Still waiting for a reply on my requesting the sources from some 2+ months ago.
Vince On 23/12/15 23:54, Clem Clarke wrote: > Gil, if you hate JCL, why not look at Jol? With simple English like > syntax. > > It does more than JCL, run in backgound/batch or you can execute jobs > under TSO. > > It has a simple PANEL instruction to make interactive screens. > > You can pass Symbolic Parameters from job to job. > > It has a Scheduling Facility. > > There are versions that run under Z/OS, Windows and Linux - even > OS/2. The Windows and Linux versions will create JCL or TSO pseudo > code OR execute programs on Windows and Linux. > > See http://start.oscar-jol.com/ > > Cheers, > > Clem Clarke > > much what JCLPaul Gilmartin wrote: >> On 2015-12-23, at 05:44, R.S. wrote: >>>> I hate JCL! >>> Just curious: why do you need to insert SET into DD concatenation? >>> >> No "need" just style for clarity. I could have put all my SET >> statements a hundred lines earlier, immediately after JOB. Instead >> I thought my JCL would be easiest to read if I placed each as close >> as possible to the references to its value. See modified example >> below. >> >> >> On 2015-12-23, at 05:55, Hardee, Chuck wrote: >> >>> The reason is that the Converter/Interpreter is expecting data as a >>> result of the "//DD2 DD *". >>> It found none so it is now looking for a new "starting" JCL statement. >>> It found one, the "// SET" statement. >>> After processing the "// SET" statement it again looks for a new >>> "starting" statement. >>> It didn't find one, at least not syntactically correct. It >>> recognized the next statement "// DD ...." as a DD statement, but >>> since the previous DD had been terminated by the "// SET", the JCL >>> rules call for the first DD in a concatenation (even a concatenation >>> of 1 DD statement) to have a label. This DD does not have a label so >>> it is assumed to be a continuation, but there is no logically >>> "active" DD in effect so, you get the "misplaced DD statement" error. >>> >>> Make sense? >>> >> No. >> >> I routinely code empty SYSIN, perhaps just to save keystrokes, as in: >> >> //STEP EXEC PGM=IEBGENER >> //SYSIN DD * # Nothing here; works fine. >> //SYSPRINT DD SYSOUT=(,) >> ... >> And my rewritten example: >> //* >> 3 //STEP EXEC PGM=IEFBR14 >> //* >> 4 //DD1 DD * # "DD *" with no data is just fine. >> 5 // DD * >> //* >> 6 // SET V1=WOMBAT >> 7 // DD PATH='/tmp/&V1' >> //* >> IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT' >> 8 // SET V2=XYZZY >> 9 // DD PATH='/tmp/&V2' >> //* >> IEFC653I SUBSTITUTION JCL - PATH='/tmp/XYZZY' >> 10 //DD2 DD * >> 11 // SET V3=WOMBAT >> 12 // DD PATH='/tmp/&V3' >> IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT' >> 13 // >> STMT NO. MESSAGE >> 12 IEFC019I MISPLACED DD STATEMENT >> ******************************** BOTTOM OF DATA ********************** >> >> All the assertions you make should have been equally true of the empty >> instream data sets at line 4 or line 5. Why does the C/I accept those >> but reject the one at line 12? >> >> I invite, even challenge, any IBM representative to provide a plausible >> rationale for the restriction in the Reference that Lizette and I cited. >> How does that rule benefit customers? Rather, it makes the Reference >> thicker, increases the learning burden on programmers, and engenders an >> unpleasant Astonishment Factor. I suspect it arose througn no >> purposeful >> design, but through developer ineptitude and indolence. It didn't work >> as intended, so they documented it and called it a feature. >> >> I hate JCL! >> >> -- gil >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- - IMPORTANT – This email and the information in it may be confidential, legally privileged and/or protected by law. It is intended solely for the use of the person to whom it is addressed. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Please also delete all copies of this email & any attachments from your system. If this is an encrypted email it is your responsibility to maintain the 1024 byte key system even for one-use keys. Once mail has been sent the sending key is not kept and therefore a replacement mail cannot be resent. We cannot guarantee the security or confidentiality of non encrypted email communications. We do not accept any liability for losses or damages that you may suffer as a result of your receipt of this email including but not limited to computer service or system failure, access delays or interruption, data non-delivery or mis-delivery, computer viruses or other harmful components. Copyright in this email and any attachments belongs to Applewood Computers. Should you communicate with anyone at Applewood Computers by email, you consent to us monitoring and reading any such correspondence. Nothing in this email shall be taken or read as suggesting, proposing or relating to any agreement concerted practice or other practice that could infringe UK or EC competition legislation (unless it is against Security requirements). This Email and its attachments (if any) are scanned for virii using Clamd and ClamAV 0.98.8 or later (Linux x64). Dykegrove Limited T/A Applewood Computers is a company registered in England (no. 01681349) whose registered office is at Applewood House, Epping Road, Roydon, Essex, CM19 5DA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
