Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

It depends. The original Converter design, back when it was the Interpreter 
half of the R/I, included detecting conflicting keywords. However, when IBM 
added quoted keywords, e.g., AMP='RECFM=FB', that fell to the wayside for those 
new parameters. For new unquoted keywords the checking is still in effect, 
AFAIK.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, October 9, 2022 9:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sun, 9 Oct 2022 21:07:57 +, Farley, Peter x23353  wrote:
>>>
>>If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
>>ISPF?
>
>IIRC I have to use the 3.17 Unix directory browser and a "/" to execute "View 
>ASCII/UTF8" or "Edit ASCII/UTF8", as I am unfamiliar with the 3.17 line 
>commands to do that (VA or EA maybe?  I really need to go look those up and 
>start using them), but yes, I CAN view or edit them when so tagged.
>
In my experience, a file tagged 819 or 1208 and FILEDATA is recognized and 
processid
by ISPF; I needn't specify EA or VA.

>>>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>>>allocation because I thought they would be incompatible with the PATH 
>>>keywords.
>>>
>>I'd say you underestimate IBM, but I've had too much unpleasant experience 
>>overestimating IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible 
>>with PATH.  WHY!?
>
>Good question, but probably not one to which we can get a straight answer.  At 
>a guess, old and crotchety JCL interpretation code that no one wants to touch 
>(if it ain't broke, don't fix it), while the "outside a DCB" keywords are 
>probably in newer OCO code that is "easier" (FSVO "easier") to maintain.
>
I suspect the JCL Converter has no ability to detect a conflict between one 
option and
a suboption of another option.

>>> IBM could provide better and more complete examples of accessing Unix
>>> files from a TSO or batch task
>+1...
>N t just HLASM SYSLIB, but also Binder SYSLIB and any/all HLL compiler 
>SYSLIB's, STEPLIB/JOBLIB, et alia: Basically, anywhere a Unix directory can 
>validly be used as a library.  Such usage probably warrants a sub-chapter of 
>its own, or at least a page or two somewhere prominent.
>
I believe Binder is exceptional.  It (necessarily) supported UNIX files in an 
intervel when
Allocation supported PATH but access methods didn't.  In consequence:

o Binder does not support non-trivial concatenations containing UNIX PATHs.

o Binder ignores FILEDATA and
  - treats SYSLIN as BINARY
  - treats SYSPRINT as TEXT.

I consider it indolent design that Binder does not issue a Warning if the 
programmer
codes a conflicting FILEDATA.  I've whined about that here and an IBM 
representative
(Peter?) has said that if I supply invalid input I should not expect any 
specific
behavior such as a message.  That's below the product quality I expect of IBM.

o Binder does not use BPAM, I believe in part because BLDL can't deal with
  UNIX filenames.

>Suggested (sub)chapter title: "Using Unix Directories as libraries".  JCL 
>Programmer's Guide perhaps, with sufficient examples to cover all the bases 
>for both TSO and batch execution.
>
>Actually, I don’t think I've even looked at the JCL Programmer's Guide in too 
>many years, so maybe I should go see what's there these days.
>
>>>   ... that show which DD keywords are compatible with Unix allocations, but 
>>> I won't hold my breath waiting for such to be created.  There may be some 
>>> table(s) somewhere (maybe in the JCL reference manual?) that show 
>>> compatibility, but it's my fault that I haven't looked for them yet.
>>>
>>There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew 
>>page size and IBM
>>simply dropped it in favor of scattered "Relationship to other parameters" 
>>sentences.

--
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: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

Your point? The behavior in question was defaulting to card image, which was 
never a thing prior to SMS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, October 9, 2022 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sun, 9 Oct 2022 12:51:07 +, Seymour J Metz wrote:

>The point that I am trying to make is that the behavior in question did not, 
>as claimed, go back half a century.
>
A half century ago, attributes specified to Allocation dominated attributes
intrinsic to the data set, and were in turn dominated by attributes coded
in the DCB.  That behavior has been preserved in the transition from
3350 to 3390, and to UNIX files.

>
>From:  Paul Gilmartin
>Sent: Sunday, October 9, 2022 8:40 AM
>
>On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:
>
>>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>>half century, longer than MVS UNIX has existed." Half a century ago there was 
>>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.
>
>And there was no 3390, but BLKSIZE=3120 still works.
>
>What point are you trying to make?
>
>
>From: f Paul Gilmartin
>Sent: Saturday, October 8, 2022 9:10 PM
>>
>In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
>LRECL(199) RECFM(V,B) ...
>and the REXX RTL would choose a reasonable BLKSIZE.

--
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: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Mon, 10 Oct 2022 11:39:59 -0400, Tony Harminc wrote:

>On Sun, 9 Oct 2022 at 21:17, Paul Gilmartin wrote:
>
>What does it mean for allocation to support PATH if access methods didn't
>support it? How could such an allocation/DDname ever be used by a program?
>Would it have to retrieve (by some undocumented scheme?) the file name, and
>then use standard UNIX I/O on it?
> 
(I'mguessing) the documented scheme is a Dynalloc Info request and that Binder
still works that way.  Necessarily for SYSLIB  since it may contain member names
invalid for BLDL (perhaps longer than 8 characters) thus inaccessible by BPAM.


-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Tony Harminc]

On Sun, 9 Oct 2022 at 21:17, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> [...]
> I believe Binder is exceptional.  It (necessarily) supported UNIX files in
> an intervel when
> Allocation supported PATH but access methods didn't.


What does it mean for allocation to support PATH if access methods didn't
support it? How could such an allocation/DDname ever be used by a program?
Would it have to retrieve (by some undocumented scheme?) the file name, and
then use standard UNIX I/O on it?

  In consequence:
>
> o Binder does not support non-trivial concatenations containing UNIX PATHs.
>
> o Binder ignores FILEDATA and
>   - treats SYSLIN as BINARY
>   - treats SYSPRINT as TEXT.
>

It sounds as though that's what you're saying. I guess I don't remember
that stage of UNIX on (presumably) OS/390.

Tony H.

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 21:07:57 +, Farley, Peter x23353  wrote:
>>>
>>If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
>>ISPF?
>
>IIRC I have to use the 3.17 Unix directory browser and a "/" to execute "View 
>ASCII/UTF8" or "Edit ASCII/UTF8", as I am unfamiliar with the 3.17 line 
>commands to do that (VA or EA maybe?  I really need to go look those up and 
>start using them), but yes, I CAN view or edit them when so tagged.
> 
In my experience, a file tagged 819 or 1208 and FILEDATA is recognized and 
processid
by ISPF; I needn't specify EA or VA.

>>>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>>>allocation because I thought they would be incompatible with the PATH 
>>>keywords.  
>>>
>>I'd say you underestimate IBM, but I've had too much unpleasant experience 
>>overestimating IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible 
>>with PATH.  WHY!?
>
>Good question, but probably not one to which we can get a straight answer.  At 
>a guess, old and crotchety JCL interpretation code that no one wants to touch 
>(if it ain't broke, don't fix it), while the "outside a DCB" keywords are 
>probably in newer OCO code that is "easier" (FSVO "easier") to maintain.
> 
I suspect the JCL Converter has no ability to detect a conflict between one 
option and
a suboption of another option.

>>> IBM could provide better and more complete examples of accessing Unix 
>>> files from a TSO or batch task
>+1...
>N t just HLASM SYSLIB, but also Binder SYSLIB and any/all HLL compiler 
>SYSLIB's, STEPLIB/JOBLIB, et alia: Basically, anywhere a Unix directory can 
>validly be used as a library.  Such usage probably warrants a sub-chapter of 
>its own, or at least a page or two somewhere prominent.
> 
I believe Binder is exceptional.  It (necessarily) supported UNIX files in an 
intervel when
Allocation supported PATH but access methods didn't.  In consequence:

o Binder does not support non-trivial concatenations containing UNIX PATHs.

o Binder ignores FILEDATA and
  - treats SYSLIN as BINARY
  - treats SYSPRINT as TEXT.

I consider it indolent design that Binder does not issue a Warning if the 
programmer
codes a conflicting FILEDATA.  I've whined about that here and an IBM 
representative
(Peter?) has said that if I supply invalid input I should not expect any 
specific
behavior such as a message.  That's below the product quality I expect of IBM.

o Binder does not use BPAM, I believe in part because BLDL can't deal with
  UNIX filenames.

>Suggested (sub)chapter title: "Using Unix Directories as libraries".  JCL 
>Programmer's Guide perhaps, with sufficient examples to cover all the bases 
>for both TSO and batch execution.
>
>Actually, I don’t think I've even looked at the JCL Programmer's Guide in too 
>many years, so maybe I should go see what's there these days.
>
>>>   ... that show which DD keywords are compatible with Unix allocations, but 
>>> I won't hold my breath waiting for such to be created.  There may be some 
>>> table(s) somewhere (maybe in the JCL reference manual?) that show 
>>> compatibility, but it's my fault that I haven't looked for them yet.
>>> 
>>There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew 
>>page size and IBM 
>>simply dropped it in favor of scattered "Relationship to other parameters" 
>>sentences.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

On Sunday, October 9, 2022 3:52 PM, Paul Gilmartin wrote:

>On Sun, 9 Oct 2022 19:00:26 +, Farley, Peter x23353 wrote:
>

>
>> ... At the time of that ISO8859-1 test I know I did NOT have the LRECL/RECFM 
>> override in place for the SYSEXEC allocation, so that may have been the 
>> problem rather than the file encoding.
>>
>If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
>ISPF?

