Re: Variable length records for SYSIN data sets
How the internal reader handles instream data sets is documented here: https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-record-length-sysin-data-sets https://www.ibm.com/docs/en/zos/2.4.0?topic=reader-sysin-record-formats Also note that JES2 and JES3 work differently. But bottom line, for JES2, everything is based on the actual length of each record written. This gets a little tricky with TSO SUBMIT (or ISPF SUBMIT) commands. SUBMIT always writes records with a record length of 80. So all instream data sets are RECFM F and LRECL 80 when SUBMIT is involved. For other uses of the internal reader, as already stated, the RECFM is F if all records are the same length (including if there are 0 or 1 records). If the lengths of the record vary, the RECFM is V. CC is supported if the JCL (records) are written with CC (eg using IEBGENER from a RECFM VBM data set) and the RECFM is adjusted accordingly (fun rules for if there are both ASA and machine CC). Instream data set LRECL for RECFM F data sets is the length of the records. If there are 0 records (null data set), it is the length of the DD * or DD DATA card (very old rule). For RECFM V data sets, the LRECL is set to the length of the longest record in the instream data. Note for all of this, each instream data set is processed separately. So each data set can have a different LRECL/RECFM. As for LRECL on the DD * or DD DATA card, JES2 ignored this until APAR OA60172. Starting with that APAR, if an instream data set is RECFM F and LRECL is specified, JES2 will pad records for the data set up to the LRECL specified. This helps when using instream data concatenated to other RECFM F data sets. This is not to say that LRECL was totally ignored on a DD * or DD DATA card. When the DCB access method is used to read an instream data set (vs ACB/RPLs), the size of the buffer the access method passes to JES is determined by the LRECL specified on the DD. Also note that in a concatenation, the RECFM is determined by the first DD in the concatenation. A customer trying to concatenate a RECFM V data set to a RECFM F instream data set with LRECL specified led to APAR OA62088. You see the fix for APAR OA60172 added too much padding to an instream data set. Basically, LRECL on the instream DD statement in that case included the 4 byte RDW prefix but the ACB/RPL interface passes the actual length so padding to LRECL made the record 4 bytes too long. Hopefully this enlightens a bit on how all this works. Tom JES2 Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running same stc in a LPAR
You can allow duplicate jobs to run based on JOBCLASS (DUPL_JOB=DELAY|NODELAY as of z/OS 1.7 - 2005), at a system level (JOBDEF DUPL_JOB=DELAY|NODELAY as of OS/390 release 3 - 1997) and with z/OS 2.4, you can exempt a particular job from duplicate job delays using the JES2 POLICY function. Tom Wasik -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ulli Theimann
For those that may have known Ulli Thiemann from IBM Health Checker and JES3 (and a number of SHARE presentations), he passed unexpectedly this past Friday morning (June 28). Obituary and other information can be found here: https://www.ranfranzandvinefh.com/obituary/319012/Ulrich-Thiemann/ Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: INTERNAL Cancel Command
JES2, internally, issues MVS CANCEL commands. In SYSLOG you would see: NC000 SY1 18268 17:10:52.26 INTERNAL 0290 CANCEL WTORTST,A=0026 This is the result of a $CJ JES2 command. You could look for one of those (and it could have been issued on another member of the JESPLEX). Tom Wasik -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBM to stabilize JES3 (was: IBM to finally drop JES3)
I apologize if my presentation on the JES2 support for the //*NET statement led you to believe that existing DJC NETs will get JCL errors when run in JES2. There are keywords that JES2 ignores, but they do not generate errors (they generate warning message in the JCL output but warning message in JES2 do not stop the job from successfully converting and running). For the records, JES2 supports the keywords that make sense in a JES2 environment (NETID, NHOLD, RELEASE, NETREL, NORMAL, ABNORMAL, ABCMP, NRCMP, OPHOLD). The other keywords that don't make sense in a JES2 environment (DEVPOOL, DEVRELSE, RELSCHCT) are ignored (minimal syntax validation is done) but do NOT generate JCL errors. JES2 support is complete for the supported keywords and was made to work like the JES3 support. In general, the implementation of JES3 JECL was based on what JES3 does (not what the books say) in an effort to be as compatible as we could. However, JES2's parsing of JECL is done using a generalized parser that may be stricter than what is used by JES3 (JES3 may detect JECL syntax errors that JES3 allows). Also, the character set for things like NETID may be different between JES3 and JES2 because JES2 uses the NETID as the name of a JOBGROUP (it must be a valid job name). For example, JES3 supports NETID=Z*+X but JES2 would JCL error because of the * and the +. I hope this clarifies what we support. Tom Wasik JES Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Symbols in SYSIN syntax
The removal of the '.' is inappropriate. If the symbol is not recognized, it should be left alone (and the '.' not removed). This only seems to occur when you specify CNVTSYS or EXECSYS. It is related to how the instream substitution service interacts with the system symbol service. If you can open a PMR against JES2, the JES2 team will investigate changing this behavior. As for the '&&' being converted to '&' that was a long internal debate. The concern was that the instream data is being fed to a service that may also be doing substitution. We were thinking of things like the high level assembler. The intent may be that the double && was intended for that service. The instream process removing that could cause problems later down the line. So it was decided that the instream substitution service would NOT un-double the &. Also note that there is another oversight that was pointed out. The &SYSUID symbol is not being substituted in the instream data. That should have been done. OA45995 was created to correct that oversight. I mention this because you happened to use &USER in your JCL. Until the APAR is available, you could set USER=&SYSUID or even SYSUID=&SYSUID Tom Wasik JES2 Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 Last date to order ServerPac
This is where I go to get end of service/end of marketing dates: http://www-03.ibm.com/systems/z/os/zos/support/zos_eos_dates.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:
>It there aren't enough blanks to compress out, will the line be extended, possibly reallocating a buffer if necessary? (I'm assuming RECFM=VB for the SYSIN. If there are not enough blanks, then the length of the line is extended. If the application or utility passes in a large enough buffer, the full record is passed (with the correct length). If not large enough, then an I/O error (buffer too small) is returned. Application that read SPOOL using ACBs/RPLs (not really documented) are passed the actual length and they can come back in with a larger buffer and get the full record. DCB interface is probably going to just fail. >So the value of a very dynamic system symbol such as TIME could vary from line to line within the same SYSIN? Yes, that is true. If you need it to be static, then set a JCL variable to the value and use that as variable in the instream data set. You can now use system symbols in batch JCL. More detail will be presented at the next SHARE so come to Boston and learn a lot more. Tom Wasik JES2 Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:
The SYMBOLS= keyword is on the DD DATA or DD * JCL. It controls what symbols are substituted in the instream data sets ... so yes, in places like: REPRO INFILE(GIMZPOOL) + OUTDATASET(&HLQ..GLOBAL.CSI) The way the substitution works is it looks to compress blanks to the right of the symbol. It will compress strings down to 1 characters trying to keep characters in the same column that they are in. The substitution happens "just in time" as the application is running to pick up the latest JES symbols. JES symbols are dynamic as opposed to JCL symbols that are static. I did not mention PARMDD because it did not hit JES2 at all so there was nothing to really talk about. Tom JES2 Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rejoice! z/OS 2.1 addresses some long term JCL complaints from here:
If you are interested, there is some additional detail on the 2.1 JES2 JCL changes in my SHARE pitch from this week: http://share.confex.com/share/120/webprogram/Handout/Session13029/JES2%20Product%20Update%20and%20Latest%20Status.pdf Tom Wasik JES2 Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
