*Hi Mike and everyone else on the list - * * * I have done some reading from the MFT manual.
1. Every task(like a job-step) has a TCB, correct? Is the *ASCB* the same as *TCB*? In the manual it states, that the READY queue is a chain of *TCB's *. (You've written an the READY state is represented, by the presence of the address space in the READY queue). 2. You write that, the TSO user address-space remains *swapped-in* atleast for the "*think-time*" period. The *think-time* is an externally-controlled parameter. Once the "think-time" elapses, the address-space is *logically swapped-out*? Does this apply today as well? - Quasar. On Sun, Nov 18, 2012 at 12:41 AM, Mike Myers <[email protected]>wrote: > Quasar: > > The status of an address space is maintained in an address space related > control block (probably the ASCB, if you want to look it up). The status > includes the swap state and the ready state is also represented by the > presence of the address space on the ready queue (it is removed from the > ready queue when it enters a wait state). A response by the TSO user with > an AID key causes an I/O interrupt that satisfies the terminal input wait > condition. There are several system event (sysevent) signals used to > communicate with SRM. Two of these that are relevant here are TERMWAIT > (user enters a terminal input wait condition) and USERRDY (user has become > ready to use a CPU). So it is fair to say that an "interrupt" is sent to > SRM on behalf of the address space when such an event occurs and a SYSEVENT > with the appropriate code is issued. > > As for similarities to CICS, CICS behaves much more like the TSO of old. > The CICS region exists in its own address space and manages the transaction > tasks that run in its address space. It is responsible for its own handling > of task dispatchability and monitoring transaction task waits. > > Mike > > > On 11/17/2012 12:59 PM, Quasar Chunawala wrote: > >> Hi Mike - >> >> Thank you very much for your reply. I have just another questions. I have >> put them inline, in the body of your e-mail in *red *color. >> >> >> On Sat, Nov 17, 2012 at 9:52 PM, Mike Myers <[email protected]>** >> wrote: >> >> Hi Quasar: >>> >>> Back in the very beginning (OS/360 MVT in 1971), TSO was introduced. At >>> that time, it consisted of a "monitor" program which used time-slicing to >>> distribute the CPU time it was given among the TSO users that were >>> loggedis will make the TSO address space >>> >>> on. >>> >>> With the introduction of the System Resource Manager (SRM) in MVS (1974), >>> things changed. From that point on, "time-sharing" was accomplished by >>> SRM. >>> In MVS, a TSO user ran in its own address space and became part of a mix >>> of >>> work units whose CPU usage was controlled by SRM. Any address space was >>> eligible to be dispatched on a CPU when it was in a "ready" state, the >>> opposite state can be generalized as a "wait" state. Except for select >>> address spaces (those marked "non-swappable"), an address space in a wait >>> state was eligible for swap-out. Entering a wait state could be announced >>> (long wait) or discovered (detected wait). A TSO user that was inactive >>> (in >>> between commands or thinking what to do next), was usually in a >>> terminal-input wait, as a read I/O operation was usually issued to the >>> terminal when the current command had finished. Thus, the address space >>> became a candidate for swap-out. >>> >>> Because of the unpredictability of the user's actions (how soon after the >>> swap-out decision was made that they would hit a key and end the I/O >>> wait), >>> the concept of "think time" and logical swapping was introduced. This was >>> intended to reduce swap-in I/O activity and the resultant CPU needed to >>> complete the swap-in. SRM permitted an externally controlled parameter >>> which represented think-time in seconds, making it possible to allow the >>> TSO user to remain swapped in for at least that long a period. Once >>> think-time passed, however, the TSO user could be "logically swapped". >>> >>> In the logically swapped state, the pages belonging to the TSO user's >>> address space would be written to disk or expanded storage (when that was >>> supported), preparing for physical swapping, but would remain in main >>> storage until the storage was actually needed to resolve paging demands >>> of >>> other address spaces. At that point, the TSO address soace would be >>> physically swapped and it's pages would be made available to the rest of >>> the system. If the *used became ready (ended the wait) prior to it's >>> pages being needed*, it would be marked swapped in and would retain use >>> >>> of its existing pages in main storage. This saved the I/O and CPU time >>> needed to perform the actual swap in. >>> >>> How did the SRM know, a TSO Address Space which is in the WAIT state, >> and >> logically swapped out, has now transitioned to the READY state after an >> AID >> key press? Does the address space send out an *interrupt* to the SRM? >> >> >> And if that's the case, how does it really differ from the transaction >> monitor CICS? >> >> In today's version (z/OS) this action still occurs, although we are >>> inclined to use the component name WLM (WorkLoad Manager) when describing >>> the functions I have attributed to SRM in the description above. >>> >>> Hope this helps. >>> >>> Mike Myers >>> Mentor Services Corporation >>> >>> >>> >>> On 11/17/2012 05:30 AM, Quasar Chunawala wrote: >>> >>> Hi everybody, >>>> >>>> I hope this finds you in the pink of health. I am Quasar, and I hail >>>> from >>>> Mumbai, India. I own a blog on the internet, parked at >>>> http://www.mainframes360.com. I am an application developer by >>>> profession. >>>> >>>> I intend to write an article on TSO/E on my blog. I have been reading >>>> matter on time-sharing and its origins on the Internet. I learnt about >>>> the >>>> history of Time Sharing systems and how they evolved over a period of >>>> time. >>>> I have also read, Bob Bemer’s article "*How to Consider a Computer*", >>>> >>>> published in the Automatic Control Magazine, in March 1957, by . >>>> >>>> I would like you to throw some light on the technical underpinnings of >>>> how TSO really accomplishes the feat of time-sharing. I know that, there >>>> is >>>> a TSO address-space for every active user logged on to the system. It is >>>> my >>>> understanding that, time is sliced by the scheduler between all the TSO >>>> jobs, other user-jobs, STARTed tasks etc. But, it occurs to me, why >>>> should >>>> a time-slot be given to a TSO user, who hasn't pressed an AID key(like >>>> Enter)? Maybe, he's just staring at a dataset. Isn't this a waste of >>>> processor-time? Or am I missing out something. >>>> >>>> Thanks and look forward to receiving a reply from you soon, >>>> >>>> Quasar Chunawala >>>> >>>> Sent from Windows Mail >>>> >>>> ------------------------------****----------------------------**--** >>>> >>>> ---------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to [email protected] with the message: INFO IBM-MAIN >>>> >>>> >>>> ------------------------------****----------------------------** >>> --**---------- >>> >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >>> >>> ------------------------------**------------------------------** >> ---------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> >> > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