IIRC I have to use the 3.17 Unix directory browser and a "/" to execute "View 
ASCII/UTF8" or "Edit ASCII/UTF8", as I am unfamiliar with the 3.17 line 
commands to do that (VA or EA maybe?  I really need to go look those up and 
start using them), but yes, I CAN view or edit them when so tagged.

>>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>>allocation because I thought they would be incompatible with the PATH 
>>keywords.  
>>
>I'd say you underestimate IBM, but I've had too much unpleasant experience 
>overestimating IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible with 
>PATH.  WHY!?

Good question, but probably not one to which we can get a straight answer.  At 
a guess, old and crotchety JCL interpretation code that no one wants to touch 
(if it ain't broke, don't fix it), while the "outside a DCB" keywords are 
probably in newer OCO code that is "easier" (FSVO "easier") to maintain.

>> IBM could provide better and more complete examples of accessing Unix 
>> files from a TSO or batch task
>+1
>At least complete examples for IEBGENER SYSUT1 and HLASM SYSLIB, both showing 
>examples of mixed concatenation.  The best I find easily is in Using Data Sets:
>//SYSUT2  DD PATH='/sj/sjpl/xsam/xpm17u01/paytime',
>//   PATHDISP=(KEEP,DELETE),
>//   PATHOPTS=(OCREAT,ORDWR),
>//   PATHMODE=(SIRUSR,SIWUSR,
>// SIRGRP,SIROTH),
>//   FILEDATA=TEXT

+1
Not just HLASM SYSLIB, but also Binder SYSLIB and any/all HLL compiler 
SYSLIB's, STEPLIB/JOBLIB, et alia: Basically, anywhere a Unix directory can 
validly be used as a library.  Such usage probably warrants a sub-chapter of 
its own, or at least a page or two somewhere prominent.

Suggested (sub)chapter title: "Using Unix Directories as libraries".  JCL 
Programmer's Guide perhaps, with sufficient examples to cover all the bases for 
both TSO and batch execution.

Actually, I don’t think I've even looked at the JCL Programmer's Guide in too 
many years, so maybe I should go see what's there these days.

>>   ... that show which DD keywords are compatible with Unix allocations, but 
>> I won't hold my breath waiting for such to be created.  There may be some 
>> table(s) somewhere (maybe in the JCL reference manual?) that show 
>> compatibility, but it's my fault that I haven't looked for them yet.
>> 
>There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew 
>page size and IBM simply dropped it in favor of scattered "Relationship to 
>other parameters"
>sentences.
--

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 19:00:26 +, Farley, Peter x23353 wrote:

>I believe I tried just removing the DSNTYPE(HFS) and it failed, but I will try 
>that again at my next opportunity to see what happens.
>
The two uses of DSNTYPE I can find are

Identify the file type as either PIPE (a FIFO file) that is coded in 
combination
with the PATH operand or

as an HFS (hierarchical file system) specified in combination with the 
DSNAME operand.
HFS indicates that the data set is an HFS data set which contains a z/OS® 
UNIX
hierarchical file system.

( I believe the latter is obsolete and not what you intend.  You didn't specify 
DSN.)

DSNTYPE does support other values (for example LIBRARY, PDS, EXTREQ,
EXTPREF, LARGE, and BASIC), but these are not appropriate for HFS files.

>Yes, my Rexx programs are tagged (IBM1047 and text), and yes, the 
>auto-conversion incantations are active.  I thought I tried tagging as 
>ISO8859-1 and text and it failed to execute a called Rexx program in the Unix 
>directory with a WRONG.LENGTH.RECORD error,
>
I'm too familiar with that for LRECL too small.  It should have a different M 
because
RECORD historically meant "block" when that message was issued.

> ... but I will repeat that test to verify.  At the time of that ISO8859-1 
> test I know I did NOT have the LRECL/RECFM override in place for the SYSEXEC 
> allocation, so that may have been the problem rather than the file encoding.
>
If it doesn't work it deserves an SR.  Can you Edit/View files so tagged with 
ISPF?

>I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
>allocation because I thought they would be incompatible with the PATH 
>keywords.  
>
I'd say you underestimate IBM, but I've had too much unpleasant experience 
overestimating
IBM in such matters.  BTW, DCB=(LRECL,...) is incompatible with PATH.  WHY!?

> IBM could provide better and more complete examples of accessing Unix files 
> from a TSO or batch task
>
+1
At least complete examples for IEBGENER SYSUT1 and HLASM SYSLIB, both showing 
examples
of mixed concatenation.  The best I find easily is in Using Data Sets:
//SYSUT2  DD PATH='/sj/sjpl/xsam/xpm17u01/paytime',
//   PATHDISP=(KEEP,DELETE),
//   PATHOPTS=(OCREAT,ORDWR),
//   PATHMODE=(SIRUSR,SIWUSR,
// SIRGRP,SIROTH),
//   FILEDATA=TEXT

>   ... that show which DD keywords are compatible with Unix allocations, but I 
> won't hold my breath waiting for such to be created.  There may be some 
> table(s) somewhere (maybe in the JCL reference manual?) that show 
> compatibility, but it's my fault that I haven't looked for them yet.
> 
There used to be such a matrix, in the JCL Ref., IIRC.  Perhaps it outgrew page 
size
and IBM simply dropped it in favor of scattered "Relationship to other 
parameters"
sentences.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

I believe I tried just removing the DSNTYPE(HFS) and it failed, but I will try 
that again at my next opportunity to see what happens.

Yes, my Rexx programs are tagged (IBM1047 and text), and yes, the 
auto-conversion incantations are active.  I thought I tried tagging as 
ISO8859-1 and text and it failed to execute a called Rexx program in the Unix 
directory with a WRONG.LENGTH.RECORD error, but I will repeat that test to 
verify.  At the time of that ISO8859-1 test I know I did NOT have the 
LRECL/RECFM override in place for the SYSEXEC allocation, so that may have been 
the problem rather than the file encoding.

I probably won’t be able to repeat these tests for at least a week because 
other tasks have priority, but I will report back after they are done.

I originally did not think of using LRECL/RECFM overrides on the SYSEXEC 
allocation because I thought they would be incompatible with the PATH keywords. 
 IBM could provide better and more complete examples of accessing Unix files 
from a TSO or batch task that show which DD keywords are compatible with Unix 
allocations, but I won't hold my breath waiting for such to be created.  There 
may be some table(s) somewhere (maybe in the JCL reference manual?) that show 
compatibility, but it's my fault that I haven't looked for them yet.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Saturday, October 8, 2022 7:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sat, 8 Oct 2022 21:40:26 +, Farley, Peter x23353  wrote:

>Follow-up #2: I found out through further experimentation that there is an 
>ASSUMPTION of LRECL(80) RECFM(F) when SYSEXEC is a Unix directory, but you can 
>override that assumption by using LRECL and RECFM on the ALLOC for SYSEXEC:
>
>  "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" ,
> "PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" ,
> "FILEDATA(TEXT) PATHDISP(KEEP, KEEP) LRECL(4096) RECFM(V)"
> 
Attribute overrides have worked that way for a half century, longer than MVS 
UNIX has existed.

Does DSNTYPE(HFS) do anything, given that HFS is no longer supported?

PATH for SYSEXEC used not to work.  Apparently it has been fixed.

>EBCDIC encoding of the Rexx programs stored in the Unix directory is still 
>required.
>
Are your Rexx programs tagged with CCSID (ASCII, if you want), and have you 
issued the incantations to enable autoconversion?  If you have and it still 
doesn't work, an SR or an RFE is in order.

ISPF Edit recognizes and respects CCSID tagging of UNIX files, converting 
to/from your terminal CCSID.

--

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 12:51:07 +, Seymour J Metz wrote:

>The point that I am trying to make is that the behavior in question did not, 
>as claimed, go back half a century.
>
A half century ago, attributes specified to Allocation dominated attributes
intrinsic to the data set, and were in turn dominated by attributes coded
in the DCB.  That behavior has been preserved in the transition from
3350 to 3390, and to UNIX files.

>
>From:  Paul Gilmartin
>Sent: Sunday, October 9, 2022 8:40 AM
>
>On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:
>
>>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>>half century, longer than MVS UNIX has existed." Half a century ago there was 
>>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.
>
>And there was no 3390, but BLKSIZE=3120 still works.
>
>What point are you trying to make?
>
>
>From: f Paul Gilmartin
>Sent: Saturday, October 8, 2022 9:10 PM
>>
>In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
>LRECL(199) RECFM(V,B) ...
>and the REXX RTL would choose a reasonable BLKSIZE.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

The point that I am trying to make is that the behavior in question did not, as 
claimed, go back half a century.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, October 9, 2022 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:

>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>half century, longer than MVS UNIX has existed." Half a century ago there was 
>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.

And there was no 3390, but BLKSIZE=3120 still works.

What point are you trying to make?


From: f Paul Gilmartin
Sent: Saturday, October 8, 2022 9:10 PM
>
In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
LRECL(199) RECFM(V,B) ...
and the REXX RTL would choose a reasonable BLKSIZE.

-- 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: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 04:46:17 +, Seymour J Metz  wrote:

>Anachronism alert! You wrote "Attribute overrides have worked that way for a 
>half century, longer than MVS UNIX has existed." Half a century ago there was 
>no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.

And there was no 3390, but BLKSIZE=3120 still works.

What point are you trying to make?


From: f Paul Gilmartin
Sent: Saturday, October 8, 2022 9:10 PM
>
In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
LRECL(199) RECFM(V,B) ...
and the REXX RTL would choose a reasonable BLKSIZE.

-- gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

