On Thu, 15 Sep 2022 22:19:40 +0000, Farley, Peter x23353 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
