>Jobname must be protecting access to something, else what's the point of >enforcing jobname rules and the intense concern that test programmers not use >production jobnames?
Jobname are often used by job schedulers to control production streams. Would you like your app people to accidentally fire off a night stream in the middle of the day? Also, ops and automation, can more easily monitor jobs rather than accounts and owners. EG: 'hey! Accounts Payable is running before Accounts Receivable is done!' OR: 'Staff Payroll abended -- priority 1!' >Prior plies in this thread suggest that in some chargeback shops jobname is >used to protect access to funds in those charged accounts. But this could be >likewise based on OWNER (userid?). And isn't there an ACCOUNT parameter on the >JOB statement which seems to be designed for this purpose? Lots of those choices are viable. I find that there are more credible choices, such as account, but using jobnames is feasible (not required) if there is enforcement. And, standard jobnames can help if there is a problem, and wouldn't we prefer to know quickly, rather than have to spend the time looking up OWNER or ACCOUNT? It all depends on what standards your management wishes to enforce. I, myself, prefer easily identifiable ID's, for TSO (for example), such as MISEAM (at my last shop -- MIS dept -- my initials), as opposed to EDWARD (my first shop -- my real first name -- no idea which department from the ID). - Too busy driving to stop for gas! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
