I have given this thread a new name. So flame me... ;-) Strange no one came with another reason why duplicate jobnames are to be prohibited or allowed.
It is about resource usage. If you have limited resources, it is better to have your jobs running in sequence. At my site we have limited resources over the years. Anything from CPU, storage, tapes, diskspace. Name it, you get it. Sometimes, not always, having fewer jobs by limiting inits and by having jobs to be named so they consume resources one by one, not together, we could get things going. We have learned to stay with prohibiting duplicate jobs running together. Mind you, we ALLOW duplicate TSO ids across the SysPlex. All those methods mentioned in that thread - by enqueing, scheduler, etc. are also good aids. Sometimes one solution is better than other depending on what you're trying to solve. Some one said they are not using a scheduler in a test LPAR. I beg to differ. :-( We are also using a scheduler on a test LPAR - we want to see how the product(s) behave in test LPAR before we move it to production LPAR. So, each to its own. YMMV of course. Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
