Johnny The two verbs of interest here are "monitor" and "notify" and the adjectives are "active" and "passive". Note I'm not necessarily using "official" language here.
What your REXX logic is doing is "actively monitoring" the status of your job. What products such as that Tivoli product are doing is waiting "passively" to be "notified" of the end of the job. I expect such a product will arrange to intercept the message which indicates that a job has completed, check whether or not the name of the job is the one for which it is waiting - possibly with more precise checks - and then continue. I used to do something like this at one time with NetView message automation. NetView had a "hook" into the MVS message flow so that it "saw" each message as if passed by within MVS and so could match the message with a table of messages set up by the person performing the NetView automation. For some reason, I used to add a job step with a program which simply issued the message as coded in the PARM field of the EXEC statement - I believe I called it WTOPARM. Thus I didn't have to mess about analysing the message indicating a job had completed and I could be more precise. The "loop" is actually a good name for what actually happens inside MVS but not in the sense you imagine. As I remember it, the way messages are handled within MVS involves first a message is created all in one place from WTO (or WTOR) - and just possibly some other places the cognoscenti still reading may be able to fill in. Then the message goes on a circuit visiting all the logic "hooks" of programs which might have an interest in messages. Quite why it is described as a circuit is a bit of a mystery for me since it doesn't need to return to its origin - or does it? Maybe it does as a way of knowing that it has visited all the places it was supposed to go - who knows? Thus there is no repetitive "active monitoring"; there is only "passive notification" because a "notification" mechanism is available and the only "active" activity is the single event when the message is created. Incidentally, when using "active monitoring", if you don't ask very often, say once every 5 minutes, nobody should complain. On the other hand each of your job submissions will wait, on average, close on 2 1/2 minutes longer than it would with, say, a 5 second interval. Until now we have been talking about messages. Your reference to the system being dead is another matter. Let's keep to the classic processor and channel model I grew up with and which I expect, in general, is mimicked with more recent hardware that is not so obviously described as "channel". When the central processor wants to read or write to external specialised input/output processors, it just points to a list of channel command words (CCWs) and tells the channel processor to get on with it - the start I/O instruction (SIO) if I'm not too senile to remember it properly. To keep it all as simple as possible, when the channel has finished what it is doing it will "interrupt" the central processor. The "interruption" may happen at any time obviously - strictly between instruction execution (again there are probably exceptions some may wish to mention) - and so the logic which handles the "interruption" knows to be careful with remembering what the processor was doing when "interrupted" - and this reminds me that one exception is that the central processor can insist it is not "interrupted" while remembering what it was doing when processing an "interruption". It may be that the central processor is so lightly loaded that it has nothing to do while waiting for the next interruption and so it loads a program status word (PSW) with the "wait" bit set. On the old 360/30s running DOS (now VSE) that I first got to know, there was a light on the console which came on when the "wait" bit was set in the PSW. This way you got some idea how busy the central processor was. Clearly, when the next "interrupt" came along, the logic which handles the "interruption" can very quickly work out that there's nothing to do but pass control, enabled for "interruptions", to the logic which schedules the highest priority task to resume execution, generally the task that was "waiting" (the WAIT macro) for the I/O corresponding to the newly arrived "interrupt". I also worked with BOS (Basic Operating System) and BPS-Tape (Basic Programming System- Tape). These operating systems were a bit cruder that DOS and did actually have an idle loop - such as you have been surmising - rather than loading a PSW with the "wait" bit. I don't know why. I was once involved with a benchmark using the BPS-Tape operating system and the only way I knew I had optimised to the maximum - by needing fewer and fewer passes of the tape during program execution - was not by extinguishing the "wait light", the indicator I had got used to with DOS, but by the relative rotational velocity of the tapes in the tape drives - another trip down memory lane! Incidentally I expect your famous loop is there somewhere even when the "wait light" is on but by now it's deep within the central processor and I/O channel hardware. I'm not sure about CICS pseudo-conversational - I believe I once knew something about IMS pseudo-conversational. Probably you really don't need to worry too much about CICS itself. This is probably all a matter of how MVS, for example, and programs running under MVS handle tasks. If programs create tasks which MVS knows about - with the ATTACH macro - then the individual tasks will be "dead" when they issue the WAIT macro but will be dispatched by MVS when whatever they were waiting for - as expressed by the list of event control blocks (ECBs) - is ready. Thus the task is "dead" but MVS is alive and knows how to revive the task. Note I said a *list* of ECBs just now. If a program wants each task to be an MVS task, there will only be one ECB representing a "wait" the completion of the next, typically, I/O event before the task can continue. It may be that a program does not want to use the overhead of the MVS task switching facilities and so doesn't use the ATTACH macro. In place of creating additional MVS tasks, *all* pending events can be represented in the ECB list and the main - and only - task, corresponding to the program started by and named on the EXEC statement, manages the logically individual tasks totally within the program logic. In other words, as far as MVS is concerned, there is only one task but, as far as the logic of the program is concerned and, if it presents an API, as far as all the users of the API are concerned, there are many tasks, with the significance, where there is an API, of one task for each user of the API. To some extent it was in order to provide a generalised way of managing logical tasks within a single MVS task that gave rise to CICS as it was in the early '70s. The main event that a program using this organisation, called the "multiple wait", needed to handle was the delay while the incredibly slow human operator bothered to think about what to do next, enter the characters and finally, after an age, hit the "Enter" key - which finally caused the ECB to be set and one of the ECBs in the "multiple wait" list to indicate a logical task was ready. However, as well as waiting for terminal user input, output to the terminal and any disk I/O was handled in the same way, "waiting" on an ECB. Before CICS, there was a country-specific program to help with this problem of efficiently handling communication with terminal devices operated by those slow human beings, BATS - the interpretation of which I forget since I have now traveled far too far down that memory lane! You may not be familiar with the use of the WAIT macro but it's there whenever you use I/O facilities in your program. For example, if you are using GET and PUT macros in an Assembler program, the logic supporting blocking or unblocking the records you "get" or "put" will need to issue the WAIT macro - and your program is doing nothing - is logically "dead" - to wait for a block to be read or written. If you have more than one buffer area you can be processing one block of records while another block is being transferred to/from the DASD but, unless you have a 360/25 and a highly optimised examination results analysis program such as I was benchmarking under the BPS-Tape operating system, some I/O logic associated with your task will be issuing the WAIT macro from time to time. Chris Mason ----- Original Message ----- From: "Johnny Luo" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Saturday, 23 December, 2006 1:46 PM Subject: Re: ftp job submission > Chris, you seem to know everything about VTAM, SNA, TCPIP -_- > > Your reply reminds me of something I did two months ago(Sorry, it may be a > little off-topic) > > That time I wrote a rexx exec to submit one JCL job and after that it'll > keep on querying the status of the job. And if it successfully ends, the > exec will submit another jcl. Just like that. > > Of course I know this exec is just a toy and it can never be put on > production system. Or the sytem programmer will call me:) > > Later on I began to learn HLASM and tried to find out whether there is a > smarter way to do this using system service. However, i cannot find one. > > I also searched the internet and found there're so many topics about this > and there is not a easy solution. > > Obviously the most difficult part is: after submitting the job, how my > program will know when the job will finish? The easiest answer is 'keeping > on doing something'. But on a production sytem it's just untolerable > cosidering the fact that the previous job may need hours to complete. > > However, I'm just curious about this because I know some softwares like > Tivoli Workload Scheduler can do this job. Then, how TWS did that? If they > use 'loop' too, why I cannot? > > I talked this to one of my friend and his opinion is that there is nothing > special with these production softwares. They still have to use some 'loop' > there. > > 'If everything is dead, then the sytem is dead. Am I right?' My firend told > me. 'So there must be somthing alive. How they keep themself alive? Loop. > Just they did that more efficient. That's the only difference'. > > Sounds like a reasonable explanation? And it made me think of the CICS > programs. > > They say CICS program is pseudo-conversational which means after one > execution it'll be dead and will not wait for user input which is the case > for traditional convesational programs. > And the manual says this is more efficient. > > However, when next user input comes, how does my programs know that since > it's dead? So actually there're something which will never be dead (maybe > it's the CICS in this case). And when user presses specific keys, it'll > invoke the approprate program. Why not the user program do this itseft? > Maybe it's still because CICS does this better than user's program:) > > Sorry for the lengthy input. > > > On 12/23/06, Chris Mason <[EMAIL PROTECTED]> wrote: > > > > > > > > dir - as many times as is necessary until the output files appear > > > > get JOBzzzzz.s - where zzzzz is the sequence number and s is 1 to the > > number > > of output files > > > > > > > Best Regards, > > Johnny Luo ---------------------------------------------------------------------- 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