Anachronism alert! You wrote "Attribute overrides have worked that way for a 
half century, longer than MVS UNIX has existed." Half a century ago there was 
no PATH and no SDB. In fact, there was no SYSEXEC, only SYSPROC.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, October 8, 2022 9:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sun, 9 Oct 2022 00:14:48 +, Seymour J Metz wrote:

>Prior to MVS-OE, there would have been DCB information in the DSCB for 
>existing DASD data sets. There was no card-image default of RECFM and LRECL . 
>Perhaps you're thinking of EDIT, for which there were defaults.
>
In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
LRECL(199) RECFM(V,B) ...
and the REXX RTL would choose a reasonable BLKSIZE.

Suddenly, it failed.  I went to SR, who recommended a PTF targeted for JES but
which worked.  SR explained that selecting BLKSIXE in the REXX RTL had been
disabled in order to let SDB operate, and SDB for JES (and presumably PATH)
unconditionally defaulted to BLKSIZE(80).  SR then recommended that I shoulc
never default BLKSIZE; an ironic consequence of SDB.

--
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: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sun, 9 Oct 2022 00:14:48 +, Seymour J Metz wrote:

>Prior to MVS-OE, there would have been DCB information in the DSCB for 
>existing DASD data sets. There was no card-image default of RECFM and LRECL . 
>Perhaps you're thinking of EDIT, for which there were defaults.
> 
In REXX, long ago, prior to SDB. I used to ALLOCATE PATH(whatever) ,
LRECL(199) RECFM(V,B) ...
and the REXX RTL would choose a reasonable BLKSIZE.

Suddenly, it failed.  I went to SR, who recommended a PTF targeted for JES but
which worked.  SR explained that selecting BLKSIXE in the REXX RTL had been
disabled in order to let SDB operate, and SDB for JES (and presumably PATH)
unconditionally defaulted to BLKSIZE(80).  SR then recommended that I shoulc
never default BLKSIZE; an ironic consequence of SDB.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

Prior to MVS-OE, there would have been DCB information in the DSCB for existing 
DASD data sets. There was no card-image default of RECFM and LRECL . Perhaps 
you're thinking of EDIT, for which there were defaults.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, October 8, 2022 7:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Sat, 8 Oct 2022 21:40:26 +, Farley, Peter x23353  wrote:

>Follow-up #2: I found out through further experimentation that there is an 
>ASSUMPTION of LRECL(80) RECFM(F) when SYSEXEC is a Unix directory, but you can 
>override that assumption by using LRECL and RECFM on the ALLOC for SYSEXEC:
>
>  "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" ,
> "PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" ,
> "FILEDATA(TEXT) PATHDISP(KEEP, KEEP) LRECL(4096) RECFM(V)"
>
Attribute overrides have worked that way for a half century, longer
than MVS UNIX has existed.

Does DSNTYPE(HFS) do anything, given that HFS is no longer supported?

PATH for SYSEXEC used not to work.  Apparently it has been fixed.

>EBCDIC encoding of the Rexx programs stored in the Unix directory is still 
>required.
>
Are your Rexx programs tagged with CCSID (ASCII, if you want), and have you
issued the incantations to enable autoconversion?  If you have and it still 
doesn't
work, an SR or an RFE is in order.

ISPF Edit recognizes and respects CCSID tagging of UNIX files, converting
to/from your terminal CCSID.

--
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: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Sat, 8 Oct 2022 21:40:26 +, Farley, Peter x23353  wrote:

>Follow-up #2: I found out through further experimentation that there is an 
>ASSUMPTION of LRECL(80) RECFM(F) when SYSEXEC is a Unix directory, but you can 
>override that assumption by using LRECL and RECFM on the ALLOC for SYSEXEC:
>
>  "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" ,
> "PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" ,
> "FILEDATA(TEXT) PATHDISP(KEEP, KEEP) LRECL(4096) RECFM(V)"
> 
Attribute overrides have worked that way for a half century, longer
than MVS UNIX has existed.

Does DSNTYPE(HFS) do anything, given that HFS is no longer supported?

PATH for SYSEXEC used not to work.  Apparently it has been fixed.

>EBCDIC encoding of the Rexx programs stored in the Unix directory is still 
>required.
>
Are your Rexx programs tagged with CCSID (ASCII, if you want), and have you
issued the incantations to enable autoconversion?  If you have and it still 
doesn't
work, an SR or an RFE is in order.

ISPF Edit recognizes and respects CCSID tagging of UNIX files, converting
to/from your terminal CCSID.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Follow-up #2: I found out through further experimentation that there is an 
ASSUMPTION of LRECL(80) RECFM(F) when SYSEXEC is a Unix directory, but you can 
override that assumption by using LRECL and RECFM on the ALLOC for SYSEXEC:

  "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" ,
 "PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" ,
 "FILEDATA(TEXT) PATHDISP(KEEP, KEEP) LRECL(4096) RECFM(V)"

EBCDIC encoding of the Rexx programs stored in the Unix directory is still 
required.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Thursday, September 15, 2022 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Follow-up: Unexpected and dumb restriction found.

While using the knowledge I built during this investigation to write a 
real-world use of the process, I found that the "address TSO" process from a 
starting Rexx in a Unix directory has a record-length restriction on SYSEXEC of 
80 bytes.

In other words, ALLOC of a Unix directory as the SYSEXEC DD makes TSO (and/or 
Rexx itself) "AssUMe" that the LRECL for the directory is 80.

In JCL you may be able overcome this using a dummy first PDS with a longer or 
variable-length RECFM/LRECL, but as far as I can tell ALLOC has no way to 
CONCAT a PDS (dummy or otherwise) with a Unix directory.  BPXWDYN may be able 
to do better, I really need to research that.

Anyway, if any line in the second Unix directory Rexx script (the one you 
really want to run) that is executed under "address TSO" is > 80 bytes, you get 
a "WRONG.LENGTH.RECORD" error and I/O abend from BPAM.

At least the first Rexx (the one you start from Unix) continues running to 
report the error(s).

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, September 12, 2022 4:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Apologies, I spotted a typo after hitting send:

3.  The TESTLSA, TESTREXA1, and TESTREXA3 scripts are duplicates of the 
TESTLS, TESTREX1, and TESTREX3 scripts but stored as ISO8859 text rather than 
as IBM1047 text.

TESTREX3, not TESTREX2

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, September 12, 2022 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

I finally found the round tuits to finish this exercise, so here is what I 
found works.  I hope my test pastes here make it through the listserver 
manipulations.  Apologies if they do not.

Setup:

1.  In my Unix $HOME directory I created a new "exec" directory
2.  Below are listed the contents of that "exec" directory with CCSID tags 
shown (and non-relevant lines omitted), followed by a listing of each of the 
three scripts TESTLS, TESTREX1, TESTREX3
3.  The TESTLSA, TESTREXA1, and TESTREXA3 scripts are duplicates of the 
TESTLS, TESTREX1, and TESTREX2 scripts but stored as ISO8859 text rather than 
as IBM1047 text.
4.  The PDSE named TSOUSER.EXEC contains a copy of TESTLS identical to the 
/u/tsouser/exec/TESTLS file

The TESTREX1 script executes the TESTLS script stored in the TSOUSER.EXEC PDSE. 
 The TESTREX3 script executes the TESTLS script stored in 
/u/tsouser/exec/TESTLS.

The TESTLS script executes a LISTDSI using the DSN passed as its only argument 
and prints out the RC and SYSREASON from the LISTDSI, and if the RC is zero it 
then prints some of the LISTDSI returned variable contents.

Listed first below are the results of running the TESTREX1 and TESTREX3 scripts 
directly from the Unix shell command prompt.  Note that running the ISO8859 
versions TESTREXA1 or TESTREXA3 will generate the same results as TESTREX1 and 
TESTREX3.  The key requirement is that if you want to execute a Rexx script 
stored in a Unix directory under "ADDRESS TSO" then that script MUST be coded 
in IBM1047 (or, I suspect, any valid EBCDIC CCSID).  The "starting" script (the 
one you execute from the shell prompt) can be coded in either an EBCDIC CCSID 
or in ISO8859 (and probably also UTF-8) but that capability is probably under 
the influence of the AUTOCVT option(s).

The first key takeaway is that a Rexx script stored in the Unix file system and 
executed under "ADDRESS TSO" in a Rexx script executed from the shell MUST be 
stored in an EBCDIC CCSID.  If you change the Unix-stored script name to be 
executed under "ADDRESS TSO" in the TESTREX3 script to TESTLSA (the ISO8859 
version), it fails with a WRNG.LEN.REC I/O error from BPAM.

The second key takeaway is that the stack does not survive the transition from 
"ADDRESS TSO" back to the script executing under the shell.  I tried using 
"QUEUE

Re: How to use LISTDSI from Rexx under Unix shell?

[David Spiegel]

Hi Gil,
Some software vendors distribute their CLIST/Rexx PDSs/PDSEs only as FB/80.
This will cause you grief because you cannot concatenate VB and FB.
That is why I have never converted to VB CLISTs/Rexx. It's just not 
worth the extra work.

(Yes, I know that you can ALTLIB, but, that is not always possible.)

I agree that BLKSIZE=3120 (or 3200) is dumb and outdated for card-image 
Datasets (e.g. MACLIBs, PROCLIBs, JCLLIBs, Source Code).
One has to keep in mind, though, that cleaning up JCL does not make 
money for the software vendor and introduces the need to test the new 
Allocations.

There is no return on investment and there is more cost.

Regards,
David

On 2022-09-19 08:22, Paul Gilmartin wrote:

