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 < quasar.chunawa...@gmail.com> 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 <m...@mentor-services.com > >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 <m...@mentor-services.com > >** > >> 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 lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>>> > >>>> > >>>> ------------------------------****----------------------------** > >>> --**---------- > >>> > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >>> > >>> ------------------------------**------------------------------** > >> ---------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > > > ------------------------------**------------------------------**---------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
