Re: omvs man pages

2022-09-15 Thread Michael Babcock 
Yes exactly what I did.  I added the rocket paths to the MANPATH in
/etc/profile.

On Thu, Sep 15, 2022 at 3:10 PM Peter Sylvester 
wrote:

> Yes, the rocket anaconda stuff has man files that you can add to MANPATH.
>
> in OMVS /etc/profile
>
> # ==
> #MANPATH environment variable
> #
> # Specifies the list of directories that the system searches for man
> # pages (help files). The %L represents the language currently set by
> # the LANG environment variable.
> # ==
> MANPATH=/usr/man/%L
> export MANPATH
>
>
> And you can activate you current conda environment, or well, assuming you
> have the rocket software in a file system in $RSOFT and your current
> conda environment is xyz, then add
>
> $RSOFT/envs/xyz/share/man into MANPATH wherever you may want it.
>
> There are other man for IBM products.
>
> Peter
>
>
>
> //
>
>
> --
> 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?

2022-09-15 Thread 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?

2022-09-15 Thread 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 "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 *-

Re: omvs man pages

2022-09-15 Thread Peter Sylvester 

Yes, the rocket anaconda stuff has man files that you can add to MANPATH.

in OMVS /etc/profile

# ==
#MANPATH environment variable
#
# Specifies the list of directories that the system searches for man
# pages (help files). The %L represents the language currently set by
# the LANG environment variable.
# ==
MANPATH=/usr/man/%L
export MANPATH


And you can activate you current conda environment, or well, assuming you
have the rocket software in a file system in $RSOFT and your current
conda environment is xyz, then add

$RSOFT/envs/xyz/share/man into MANPATH wherever you may want it.

There are other man for IBM products.

Peter



//


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

Re: omvs man pages

2022-09-15 Thread Paul Gilmartin 
On Thu, 15 Sep 2022 21:34:34 +0200, Peter Sylvester wrote:
>>>
>> A more recent edition: 
>> 
>>
>>> BUT - is there a way to update this with additional man pages - say some
>> >from Rocket (i.e. curl) ?M
>
>> Bummer.  I would have hoped for something such as
>>  MANPATH=/usr/man/%L:/usr/lpp/com.rocketsoftward/man
>
>You have that ${ROCKET_FS}/envs/whatever/share/man
>
On Thu, 15 Sep 2022 14:24:39 -0500, Michael Babcock wrote:

>I added the rocket stuff to my MANPATH in my global profile.
>
Please be explicit, perhaps:
MANPATH=/usr/man/%L:${ROCKET_FS}/envs/whatever/share/man
???

-- 
gil

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

Re: omvs man pages

2022-09-15 Thread Peter Sylvester 

On 15/09/2022 21:18, Paul Gilmartin wrote:

On Thu, 15 Sep 2022 13:56:38 -0500, Lionel B. Dyck wrote:


This explains how to enable the man pages in omvs
https://www.ibm.com/docs/en/zos/2.1.0?topic=utilities-enabling-man-pages


A more recent edition: 



BUT - is there a way to update this with additional man pages - say some

>from Rocket (i.e. curl) ?M



Alas, I see: 
:
 ...
 The historical MANPATH variable is not included in POSIX because no 
attempt is
 made to specify naming conventions for reference page files, nor even to 
mandate
 that they are files at all.

Bummer.  I would have hoped for something such as
 MANPATH=/usr/man/%L:/usr/lpp/com.rocketsoftward/man


You have that ${ROCKET_FS}/envs/whatever/share/man

Peter

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

Re: omvs man pages

2022-09-15 Thread Michael Babcock 
I added the rocket stuff to my MANPATH in my global profile.

On Thu, Sep 15, 2022 at 1:57 PM Lionel B. Dyck  wrote:

> This explains how to enable the man pages in omvs
> https://www.ibm.com/docs/en/zos/2.1.0?topic=utilities-enabling-man-pages
>
> BUT - is there a way to update this with additional man pages - say some
> from Rocket (i.e. curl) ?
>
> Thanks
>
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
>
> “Worry more about your character than your reputation. Character is what
> you
> are, reputation merely what others think you are.”   - - - John Wooden
>
> --
> 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: omvs man pages

2022-09-15 Thread Paul Gilmartin 
On Thu, 15 Sep 2022 13:56:38 -0500, Lionel B. Dyck wrote:

>This explains how to enable the man pages in omvs
>https://www.ibm.com/docs/en/zos/2.1.0?topic=utilities-enabling-man-pages
>
A more recent edition: 


>BUT - is there a way to update this with additional man pages - say some
>from Rocket (i.e. curl) ?
>
Alas, I see: 
:
...
The historical MANPATH variable is not included in POSIX because no attempt 
is
made to specify naming conventions for reference page files, nor even to 
mandate
that they are files at all. 

Bummer.  I would have hoped for something such as
MANPATH=/usr/man/%L:/usr/lpp/com.rocketsoftward/man

Are the Bookie pages formatted on-the-fly or are formatted versions cached?

>Lionel B. Dyck <><
>Website: https://www.lbdsoftware.com
>Github: https://github.com/lbdyck

-- 
gil

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

omvs man pages

2022-09-15 Thread Lionel B. Dyck 
This explains how to enable the man pages in omvs
https://www.ibm.com/docs/en/zos/2.1.0?topic=utilities-enabling-man-pages

BUT - is there a way to update this with additional man pages - say some
from Rocket (i.e. curl) ?

Thanks


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.”   - - - John Wooden

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

Re: z/OSMF and Health Checker butting heads

2022-09-15 Thread Peter Relson 
This is what I am told:

z/OSMF does not introduce a new default console definition. The default console 
definition used by z/OSMF is the default value of the OPERPARM segment in SAF. 
For instance, ROUTCODE would default to NONE. z/OSMF has a sample job which 
contains a sample command to set up OPERPARM. Although that sample command is 
using ROUTCODE(all), it is a sample, not a default value.

Perhaps you used the sample as-is and defined OPERPARM thusly.

Regardless, we'll look into either changing the sample or commenting that this 
sample should not be used as-is for whatever reasons.

Peter Relson
z/OS Core Technology Design


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