On Mon, 19 Sep 2022 04:00:05 +, Seymour J Metz wrote:


WTF? TSO has supported LRECL=255 for over half a century. Don't be confused by 
IBM shipping code in an archaic form factor.


Alas, I am confounded, not confused, by IBM's shipping SYSLIB, SYSPROC,
etc. in an archaic form factor making concatenation of user libraries in a more
rational form factor.  I somewhat circumvented that absurdity by making my
SYSEXEC RECFM=VB.

When I first encountered MVS I wondered that RECFM=VBS,LRECL=X wasn't
the modal format, because it's the most compatible with all possible data.
Or that access methods didn't convert from the format on physical media to
that requested in JCL or DCB.  IBM belatedly provided that facility for UNIX
files but never extended that support to Classic data sets.



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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Mon, 19 Sep 2022 04:00:05 +, Seymour J Metz wrote:

>WTF? TSO has supported LRECL=255 for over half a century. Don't be confused by 
>IBM shipping code in an archaic form factor.
>
Alas, I am confounded, not confused, by IBM's shipping SYSLIB, SYSPROC,
etc. in an archaic form factor making concatenation of user libraries in a more
rational form factor.  I somewhat circumvented that absurdity by making my
SYSEXEC RECFM=VB.

When I first encountered MVS I wondered that RECFM=VBS,LRECL=X wasn't
the modal format, because it's the most compatible with all possible data.
Or that access methods didn't convert from the format on physical media to
that requested in JCL or DCB.  IBM belatedly provided that facility for UNIX
files but never extended that support to Classic data sets.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

WTF? TSO has supported LRECL=255 for over half a century. Don't be confused by 
IBM shipping code in an archaic form factor.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Friday, September 16, 2022 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Fri, 16 Sep 2022 15:04:06 +, Farley, Peter  wrote:

>More appropriately, since my ALLOC of SYSEXEC to a PATH specified 
>FILETYPE(TEXT), it seems to me that should signal to the system (whoever 
>creates and opens the SYSEXEC DCB) that the data in that file are 
>presumptively RECFM=V,LRECL=(some reasonable maximum like 4096).
>
When have you ever seen a 4096-column keypunch?  80 is the only
reasonable value compatible with antiquated art, HLASM SYSIN, etc.

>I will try out both LRECL on the existing ALLOC and the BPXWDYN method and see 
>which works.
>
I wrote nastily, from memory, in my BPXWDYN suggestion.  Closer,
but still from memory:
ADDRESS TSO "call *(bpxwdyn) 'concat DDLIST(SYSEXEC,DDname2[,DDnamex...])'"

--
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: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Fri, 16 Sep 2022 15:04:06 +, Farley, Peter  wrote:

>More appropriately, since my ALLOC of SYSEXEC to a PATH specified 
>FILETYPE(TEXT), it seems to me that should signal to the system (whoever 
>creates and opens the SYSEXEC DCB) that the data in that file are 
>presumptively RECFM=V,LRECL=(some reasonable maximum like 4096).
> 
When have you ever seen a 4096-column keypunch?  80 is the only
reasonable value compatible with antiquated art, HLASM SYSIN, etc.

>I will try out both LRECL on the existing ALLOC and the BPXWDYN method and see 
>which works.
>
I wrote nastily, from memory, in my BPXWDYN suggestion.  Closer,
but still from memory:
ADDRESS TSO "call *(bpxwdyn) 'concat DDLIST(SYSEXEC,DDname2[,DDnamex...])'"

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

More appropriately, since my ALLOC of SYSEXEC to a PATH specified 
FILETYPE(TEXT), it seems to me that should signal to the system (whoever 
creates and opens the SYSEXEC DCB) that the data in that file are presumptively 
RECFM=V,LRECL=(some reasonable maximum like 4096).

Hindsight is always 20/20.

I will try out both LRECL on the existing ALLOC and the BPXWDYN method and see 
which works.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, September 15, 2022 7:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Thu, 15 Sep 2022 22:19:40 +, Farley, Peter x23353 
 wrote:

>Follow-up: Unexpected and dumb restriction found.
>
>While using the knowledge I built during this investigation to write a 
>real-world use of the process, I found that the "address TSO" process from a 
>starting Rexx in a Unix directory has a record-length restriction on SYSEXEC 
>of 80 bytes.
>
>In other words, ALLOC of a Unix directory as the SYSEXEC DD makes TSO (and/or 
>Rexx itself) "AssUMe" that the LRECL for the directory is 80.
>
>In JCL you may be able overcome this using a dummy first PDS with a longer or 
>variable-length RECFM/LRECL, but as far as I can tell ALLOC has no way to 
>CONCAT a PDS (dummy or otherwise) with a Unix directory.  BPXWDYN may be able 
>to do better, I really need to research that.
>
ADDRESS TSO "call bpxwdyn 'concat(SYSEXEC,...)'"

>Anyway, if any line in the second Unix directory Rexx script (the one you 
>really want to run) that is executed under "address TSO" is > 80 bytes, you 
>get a "WRONG.LENGTH.RECORD" error and I/O abend from BPAM.
>
Can't you specify LRECL on ALLOCATE (or BPXWDYN) PATH ...?

Many years ago I encountered a similar (I felt it was worse) problem because a 
PATH hasn't a DSORG acceptable for REXX.  Has that been fixed?  DYNALOC should 
supply PO or PS as suitable, or at least make DSORG not mutually exclusive with 
PATH in JCL.  I circumvented with CONCAT.

And I got an ABEND from FREEMAIN (I guess) at exec termination (storage key 
conflict, I guess.)  I ignored it because it occurred at completion and no data 
were lost.

--

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Thu, 15 Sep 2022 22:19:40 +, Farley, Peter x23353 
 wrote:

>Follow-up: Unexpected and dumb restriction found.
>
>While using the knowledge I built during this investigation to write a 
>real-world use of the process, I found that the "address TSO" process from a 
>starting Rexx in a Unix directory has a record-length restriction on SYSEXEC 
>of 80 bytes.
>
>In other words, ALLOC of a Unix directory as the SYSEXEC DD makes TSO (and/or 
>Rexx itself) "AssUMe" that the LRECL for the directory is 80.
>
>In JCL you may be able overcome this using a dummy first PDS with a longer or 
>variable-length RECFM/LRECL, but as far as I can tell ALLOC has no way to 
>CONCAT a PDS (dummy or otherwise) with a Unix directory.  BPXWDYN may be able 
>to do better, I really need to research that.
>
ADDRESS TSO "call bpxwdyn 'concat(SYSEXEC,...)'"

>Anyway, if any line in the second Unix directory Rexx script (the one you 
>really want to run) that is executed under "address TSO" is > 80 bytes, you 
>get a "WRONG.LENGTH.RECORD" error and I/O abend from BPAM.
>
Can't you specify LRECL on ALLOCATE (or BPXWDYN) PATH ...?

Many years ago I encountered a similar (I felt it was worse) problem because a 
PATH hasn't
a DSORG acceptable for REXX.  Has that been fixed?  DYNALOC should supply PO or 
PS
as suitable, or at least make DSORG not mutually exclusive with PATH in JCL.  I 
circumvented
with CONCAT.

And I got an ABEND from FREEMAIN (I guess) at exec termination (storage key 
conflict,
I guess.)  I ignored it because it occurred at completion and no data were lost.

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Follow-up: Unexpected and dumb restriction found.

While using the knowledge I built during this investigation to write a 
real-world use of the process, I found that the "address TSO" process from a 
starting Rexx in a Unix directory has a record-length restriction on SYSEXEC of 
80 bytes.

In other words, ALLOC of a Unix directory as the SYSEXEC DD makes TSO (and/or 
Rexx itself) "AssUMe" that the LRECL for the directory is 80.

In JCL you may be able overcome this using a dummy first PDS with a longer or 
variable-length RECFM/LRECL, but as far as I can tell ALLOC has no way to 
CONCAT a PDS (dummy or otherwise) with a Unix directory.  BPXWDYN may be able 
to do better, I really need to research that.

Anyway, if any line in the second Unix directory Rexx script (the one you 
really want to run) that is executed under "address TSO" is > 80 bytes, you get 
a "WRONG.LENGTH.RECORD" error and I/O abend from BPAM.

At least the first Rexx (the one you start from Unix) continues running to 
report the error(s).

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, September 12, 2022 4:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Apologies, I spotted a typo after hitting send:

3.  The TESTLSA, TESTREXA1, and TESTREXA3 scripts are duplicates of the 
TESTLS, TESTREX1, and TESTREX3 scripts but stored as ISO8859 text rather than 
as IBM1047 text.

TESTREX3, not TESTREX2

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, September 12, 2022 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

I finally found the round tuits to finish this exercise, so here is what I 
found works.  I hope my test pastes here make it through the listserver 
manipulations.  Apologies if they do not.

Setup:

1.  In my Unix $HOME directory I created a new "exec" directory
2.  Below are listed the contents of that "exec" directory with CCSID tags 
shown (and non-relevant lines omitted), followed by a listing of each of the 
three scripts TESTLS, TESTREX1, TESTREX3
3.  The TESTLSA, TESTREXA1, and TESTREXA3 scripts are duplicates of the 
TESTLS, TESTREX1, and TESTREX2 scripts but stored as ISO8859 text rather than 
as IBM1047 text.
4.  The PDSE named TSOUSER.EXEC contains a copy of TESTLS identical to the 
/u/tsouser/exec/TESTLS file

The TESTREX1 script executes the TESTLS script stored in the TSOUSER.EXEC PDSE. 
 The TESTREX3 script executes the TESTLS script stored in 
