> 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
