Re: How to use LISTDSI from Rexx under Unix shell?
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?
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?
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?
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?
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" 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
Re: PEngiEZT contact
Twenty years ago I was in contact with Seecko Lazanja from foundation software. Try to find his email. ITschak בתאריך יום ו׳, 7 באוק׳ 2022 ב-21:46 מאת Schmitt, Michael < michael.schm...@dxc.com>: > (Let me know if there's a more appropriate list to post to) > > There's a product PEngiEZT for Easytrieve to COBOL conversion: > > http://www.pengi.com/pengiweb-0.2.prd.env/www/web/html/PEngiUser.shtml > > I want to find out more about licensing and platform options, but the web > site's contact link is broken! > > Does this company still exist? Does anyone have a contact? > > Note: I'm aware that IBM has licensed this technology for use in the IBM > Migration Aid for z/OS, but what I want to do is run the conversion program > on a different platform than z/OS. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM Question
I sent Steve a copy offline. It was on a Classic SMS Redbooks CD I found and the CD also contains the books in the conversion series. The -01 version was dated September 1999, updated February 2000. On Sat, 8 Oct 2022 at 12:25, Paul Gorlinsky wrote: > BTW There are other Redbooks in this same area. For example Converting to > DFSMSrmm from CA-1 ( SG24-6241-01 ) > > -- > 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: RMM Question
BTW There are other Redbooks in this same area. For example Converting to DFSMSrmm from CA-1 ( SG24-6241-01 ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: RMM Question
On 6/10/2022 19:07, Steve Beaver wrote: Does anyone in the group have the following Redbook on their PC or Laptop SG24-4998-01, Converting to Removable Media Manager: A Practical Guide I migth have it on a backup. Any idea of the date? Best regards. j@n. -- 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