/u/tsouser/exec/TESTLS.

The TESTLS script executes a LISTDSI using the DSN passed as its only argument 
and prints out the RC and SYSREASON from the LISTDSI, and if the RC is zero it 
then prints some of the LISTDSI returned variable contents.

Listed first below are the results of running the TESTREX1 and TESTREX3 scripts 
directly from the Unix shell command prompt.  Note that running the ISO8859 
versions TESTREXA1 or TESTREXA3 will generate the same results as TESTREX1 and 
TESTREX3.  The key requirement is that if you want to execute a Rexx script 
stored in a Unix directory under "ADDRESS TSO" then that script MUST be coded 
in IBM1047 (or, I suspect, any valid EBCDIC CCSID).  The "starting" script (the 
one you execute from the shell prompt) can be coded in either an EBCDIC CCSID 
or in ISO8859 (and probably also UTF-8) but that capability is probably under 
the influence of the AUTOCVT option(s).

The first key takeaway is that a Rexx script stored in the Unix file system and 
executed under "ADDRESS TSO" in a Rexx script executed from the shell MUST be 
stored in an EBCDIC CCSID.  If you change the Unix-stored script name to be 
executed under "ADDRESS TSO" in the TESTREX3 script to TESTLSA (the ISO8859 
version), it fails with a WRNG.LEN.REC I/O error from BPAM.

The second key takeaway is that the stack does not survive the transition from 
"ADDRESS TSO" back to the script executing under the shell.  I tried using 
"QUEUE" instead of "SAY" in the TESTLS script, but the values stacked got 
"executed" under the "ADDRESS TSO" umbrella, so "ADDRESS TSO" scripts that want 
to return data have to use "SAY" to transmit information back to the invoking 
script.

Peter

/u/tsouser/exec > TESTREX1 'TSOUSER.EXEC'
 3 *-* parse source env how fullname fromddn fromdsn fromname hostcmd 
hostasn
   >>>   "TSO"
   >>>   "COMMAND"
   >>>   "./exec/TESTREX1"
   >>>   "PATH"
   >>>   "./exec/TESTREX1"
   >>>   "?"
   >>>   "SH"
   >>>   "OMVS OpenMVS"
 4 *-* SAY &quo

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Apologies, I spotted a typo after hitting send:

3.  The TESTLSA, TESTREXA1, and TESTREXA3 scripts are duplicates of the 
TESTLS, TESTREX1, and TESTREX3 scripts but stored as ISO8859 text rather than 
as IBM1047 text.

TESTREX3, not TESTREX2

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, September 12, 2022 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

EXTERNAL EMAIL

I finally found the round tuits to finish this exercise, so here is what I 
found works.  I hope my test pastes here make it through the listserver 
manipulations.  Apologies if they do not.

Setup:

1.  In my Unix $HOME directory I created a new "exec" directory
2.  Below are listed the contents of that "exec" directory with CCSID tags 
shown (and non-relevant lines omitted), followed by a listing of each of the 
three scripts TESTLS, TESTREX1, TESTREX3
3.  The TESTLSA, TESTREXA1, and TESTREXA3 scripts are duplicates of the 
TESTLS, TESTREX1, and TESTREX2 scripts but stored as ISO8859 text rather than 
as IBM1047 text.
4.  The PDSE named TSOUSER.EXEC contains a copy of TESTLS identical to the 
/u/tsouser/exec/TESTLS file

The TESTREX1 script executes the TESTLS script stored in the TSOUSER.EXEC PDSE. 
 The TESTREX3 script executes the TESTLS script stored in 
/u/tsouser/exec/TESTLS.

The TESTLS script executes a LISTDSI using the DSN passed as its only argument 
and prints out the RC and SYSREASON from the LISTDSI, and if the RC is zero it 
then prints some of the LISTDSI returned variable contents.

Listed first below are the results of running the TESTREX1 and TESTREX3 scripts 
directly from the Unix shell command prompt.  Note that running the ISO8859 
versions TESTREXA1 or TESTREXA3 will generate the same results as TESTREX1 and 
TESTREX3.  The key requirement is that if you want to execute a Rexx script 
stored in a Unix directory under "ADDRESS TSO" then that script MUST be coded 
in IBM1047 (or, I suspect, any valid EBCDIC CCSID).  The "starting" script (the 
one you execute from the shell prompt) can be coded in either an EBCDIC CCSID 
or in ISO8859 (and probably also UTF-8) but that capability is probably under 
the influence of the AUTOCVT option(s).

The first key takeaway is that a Rexx script stored in the Unix file system and 
executed under "ADDRESS TSO" in a Rexx script executed from the shell MUST be 
stored in an EBCDIC CCSID.  If you change the Unix-stored script name to be 
executed under "ADDRESS TSO" in the TESTREX3 script to TESTLSA (the ISO8859 
version), it fails with a WRNG.LEN.REC I/O error from BPAM.

The second key takeaway is that the stack does not survive the transition from 
"ADDRESS TSO" back to the script executing under the shell.  I tried using 
"QUEUE" instead of "SAY" in the TESTLS script, but the values stacked got 
"executed" under the "ADDRESS TSO" umbrella, so "ADDRESS TSO" scripts that want 
to return data have to use "SAY" to transmit information back to the invoking 
script.

Peter

/u/tsouser/exec > TESTREX1 'TSOUSER.EXEC'
 3 *-* parse source env how fullname fromddn fromdsn fromname hostcmd 
hostasn
   >>>   "TSO"
   >>>   "COMMAND"
   >>>   "./exec/TESTREX1"
   >>>   "PATH"
   >>>   "./exec/TESTREX1"
   >>>   "?"
   >>>   "SH"
   >>>   "OMVS OpenMVS"
 4 *-* SAY "PARSE SOURCE =" env how fullname fromddn fromdsn fromname 
hostcmd hostasn
   >>>   "PARSE SOURCE = TSO COMMAND ./exec/TESTREX1 PATH ./exec/TESTREX1 ? 
SH OMVS OpenMVS"
PARSE SOURCE = TSO COMMAND ./exec/TESTREX1 PATH ./exec/TESTREX1 ? SH OMVS 
OpenMVS
 5 *-* CALL OUTTRAP OUT.
   >>>   "OUT."
   >>>   "OUT."
 6 *-* ADDRESS TSO
 7 *-* "ALLOC FI(SYSEXEC) DA('TSOUSER.EXEC') SHR"
   >>>   "ALLOC FI(SYSEXEC) DA('TSOUSER.EXEC') SHR"
 8 *-* "TESTLS 'TSOUSER.EXEC'"
   >>>   "TESTLS 'TSOUSER.EXEC'"
 9 *-* "FREE FI(SYSEXEC)"
   >>>   "FREE FI(SYSEXEC)"
10 *-* DO I=1 TO OUT.0
   >>>   "1"
   >>>   "4"
11 *-*  SAY OUT.I
   >>>"PARSE SOURCE = TSO COMMAND TESTLS SYSEXEC ? ? TSO TSO/E ?"
PARSE SOURCE = TSO COMMAND TESTLS SYSEXEC ? ? TSO TSO/E ?
12 *-* END
10 *-* DO I=1 TO OUT.0
11 *-*  SAY OUT.I
   >>>"RUNNING LISTDSI('TSOUSER.EXEC')"
RUNNING LISTDSI('TSOUSER.EXEC')
12 *-* END
10 *-* DO I=1 TO OUT.0
11 *-*  SAY OUT.I
   >>>"L

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

gt;>>   "COMMAND"
   >>>   "./exec/TESTREX3"
   >>>   "PATH"
   >>>   "./exec/TESTREX3"
   >>>   "?"
   >>>   "SH"
   >>>   "OMVS OpenMVS"
 4 *-* SAY "PARSE SOURCE =" env how fullname fromddn fromdsn fromname 
hostcmd hostasn
   >>>   "PARSE SOURCE = TSO COMMAND ./exec/TESTREX3 PATH ./exec/TESTREX3 ? 
SH OMVS OpenMVS"
PARSE SOURCE = TSO COMMAND ./exec/TESTREX3 PATH ./exec/TESTREX3 ? SH OMVS 
OpenMVS
 5 *-* CALL OUTTRAP OUT.
   >>>   "OUT."
   >>>   "OUT."
 6 *-* ADDRESS TSO
 7 *-* "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" , 
"PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" , "FILEDATA(TEXT) 
PATHDISP(KEEP, KEEP)"
   >>>   "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS) 
PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY) FILEDATA(TEXT) PATHDISP(KEEP, KEEP)"
10 *-* "TESTLS 'TSOUSER.EXEC'"
   >>>   "TESTLS 'TSOUSER.EXEC'"
11 *-* "FREE FI(SYSEXEC)"
   >>>   "FREE FI(SYSEXEC)"
12 *-* DO I=1 TO OUT.0
   >>>   "1"
   >>>   "4"
13 *-*  SAY OUT.I
   >>>"PARSE SOURCE = TSO COMMAND TESTLS SYSEXEC ? ? TSO TSO/E ?"
PARSE SOURCE = TSO COMMAND TESTLS SYSEXEC ? ? TSO TSO/E ?
14 *-* END
12 *-* DO I=1 TO OUT.0
13 *-*  SAY OUT.I
   >>>"RUNNING LISTDSI('TSOUSER.EXEC')"
RUNNING LISTDSI('TSOUSER.EXEC')
14 *-* END
12 *-* DO I=1 TO OUT.0
13 *-*  SAY OUT.I
   >>>"LISTDSI RC = 0 REASON = "
