Quasar:
To begin, MFT is pretty ancient (although I was a sysprog for its
predecessor, SSS - OS/360 release 2). Much has changed since MFT,
although much remains the same. In MFT, there were no ASCBs, as there
were no address spaces, which didn't appear until MVS, where every job,
TSO user and started task had one. The tasks (TCBs) were (still are)
contained within their respective address space.
Trying to determine the actions of the z/OS system from an MFT manual is
like trying to understand current human civilization by studying
Australopithecus (sp?). I recommend you find a manual that describes the
current operating systems, such as "Introduction to the New Mainframe
z/OS Basics". Yes, it is a redbook, but it is commonly used to introduce
z/OS behavior to new IT students at the high school and university level.
Back to the question at hand. When any task (TCB) or service (SRB)
associated with the address space is ready to run, the ASCB is placed on
the ready queue in priority order. If you look at the ASCB detailed
description, you will find that an ASCB has pointers to its predecessor
and successor ASCBs on the ready queue. There are pointers from the ASCB
that are used to locate the ready TCB(s) or SRB(s) in the address space.
I said that once the think time expires, the TSO user's address space is
swapped out (physically), but only if there is a need to use its main
storage pages to satisfy the needs of other address spaces. Until that
time expires and the storage need arises, the address space remains
logically swapped out (as long as they remain "not-ready"). Becoming
ready while logically swapped causes them to transition from logically
swapped out to swapped in.
In today's systems with large main storage, an address space may remain
logically swapped out for an indefinite period of time. In today's
world, think time (a setting found in the IEAOPTxx member of the system
parameter library - xxx.PARMLIB) is still used to determine when a
logically swapped out address space becomes a "candidate" for a physical
swap out. Again, that only happens if there is a need to take those
pages away for someone else.
Mike
On 11/18/2012 03:06 AM, Quasar Chunawala 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
