*Hi Peter - * * * I know the questions that I have posted here are naiive, and maybe I should have read the *ABC of System Programming*, and probably then should have asked something.
To be honest, I am an application developer, not a sysprog or a sysop and so, I've never really read the IBM redbooks from cover-to-cover, or taken a class on zOS architecture, before posting a question. I might have offended a few people on the list, by saying it. I am afraid to take the plunge, otherwise I'd be losing grip on reality(a bit of an exaggeration). - Quasar. On Sun, Nov 18, 2012 at 1:42 PM, mf db <[email protected]> wrote: > Hi Quasar, > > Suggest you to get aquainted with "ABC of system programming" and Z/os > architecture. Otherwise many question would get spawned without a basic > idea. > > Peter > > On Sun, Nov 18, 2012 at 1:36 PM, Quasar Chunawala < > [email protected]> wrote: > > > *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 > > > > ---------------------------------------------------------------------- > 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