LISTDSI RC = 0 REASON = 
14 *-* END
12 *-* DO I=1 TO OUT.0
13 *-*  SAY OUT.I
   >>>"DSN=TSOUSER.EXEC,DSORG=PO,RECFM=FB,LRECL=80,BLKSIZE=32720"
DSN=TSOUSER.EXEC,DSORG=PO,RECFM=FB,LRECL=80,BLKSIZE=32720
14 *-* END
12 *-* DO I=1 TO OUT.0
15 *-* EXIT

/u/tsouser > ls -laT exec
total 192
drwxr-xr-x   2 TSOUSER   USERGRP 8192 Aug 30 01:40 .
drwxr-x---  11 TSOUSER   USERGRP 8192 Sep 12 13:22 ..
t IBM-1047T=on  -rwxr-xr-x   1 TSOUSER   USERGRP  416 Sep 12 12:54
TESTLS
t ISO8859-1   T=on  -rwxr-xr-x   1 TSOUSER   USERGRP  416 Sep 12 13:03
TESTLSA
t IBM-1047T=on  -rwxr-xr-x   1 TSOUSER   USERGRP  385 Aug 29 22:12
TESTREX1
t IBM-1047T=on  -rwxr-xr-x   1 TSOUSER   USERGRP  471 Aug 29 23:40
TESTREX3
t ISO8859-1   T=on  -rwxr-xr-x   1 TSOUSER   USERGRP  353 Aug 29 22:17
TESTREXA1
t ISO8859-1   T=on  -rwxr-xr-x   1 TSOUSER   USERGRP  501 Sep 12 12:58
TESTREXA3

This is the TESTLS script:

/* REXX */
TRACE "O"
parse source env how fullname fromddn fromdsn fromname hostcmd hostasn
SAY "PARSE SOURCE =" env how fullname fromddn fromdsn fromname hostcmd hostasn
ARG DSN2LIST
SAY "RUNNING LISTDSI("DSN2LIST")"
RRC = LISTDSI(DSN2LIST)
SAY 'LISTDSI RC =' RRC 'REASON =' SYSREASON
IF RRC = 0 THEN DO
   SAY 'DSN='SYSDSNAME',DSORG='SYSDSORG',RECFM='SYSRECFM ||,
   ',LRECL='SYSLRECL',BLKSIZE='SYSBLKSIZE
END

This is the TESTREX1 script:

/* REXX */
TRACE 'R'
parse source env how fullname fromddn fromdsn fromname hostcmd hostasn
SAY "PARSE SOURCE =" env how fullname fromddn fromdsn fromname hostcmd hostasn
CALL OUTTRAP OUT.
   ADDRESS TSO
  "ALLOC FI(SYSEXEC) DA('TSOUSER.EXEC') SHR"
  "TESTLS 'TSOUSER.EXEC'"
  "FREE FI(SYSEXEC)"
   DO I=1 TO OUT.0
  SAY OUT.I
   END
EXIT

This is the TESTREX3 script:

/* REXX */
TRACE 'R'
parse source env how fullname fromddn fromdsn fromname hostcmd hostasn
SAY "PARSE SOURCE =" env how fullname fromddn fromdsn fromname hostcmd hostasn
CALL OUTTRAP OUT.
   ADDRESS TSO
  "ALLOC FI(SYSEXEC) PATH('/u/tsouser/exec') DSNTYPE(HFS)" ,
     "PATHMODE(SIRUSR,SIXUSR) PATHOPTS(ORDONLY)" ,
 "FILEDATA(TEXT) PATHDISP(KEEP, KEEP)"
  "TESTLS 'TSOUSER.EXEC'"
  "FREE FI(SYSEXEC)"
   DO I=1 TO OUT.0
  SAY OUT.I
   END
EXIT

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Friday, August 26, 2022 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Thank you Hank.  I was able to use those examples and your suggestion to get 
something working that uses LISTDSI.  I will post my results later after a bit 
more experimentation.

It appears that LISTDSI is not *immediately* available in a Rexx script started 
directly from the shell, but *IS* available when you run another Rexx routine 
with "address TSO" from a Rexx script started directly from the shell.

I'll post

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

That sounds like yet another reason for TSO/E to steal GLOBALV from CMS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Monday, August 29, 2022 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Apologies for not responding sooner, but I will reply with working example 
soon, have been busy on other things.

However, I can report that the OUTTRAP works from shell-initiated Rexx because 
the "address tso" fork inherits FD's 0, 1, 2 and OUTTRAP captures FD 1 
(SYSTSPRT from the TSO fork) with no problem.  This is documented behavior.

Rexx variables like SYSREASON, etc., set by LISTDSI in the TSO fork do not get 
set in the OMVS address space, which is also documented behavior.  The TSO fork 
has to output values needed in the OMVS address space to SYSTSPRT (or maybe to 
the stack, still testing to see if that works or not).  STEMPUSH/STEMPULL may 
also work as a communication path if the stack survives the TSO fork.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, August 28, 2022 7:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Fri, 26 Aug 2022 00:21:06 -0500, Hank Oerlemans wrote:

>See 
>https://secure-web.cisco.com/1M_xTFEwsPu00bvTEXVoZ6ceCVLecodh0nIoNgvwQ18pdzx6Vy7o2y-zaArhM5Kcw80Kv1AzhsQIJ5rbf5CaaTGcAE_BDI3enwZVMjuoyG1RJrKXP_V22QV6pK3uG-icphKU0bvNN0x5tl9yquz-Pxa5CvY1bIhWICpX2twXGc9pfrcewAtYJd6DKevKpbzVfon6i6VL4NroShKAP9ocRM66WPaaD7Ebf_GViqw8qt_MmxSQXxT74GyvUjcpTwp7NdtHsBMXSzgBDPofOz-w4csC1sInaplpul3MyOl_eGtPZOJclcZdnvjMPMOiaAlraVsQiGnhSo-QaRshj4_duZfr4eDu-VzxmJY9vmNmFMjSjEY8nV9nHapNI4MFsRtLGiD8EesULn3_4lJyZr4z3F2Lj-yITmMIONMfALQ--fpi_bHLjTmMysQNupDBw43G-0xisxRNl1THXjgI78wpc1w/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.4.0%3Ftopic%3Denvironment-examples__%3B%21%21Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg%21KesIc3TuKFptIfS99HLPkItYC57T3-XBb_a8ys87AZ1h99dzxzncHglIwjzi5SNqrng0k3qbkEbI7zpOrBXnbR7m58EpuMzuNMVK5iI1%24
>
>Use your OMVS Rexx to Address TSO 'exec (mydsi)' your working code and outtrap 
>to work with the results.
>
I suspect that outtrap will take effect in the TMP fork, not in the OMVS fork.

You might use a POSIX pipe (address syscall pipe p.), details left as an 
exercise
for the student.

--

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: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Apologies for not responding sooner, but I will reply with working example 
soon, have been busy on other things.

However, I can report that the OUTTRAP works from shell-initiated Rexx because 
the "address tso" fork inherits FD's 0, 1, 2 and OUTTRAP captures FD 1 
(SYSTSPRT from the TSO fork) with no problem.  This is documented behavior.

Rexx variables like SYSREASON, etc., set by LISTDSI in the TSO fork do not get 
set in the OMVS address space, which is also documented behavior.  The TSO fork 
has to output values needed in the OMVS address space to SYSTSPRT (or maybe to 
the stack, still testing to see if that works or not).  STEMPUSH/STEMPULL may 
also work as a communication path if the stack survives the TSO fork.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, August 28, 2022 7:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

On Fri, 26 Aug 2022 00:21:06 -0500, Hank Oerlemans wrote:

>See 
>https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.4.0?topic=environment-examples__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KesIc3TuKFptIfS99HLPkItYC57T3-XBb_a8ys87AZ1h99dzxzncHglIwjzi5SNqrng0k3qbkEbI7zpOrBXnbR7m58EpuMzuNMVK5iI1$
>  
>
>Use your OMVS Rexx to Address TSO 'exec (mydsi)' your working code and outtrap 
>to work with the results.
> 
I suspect that outtrap will take effect in the TMP fork, not in the OMVS fork.

You might use a POSIX pipe (address syscall pipe p.), details left as an 
exercise
for the student.

--

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Fri, 26 Aug 2022 00:21:06 -0500, Hank Oerlemans wrote:

>See https://www.ibm.com/docs/en/zos/2.4.0?topic=environment-examples
>
>Use your OMVS Rexx to Address TSO 'exec (mydsi)' your working code and outtrap 
>to work with the results.
> 
I suspect that outtrap will take effect in the TMP fork, not in the OMVS fork.

You might use a POSIX pipe (address syscall pipe p.), details left as an 
exercise
for the student.

-- gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Paul Gilmartin]

On Thu, 25 Aug 2022 03:44:27 +, Farley, Peter x23353 wrote:
>
>Sample code to get LISTDSI information on 'profilename.EXEC':
>
>/* Rexx */
>Address tso
>Myrc = LISTDSI('EXEC')
>
That is not a Command, which woulc require"
"Myrc = LISTDSI('EXEC')"

>Say 'RC='Myrc',reason='SYSREASON

-- 
gil

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

I think you are correct about LISTDSI not being in the shell Rexx environment.  
The various documents are not complete or consistent in what they say about TSO 
"external" routines, and the description of exactly what "address TSO" in a 
Rexx script run from the shell does for you with respect to "external" routines 
is not very clear either.  Some practical examples using TSO "external" 
functions would help.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, August 26, 2022 10:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

That looks like LISTDSI is not in the function package for the Unix shell. 
IMHO, this is something that the documentation should explicitly mention in an 
obvious location.

