tbray@watsol.waterloo.edu (Tim Bray) (08/31/89)
|| The dreaded JCL requires that you tell the system how long your job || will run, how much memory it will need, and any resources like tape || drives that you will be using... |I think that it |would be fairly widely agreed that generally it is not known either how |much memory will be required, nor how long a program will run... I'm not sure I buy this. The people in this forum perhaps have somewhat distorted perspectives; in R&D mode, you're is often surprised by the characteristics of the program you're running, particularly if you just wrote it. Anyhow I am. On the other hand, in the real world out there, where the majority of jobs are production mode doing real work, it is often the case that people have a pretty good idea what resources are required for some big job (I exclude small jobs from this discussion). E.g., a lot of HW designers, when they're iterating a design, know pretty well how long their next Spice-or-some-relative is going to run and how big it's going to get. The same holds, only more so, for DP type stuff like accounting/payroll/GL etc, yecch. And this is particularly true for highly-tuned database and transaction processing applications. In fact, the OS doesn't have anywhere near the insight the user (or at least system manager) does. Given this, the addition of ***OPTIONAL*** JCL-type info which could be made available to the scheduler might be a big win. In situations like the one Henry Spencer mentioned, and in many others, the OS doesn't really have a hope. But if somebody told it: #27 here is going to pound the hell out of /usr/app1, while #45 is going to access 23 Mb of VM nonlocally, and #72 is memory-lean and heavily compute-bound, then the OS might be able to do some pretty clever things. When you don't know the info, you don't give it, and the OS does the best it can. If do know it, why waste it? Providing it doesn't seem too onerous, particularly if this is the kind of thing that gets run every Thursday at 10:30 P.M... Cheers, Tim Bray, New OED Project, U of Waterloo