JCL, TSO and UNIX are very different by nature. While they all are controlled by WLM, WLM handles their defaults differently. TSO has a user who won't tolerate the screen being locked because they want to continue working. JCL is disconnected from the user and the user is willing for the job to complete. JCL has accounting information and user information which can influence priority. As for UNIX, WLM can control the address space but it wasn't (maybe it does now) granular enough to be able to differentiate the work. The best example is using MAKE for a single program versus an entire product. It spawns so many processes it would overwhelm our dev machine.
tail -f requires you send output to a file and you remember that file name. SYSOUT= is far easier to work with than using separate datasets. Having SYSOUT seperated in to each DD allows us to easily and quickly switch between DD's. E.g. joblog shows my job hasn't completed but a couple assemblies have non-0 CC, I can easily look at the SYSTERM output to fix the problem. With UNIX MAKE, I found myself using GREP and various utilities to verify success. It always seemed to take longer. As for comparing job log to manually logging information, they are worlds apart. JCL has CC's for each step and if you implement CC display in the job log. Almost everyone has this installed. It's automatic and I can quickly find the steps that have non-0 CC without manually logging it. Jon Perryman. >________________________________ > From: Paul Gilmartin <paulgboul...@aim.com> > > >How does WLM depend on JCL? Doesn't it work alike for TSO and UNIX sessions? > > >3. It allows you the ability to look at how a job is proceeding (SDSF). >> >"tail -f" allows monitoring any output file, not those arbitrarily designated >as "spool" files. I find the entire distinction between "spool" files and >other >data sets artificial and obstructive. > >>4. It segregates output into job steps and DD's making it easier to find the >>information you desire. Much more difficult to do in TSO. >> >Characteristic of the declarative as opposed to procedural nature of JCL, yes. > >>5. It has a job log which usually contains a summary of return codes to >>quickly determine if anything failed. (IEFACTRT). >> >In a procedural scripting language, I can log what I want, in the format >I want. And I truly wish I could direct the JES logs to UNIX files as an >alternative to the "spool". > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