z/OS 2.5 TSO/E REXX Reference, SA32-0972-50. includes LISTDSI on p. 94 of 
Built-in functions in Chapter 4. Functions, which I took to mean that it was 
generally available. However , stumbled on Table 13. Summary of using 
instructions, functions, commands, and services in Summary of writing execs for 
different address spaces in Chapter 8. Using REXX in different address spaces, 
which on p. 94 shows LISTDSI as being available only in a TSO address space. I 
would have caught on sooner had the wording in Chapter 4 been "LISTDSI is a 
TSO/E external function and is only available in a TSO address space." instead 
of "LISTDSI is a TSO/E external function.".

Similarly, Using REXX and z/OS UNIX System Services, SA23-2283-50, didn't 
address the issue of the nonavailability of TSO functions under the shell.

I've cc'd this to IBM in hopes that they will update both manuals.


--
Shmuel (Seymour J.) Metz


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, August 25, 2022 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Results under TSO/ISPF:

  3 *-* address TSO
  4 *-* Myrc = LISTDSI("'TSOUSER.EXEC'")
>L>   "'TSOUSER.EXEC'"
>F>   "0"
  5 *-* Say 'RC='Myrc',reason='SYSREASON
>L>   "RC="
>V>   "0"
>O>   "RC=0"
>L>   ",reason="
>O>   "RC=0,reason="
>V>   ""
>O>   "RC=0,reason="
 RC=0,reason=
Results under Unix shell:

/u/tsouser > cat test.rex
/* REXX */
trace "I"
address TSO
Myrc = LISTDSI("'TSOUSER.EXEC'")
say "Myrc="Myrc",reason="SYSREASON
/u/tsouser > ls -la test.rex
-rwxr-xr-x   1 'TSOUSER  IPGROUP  100 Aug 25 13:17 test.rex
/u/tsouser > test.rex
 3 *-* address TSO
 4 *-* Myrc = LISTDSI("'TSOUSER.EXEC'")
   >L>   "'TSOUSER.EXEC'"
 4 +++ Myrc = LISTDSI("'TSOUSER.EXEC'")
IRX0043I Error running ./test.rex, line 4: Routine not found
/u/tsouser >


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 25, 2022 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

The current environment shouldn't matter,  What is the output from Sample code 
to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
trace i
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON

Do the results change if you fully qualify the name?

--
Shmuel (Seymour J.) Metz

____
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, August 24, 2022 11:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to use LISTDSI from Rexx under Unix shell?

Posted earlier today on MVS-OE but got no responses there.

I know this has probably been discussed previously but I can't seem to get the 
Marist MVS-OE archive search to work for me.

Is there any way to use the LISTDSI TSO external function from "address tso" in 
a Rexx program run under the Unix shell?

I can only get it to return RC = -3, "routine not found".  Sample code below.

RTFM seems to indicate that "address tso" in a REXX program run under the Unix 
shell will run a TSO TMP in a separate address space, which is OK, I can 
capture the output from that as needed, but I am not getting any execution of 
LISTDSI at all.

Peter

Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
Address tso
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged 

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Thank you Hank.  I was able to use those examples and your suggestion to get 
something working that uses LISTDSI.  I will post my results later after a bit 
more experimentation.

It appears that LISTDSI is not *immediately* available in a Rexx script started 
directly from the shell, but *IS* available when you run another Rexx routine 
with "address TSO" from a Rexx script started directly from the shell.

I'll post more later about exactly what works and what does not.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Hank Oerlemans
Sent: Friday, August 26, 2022 1:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

See 
https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.4.0?topic=environment-examples__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!NSbZd0CNeUaU5BZESy4PzCYcXfYNfc_-HKIWdGYsJ1Msk5gyoo6kuUDqq1LLiI5hNhxUcBIlkTXgbGAIT_xeMlIM0ZT36o6fwu7OPmoq$
  

Use your OMVS Rexx to Address TSO 'exec (mydsi)' your working code and outtrap 
to work with the results.

--

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

That looks like LISTDSI is not in the function package for the Unix shell. 
IMHO, this is something that the documentation should explicitly mention in an 
obvious location.

z/OS 2.5 TSO/E REXX Reference, SA32-0972-50. includes LISTDSI on p. 94 of 
Built-in functions in Chapter 4. Functions, which I took to mean that it was 
generally available. However , stumbled on Table 13. Summary of using 
instructions, functions, commands, and services in Summary of writing execs for 
different address spaces in Chapter 8. Using REXX in different address spaces, 
which on p. 94 shows LISTDSI as being available only in a TSO address space. I 
would have caught on sooner had the wording in Chapter 4 been "LISTDSI is a 
TSO/E external function and is only available in a TSO address space." instead 
of "LISTDSI is a TSO/E external function.".

Similarly, Using REXX and z/OS UNIX System Services, SA23-2283-50, didn't 
address the issue of the nonavailability of TSO functions under the shell.

I've cc'd this to IBM in hopes that they will update both manuals.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, August 25, 2022 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

Results under TSO/ISPF:

  3 *-* address TSO
  4 *-* Myrc = LISTDSI("'TSOUSER.EXEC'")
>L>   "'TSOUSER.EXEC'"
>F>   "0"
  5 *-* Say 'RC='Myrc',reason='SYSREASON
>L>   "RC="
>V>   "0"
>O>   "RC=0"
>L>   ",reason="
>O>   "RC=0,reason="
>V>   ""
>O>   "RC=0,reason="
 RC=0,reason=
Results under Unix shell:

/u/tsouser > cat test.rex
/* REXX */
trace "I"
address TSO
Myrc = LISTDSI("'TSOUSER.EXEC'")
say "Myrc="Myrc",reason="SYSREASON
/u/tsouser > ls -la test.rex
-rwxr-xr-x   1 'TSOUSER  IPGROUP  100 Aug 25 13:17 test.rex
/u/tsouser > test.rex
 3 *-* address TSO
 4 *-* Myrc = LISTDSI("'TSOUSER.EXEC'")
   >L>   "'TSOUSER.EXEC'"
 4 +++ Myrc = LISTDSI("'TSOUSER.EXEC'")
IRX0043I Error running ./test.rex, line 4: Routine not found
/u/tsouser >


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 25, 2022 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

EXTERNAL EMAIL

The current environment shouldn't matter,  What is the output from Sample code 
to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
trace i
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON

Do the results change if you fully qualify the name?




--
Shmuel (Seymour J.) Metz
https://secure-web.cisco.com/1YDwjfxsuN8YosNj7mXD-U24m5vQEljWqswlrPh8LYVTX_Hi1LZ7_Z2wKWTHxvafcOrnzaGpO_pmhxcWmgBosKaPNMQpKnFQ3FYpBeje-M2TeG3QbVrPVsUb81Ho9ASARopQHpPksHIHHiwgGLJPuNQyM-_JX5Hd9DABesbxwSSnB5336QOJ2GXhXUjgXiqxNUtXUkUYq6mkTmFYKR1V95Jyh71qBOAFQUNrKWERw48U-_lqVaSS9hdk9aMRoo_cDS3zqegTZ1dTND2_GIwG37cpNEl1Th8nvWv5KkiSIvQOKYUltz37CJwjWnmVAg1Ki-cU0Ubitavpf6MfAqvNCb5_a852jhBKVU65KLjwzPKMQy8yUmIGNfYqUS6dkCXRdabgMekPtCundvQ7qndbB2AMq7dfga8nSuhscTBDwJQx25BIkWh7c74cVWPVONV68VjqsdgzQZhrVghR510J2IA/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F%2Asmetz3__%3Bfg%21%21Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg%21PklzQNpdawcFoesdvpTMIAxVFV0YwB_wzbMOiqhtRUydn0TkPM5kN2sOFZL7gnoPboy6U6-8YX_XX-K26lo4PA%24

________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, August 24, 2022 11:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to use LISTDSI from Rexx under Unix shell?

Posted earlier today on MVS-OE but got no responses there.

I know this has probably been discussed previously but I can't seem to get the 
Marist MVS-OE archive search to work for me.

Is there any way to use the LISTDSI TSO external function from "address tso" in 
a Rexx program run under the Unix shell?

I can only get it to return RC = -3, "routine not found".  Sample code below.

RTFM seems to indicate that "address tso" in a REXX program run under the Unix 
shell will run a TSO TMP in a separate address space, which is OK, I can 
capture the output from that as needed, but I am not getting any execution of 
LISTDSI at all.

Peter

Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
Address tso
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON


This message and any attachments are intended only for 

Re: How to use LISTDSI from Rexx under Unix shell?

[Hank Oerlemans]

See https://www.ibm.com/docs/en/zos/2.4.0?topic=environment-examples

Use your OMVS Rexx to Address TSO 'exec (mydsi)' your working code and outtrap 
to work with the results.

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Results under TSO/ISPF:

  3 *-* address TSO  
  4 *-* Myrc = LISTDSI("'TSOUSER.EXEC'")
>L>   "'TSOUSER.EXEC'"  
>F>   "0"
  5 *-* Say 'RC='Myrc',reason='SYSREASON 
>L>   "RC="  
>V>   "0"
>O>   "RC=0" 
>L>   ",reason=" 
>O>   "RC=0,reason=" 
>V>   "" 
>O>   "RC=0,reason=" 
 RC=0,reason=
Results under Unix shell:

