Michael, You nailed the cause there! My suspicion is zero or no *experienced* TSO/E guys in the TSO/E group @ IBM...
Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Thu, Oct 23, 2025 at 2:02 PM Schmitt, Michael < [email protected]> wrote: > > Does anyone else think this is stupid? > > Yes, I posted a rant to this list last year about this very subject. > (subject IRXJCL with sequential SYSEXEC, on 7/12/2024) > > Here's what I posted... > > > -------------------------------------------------------------------------------- > I'm on zOS 2.5 now, which has the new feature of allowing the exec for > PGM=IRXJCL to be a sequential file, rather than a member of a PDS. The DD > is still SYSEXEC. > > The natural way to code this is: > > //JS010 EXEC PGM=IRXJCL > //SYSTSIN DD DUMMY,DISP=SHR > //SYSTSPRT DD SYSOUT=* > //SYSEXEC DD * > SAY 'HELLO, WORLD!' > /* > > Bzzt. Nope, that's a R3637. > > Time to read the documentation, which is here: > https://www.ibm.com/docs/en/zos/2.5.0?topic=ir-using-irxjcl-run-rexx-exec-in-mvs-batch > > What I'd expect to see is documentation of the PARM values, and > documentation for each of the DDs, including SYSEXEC. There isn't any; it > is just a narrative, which specifically says that the parm must: > > "Specify the member name of the exec and one argument you want to pass > to the exec in the PARM field on the EXEC statement. You can specify only > the name of a member of a PDS." > > And for SYSEXEC (which actually could be a different DD name, determined > by the module name table) is only referred as pointing to a PDS. > > > What you're supposed to do is ignore what's in the "Using IRXJCL to run a > REXX exec in MVS batch" topic and read the next topic: > > > https://www.ibm.com/docs/en/zos/2.5.0?topic=routine-using-irxjcl-execute-in-stream-rexx-exec > > which serves as kind of an errata to the previous topic. Here we learn > that to get this to work, you must code the PARM string, but with one to > eight x'00' for the member name field! > > > My questions are: > > 1. Why such an obscure method of saying that the SYSEXEC is sequential? > Why not, oh I don't know, process SYSEXEC as sequential if the organization > of SYSEXEC is sequential? > > 2. If it must be that it uses the PARM value to know that it is > sequential, why does it use a member name of x'00'? Can you think of ANY > other user-facing utility that works this way? I mean, something users put > in JCL, not some program API. > > 3. Why was the documentation not fully updated? This is documentation by > counter-example. > > 4. And, why doesn't the documentation for "Return code for IRXJCL routine" > > https://www.ibm.com/docs/en/zos/2.5.0?topic=ir-return-codes > > list 3637 as a return code and document what it means? The meaning of > R3637 is documented in return code 20021, which you would only find if you > READ THE COMPLETE DESCRIPTION OF THE RETURN CODE YOU DIDN'T GET. > > This makes no sense. The entire topic is about running IRXJCL in MVS > batch, so you're never going to see 20021. It should document the return > code you will get. If it wants to explain what you might get if running > IRXJCL a different way, then *that* should be in the Notes. > > -------------------------------------------------------------------------------- > > Then there was some follow-up discussion, theorizing that the weird > behavior is related to some internal processing where there was already > code that used a member name of x'00' to mean read SYSEXEC as sequential. > > And that then: > > 1. There's enhancement requests submitted: "Why can't we use IRXJCL with > an instream data or other sequential file?" > > 2. IBM finally decides to accede to the enhancement requests. They send > this to Development: "Allow sequential input to IRXJCL". > > 3. Development says, hey all we need to do is document the secret internal > hack, and we can go home early! > > So they do the absolute least amount of work: just add a new topic to the > documentation, that documents the kludge. > > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Mike Shaw > Sent: Thursday, October 23, 2025 12:45 PM > To: [email protected] > Subject: IRXJCL oddity > > Everyone, > > I saw this <https://www.ibm.com/docs/en/SSLTBW_3.2.0/pdf/ikja300_v3r2.pdf> > gem in the z/OS V3R2 Rexx Reference (page 248) and I could not believe it. > It dates back to z/OS V2R5. > > If you invoke IRXJCL to execute a Rexx exec in batch, and you want the Rexx > interpreter to treat SYSEXEC as a sequential input file instead of as a > partitioned data set, then you code the JCL PARM= field as a BINARY ZERO > between single quotes! If that is done, IRXJCL opens the SYSEXEC file and > reads in the exec within it and then interprets it. To pass an argument to > the exec, you code PARM= as a single BINARY ZERO followed by the argument > for the exec. > > Does anyone else think this is stupid? Instead of IBM adding code to IRXJCL > so that it checks the SYSEXEC DD to see if it is DSORG=PS and then acting > accordingly if it is, the user is supposed to edit their JCL PARM= field > 'HEX ON' and type in a binary zero (which displays as a blank under ISPF) > between single quotes to tell IRXJCL to treat SYSEXEC as a sequential file. > > I don't get it... > > Mike Shaw > MVS/QuickRef Support Group > Chicago-Soft, Ltd. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