/u/tsouser > cat test.rex
/* REXX */
trace "I"
address TSO
Myrc = LISTDSI("'TSOUSER.EXEC'")
say "Myrc="Myrc",reason="SYSREASON
/u/tsouser > ls -la test.rex
-rwxr-xr-x   1 'TSOUSER  IPGROUP  100 Aug 25 13:17 test.rex
/u/tsouser > test.rex
 3 *-* address TSO
 4 *-* Myrc = LISTDSI("'TSOUSER.EXEC'")
   >L>   "'TSOUSER.EXEC'"
 4 +++ Myrc = LISTDSI("'TSOUSER.EXEC'")
IRX0043I Error running ./test.rex, line 4: Routine not found
/u/tsouser >


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 25, 2022 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to use LISTDSI from Rexx under Unix shell?

EXTERNAL EMAIL

The current environment shouldn't matter,  What is the output from Sample code 
to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
trace i
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON

Do the results change if you fully qualify the name?




--
Shmuel (Seymour J.) Metz
https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!PklzQNpdawcFoesdvpTMIAxVFV0YwB_wzbMOiqhtRUydn0TkPM5kN2sOFZL7gnoPboy6U6-8YX_XX-K26lo4PA$
  

____________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, August 24, 2022 11:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to use LISTDSI from Rexx under Unix shell?

Posted earlier today on MVS-OE but got no responses there.

I know this has probably been discussed previously but I can't seem to get the 
Marist MVS-OE archive search to work for me.

Is there any way to use the LISTDSI TSO external function from "address tso" in 
a Rexx program run under the Unix shell?

I can only get it to return RC = -3, "routine not found".  Sample code below.

RTFM seems to indicate that "address tso" in a REXX program run under the Unix 
shell will run a TSO TMP in a separate address space, which is OK, I can 
capture the output from that as needed, but I am not getting any execution of 
LISTDSI at all.

Peter

Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
Address tso
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON


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

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Seymour J Metz]

The current environment shouldn't matter,  What is the output from
Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
trace i
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON

Do the results change if you fully qualify the name?




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, August 24, 2022 11:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to use LISTDSI from Rexx under Unix shell?

Posted earlier today on MVS-OE but got no responses there.

I know this has probably been discussed previously but I can't seem to get the 
Marist MVS-OE archive search to work for me.

Is there any way to use the LISTDSI TSO external function from "address tso" in 
a Rexx program run under the Unix shell?

I can only get it to return RC = -3, "routine not found".  Sample code below.

RTFM seems to indicate that "address tso" in a REXX program run under the Unix 
shell will run a TSO TMP in a separate address space, which is OK, I can 
capture the output from that as needed, but I am not getting any execution of 
LISTDSI at all.

Peter

Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
Address tso
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON


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: How to use LISTDSI from Rexx under Unix shell?

[Kirk Wolf]

You might wish try executing the "catsearch" shell command from Rexx, which is 
part of the Co:Z Toolkit.
This uses IGGCSI00, along with other services to obtain DSCB information.

https://coztoolkit.com/docs/zos-utilities/dsp-ref_catsearch.html

> catsearch  -l user.coz.**
Volume  Referred  Ext  TracksUsed Recfm Lrecl BlkSz Dsorg  Dsname
WORK81 2008/09/24   1  30   ?  U0  6144  PO-E  USER.COZ.LOADLIB
WORK81 2008/09/24   1  15   4  FB  80 27920  POUSER.COZ.SAMPJCL
WORK84 2008/09/11   1   1   1  U0  6144  PSUSER.COZ.TEST.SEQ
WORK81 2008/09/24   1  15   4  FB  80 27920  POUSER.COZ.TESTJCL

Co:Z is free to use under the terms of our Community License.
Enterprise License and Support Agreements also available.
See: http://coztoolkit.com/support.html

Kirk Wolf
Dovetailed Technologies, LLC

Note: Our website and domain name have changed from dovetail.com to 
coztoolkit.com


On Thu, Aug 25, 2022, at 5:02 AM, Michael Babcock wrote:
> Off the top of my head, you might also look at the catalog search
> interface.  Examples in SYS1.SAMPLIB I believe.
> 
> On Wed, Aug 24, 2022 at 10:47 PM Farley, Peter x23353 <
> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Posted earlier today on MVS-OE but got no responses there.
> >
> > I know this has probably been discussed previously but I can't seem to get
> > the Marist MVS-OE archive search to work for me.
> >
> > Is there any way to use the LISTDSI TSO external function from "address
> > tso" in a Rexx program run under the Unix shell?
> >
> > I can only get it to return RC = -3, "routine not found".  Sample code
> > below.
> >
> > RTFM seems to indicate that "address tso" in a REXX program run under the
> > Unix shell will run a TSO TMP in a separate address space, which is OK, I
> > can capture the output from that as needed, but I am not getting any
> > execution of LISTDSI at all.
> >
> > Peter
> >
> > Sample code to get LISTDSI information on 'profilename.EXEC':
> >
> > /* Rexx */
> > Address tso
> > Myrc = LISTDSI('EXEC')
> > Say 'RC='Myrc',reason='SYSREASON
> >
> >
> > 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
> >
> -- 
> Michael Babcock
> OneMain Financial
> z/OS Systems Programmer, Lead
> 
> --
> 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: How to use LISTDSI from Rexx under Unix shell?

[Michael Babcock]

Off the top of my head, you might also look at the catalog search
interface.  Examples in SYS1.SAMPLIB I believe.

On Wed, Aug 24, 2022 at 10:47 PM Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> Posted earlier today on MVS-OE but got no responses there.
>
> I know this has probably been discussed previously but I can't seem to get
> the Marist MVS-OE archive search to work for me.
>
> Is there any way to use the LISTDSI TSO external function from "address
> tso" in a Rexx program run under the Unix shell?
>
> I can only get it to return RC = -3, "routine not found".  Sample code
> below.
>
> RTFM seems to indicate that "address tso" in a REXX program run under the
> Unix shell will run a TSO TMP in a separate address space, which is OK, I
> can capture the output from that as needed, but I am not getting any
> execution of LISTDSI at all.
>
> Peter
>
> Sample code to get LISTDSI information on 'profilename.EXEC':
>
> /* Rexx */
> Address tso
> Myrc = LISTDSI('EXEC')
> Say 'RC='Myrc',reason='SYSREASON
>
>
> 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
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: How to use LISTDSI from Rexx under Unix shell?

[Nobuhiko Furuya]

How about the following ?

  /* REXX */
   X = LISTDSI("'SYS1.MODGEN'" DIRECTORY)
   SAY 'FUNCTION CODE FROM LISTDSI IS: ' X
   SAY 'THE DATA SET NAME IS:  ' SYSDSNAME
   SAY 'THE DEVICE UNIT ON WHICH THE VOLUME RESIDES IS:' SYSUNIT
   SAY 'THE RECORD FORMAT IS:  ' SYSRECFM
   SAY 'THE LOGICAL RECORD LENGTH IS:  ' SYSLRECL
   SAY 'THE BLOCK SIZE IS: ' SYSBLKSIZE
   SAY 'THE ALLOCATION IN SPACE UNITS IS:  ' SYSALLOC
   SAY 'TYPE OF RACF PROTECTION IS:    ' SYSRACFA
   SAY 'THE NUMBER OF ALLOCATED BLOCKS IS: ' SYSADIRBLK
   SAY 'THE NUMBER OF USED BLOCKS IS:  ' SYSUDIRBLK
   SAY 'THE NUMBER OF MEMBER IS:   ' SYSMEMBERS

The result is as folows.

 FUNCTION CODE FROM LISTDSI IS:  0
 THE DATA SET NAME IS:   SYS1.MODGEN
 THE DEVICE UNIT ON WHICH THE VOLUME RESIDES IS: 3390
 THE RECORD FORMAT IS:   FB
 THE LOGICAL RECORD LENGTH IS:   80
 THE BLOCK SIZE IS:  27920
 THE ALLOCATION IN SPACE UNITS IS:   567
 TYPE OF RACF PROTECTION IS: NONE
 THE NUMBER OF ALLOCATED BLOCKS IS:  57
 THE NUMBER OF USED BLOCKS IS:   47
 THE NUMBER OF MEMBER IS:    723

Best regards,

Nobuhiko Furuya(古谷信彦)
V-SOL Inc.

On 2022/08/25 12:44, Farley, Peter x23353 wrote:

Posted earlier today on MVS-OE but got no responses there.

I know this has probably been discussed previously but I can't seem to get the 
Marist MVS-OE archive search to work for me.

Is there any way to use the LISTDSI TSO external function from "address tso" in 
a Rexx program run under the Unix shell?

I can only get it to return RC = -3, "routine not found".  Sample code below.

RTFM seems to indicate that "address tso" in a REXX program run under the Unix 
shell will run a TSO TMP in a separate address space, which is OK, I can capture the 
output from that as needed, but I am not getting any execution of LISTDSI at all.

Peter

Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
Address tso
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON


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

How to use LISTDSI from Rexx under Unix shell?

[Farley, Peter x23353]

Posted earlier today on MVS-OE but got no responses there.

I know this has probably been discussed previously but I can't seem to get the 
Marist MVS-OE archive search to work for me.

Is there any way to use the LISTDSI TSO external function from "address tso" in 
a Rexx program run under the Unix shell?

I can only get it to return RC = -3, "routine not found".  Sample code below.

RTFM seems to indicate that "address tso" in a REXX program run under the Unix 
shell will run a TSO TMP in a separate address space, which is OK, I can 
capture the output from that as needed, but I am not getting any execution of 
LISTDSI at all.

Peter

Sample code to get LISTDSI information on 'profilename.EXEC':

/* Rexx */
Address tso
Myrc = LISTDSI('EXEC')
Say 'RC='Myrc',reason='SYSREASON


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