Regarding Time Sharing
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
Re: Regarding Time Sharing
On 11/17/2012 2:30 AM, Quasar Chunawala wrote: ... 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. No CPU time slice is provided to any unit of work that is suspended for any reason, including terminal I/O. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding Time Sharing
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 logged 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. 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
Re: Regarding Time Sharing
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.comwrote: 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 logged 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
Re: Which SMFDUMP program?
At 14:55 -0600 on 11/16/2012, Jeff Holst wrote about Which SMFDUMP program?: I was looking for the SMFDUMP program and thought I rememebered that it was on the CBT tape. And indeed it is. In fact, I found two versions of the program, in files 684 and 686. They appear to have the same origins, but the two programs are a bit different. The dates of last updates appear to be 2004 for 684 and 2006 for 686, should that make a difference to anyone. I have seen a number of references in the archives to the version in file 686. Is this considered to be the superior version? Jeff Holst You might want to look at the Change Doc associated with the two versions to see if 686 is an updated version of 684 or if both are separate forks of the original version - IOW: Both started with the original IBM IPO source and different changes were made to the IPO version to create 684 and 686. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
Lindy, I have received several private, offlist requests for elucidations of the same sort you make. I suggest that you read the descriptions of the ENQ and DEQ macros in z/OS MVS: Assembler Services Reference, Volume 1 (ABEND-HSPSERV), SA22-7606. Some of the computer science literature talks instead about serialization and semaphores (Dijkstra's term, a metaphoric hijacking of the European word for what Americans usually call 'traffic lights'). Also worth looking at are the discussions of the Test and Set (TS) instruction and its more powerful brethren, the most recent of which is Perform Locked Operation (PLO), in z/Architecture Principles of Operation, SA22-7832. These notions are important ones. What needs to be emphasized about them is that they all make use of a mixture of conventions and hardware help. If you and I and others agree to adhere to a set of such conventions, then we can safely share access to serially reusable resources. If not, not. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding Time Sharing
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.comwrote: 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*,
Re: Regarding Time Sharing
On 11/17/2012 11:59 AM, 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.comwrote: 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 logged 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 The TSO address space goes into a WAIT state by issuing a read to the terminal, which causes MVS to generate a channel program and initiate a channel READ operation on the appropriate channel path to the appropriate controller for that terminal device. When the user presses a key that implies data is to be transmitted, the controller sends the data to the channel, which stores the data in memory and generates an I/O interrupt when the transfer is complete.
Re: Regarding Time Sharing
An observation I missed so far in this thread is that the very acronym 'TSO' is a historic misnomer. For many decades now TSO has not involved 'time sharing' any more than batch jobs or started tasks do. Nor has TSO been 'optional' in my professional lifetime. You can choose not to allow anyone to use it, but that hardly qualifies it as an 'option'. Keep that anachronism in mind as you digest this thread. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Quasar Chunawala quasar.chunawa...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 11/17/2012 02:30 AM Subject:Regarding Time Sharing Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Diagnosing VTOC error
I would go to the Master Console and issue a D U,VOL=xxfor one of the vols with VTOC ERROR See if it is online. If it is not online, then check the ISMF panels and see if it is part of an SMS pool but not available. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Friday, November 16, 2012 3:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Diagnosing VTOC error Hello Group, I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. I don't have a deep knowledge on storage side but any pointers to diagnose would really help me in referring some manuals or links. Any Advises or pointers would be really appreciated much. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
On Sat, 17 Nov 2012 04:24:44 +, Lindy Mayfield lindy.mayfi...@sas.com wrote: Can I read these control blocks with Rexx? If so, maybe I'll give it a go when I have some free moments. I think a good example is the SHOWDASD exec ( panel) in CBT File 183. It is Gilbert's code that Sam used that started this thread. I've used it for many years and never had a problem. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
On Fri, 16 Nov 2012 10:18:43 -0500, John Gilmore wrote: I have not elected to screen my own house in this way; equally, I have not reinforced its roof against purple cows falling from the sky; I have judged that these two risks are exiguous here in Massachusetts. Probability? I can't resist: http://xkcd.com/1132/ Serialization was invented to address this class of problems. We can make programs reentrant. Control blocks, on the other hand, are and will remain serially reusable. A minimal requirement for their integrity is that two dispatchables not access one of them concurrently. But the serialization can be inconspicuous. IEANTRT makes do with nothing more than the block-concurrent character of Load and STore, given major cooperation by IEANTCR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
May I infer, then, that you are talking about serious issues where the program better get it right the first time, especially when updating these control blocks (1) that are being discussed at the moment. And simple interfaces to storage, such as Rexx need have different requirements, thus because of simple functions to read storage be exempt from this discussion? I mean, that's all there is that programs like Rexx have, and they need live with it, yet at the same time understand discussions such as these. Kind regards Lindy (1) Who can update these control blocks? I think from reading this only z/OS can. (or should, you guys do what you want, seems like, then justify it like I just did.) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Saturday, November 17, 2012 8:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups Lindy, I have received several private, offlist requests for elucidations of the same sort you make. I suggest that you read the descriptions of the ENQ and DEQ macros in z/OS MVS: Assembler Services Reference, Volume 1 (ABEND-HSPSERV), SA22-7606. Some of the computer science literature talks instead about serialization and semaphores (Dijkstra's term, a metaphoric hijacking of the European word for what Americans usually call 'traffic lights'). Also worth looking at are the discussions of the Test and Set (TS) instruction and its more powerful brethren, the most recent of which is Perform Locked Operation (PLO), in z/Architecture Principles of Operation, SA22-7832. These notions are important ones. What needs to be emphasized about them is that they all make use of a mixture of conventions and hardware help. If you and I and others agree to adhere to a set of such conventions, then we can safely share access to serially reusable resources. If not, not. John Gilmore, Ashland, MA 01721 - USA -- 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
Re: New way to do UCB lookups
On Sat, Nov 17, 2012 at 5:55 PM, Lindy Mayfield lindy.mayfi...@sas.comwrote: May I infer, then, that you are talking about serious issues where the program better get it right the first time, especially when updating these control blocks (1) that are being discussed at the moment. And simple interfaces to storage, such as Rexx need have different requirements, thus because of simple functions to read storage be exempt from this discussion? I mean, that's all there is that programs like Rexx have, and they need live with it, yet at the same time understand discussions such as these. Lindy - Please consider the topic in a more general fashion. Any applications (problem or supervisor state) that has 2 or more threads of executions (TCBs) operating at the same time and share data structures (memory) need to agree when how to synchronise updates and read access to the share memory area. Otherwise, both threads may attempt to update the same memory location at the same time with different values. One of the values will be lost. This will negatively impact the way the application runs. Sam Kind regards Lindy (1) Who can update these control blocks? I think from reading this only z/OS can. (or should, you guys do what you want, seems like, then justify it like I just did.) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Saturday, November 17, 2012 8:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New way to do UCB lookups Lindy, I have received several private, offlist requests for elucidations of the same sort you make. I suggest that you read the descriptions of the ENQ and DEQ macros in z/OS MVS: Assembler Services Reference, Volume 1 (ABEND-HSPSERV), SA22-7606. Some of the computer science literature talks instead about serialization and semaphores (Dijkstra's term, a metaphoric hijacking of the European word for what Americans usually call 'traffic lights'). Also worth looking at are the discussions of the Test and Set (TS) instruction and its more powerful brethren, the most recent of which is Perform Locked Operation (PLO), in z/Architecture Principles of Operation, SA22-7832. These notions are important ones. What needs to be emphasized about them is that they all make use of a mixture of conventions and hardware help. If you and I and others agree to adhere to a set of such conventions, then we can safely share access to serially reusable resources. If not, not. John Gilmore, Ashland, MA 01721 - USA -- 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
Re: New way to do UCB lookups
In CAE1XxDEyOS91wadT+9t_aXz0Pw+ok=YD=mw_V4Fx9xQ=qqq...@mail.gmail.com, on 11/16/2012 at 10:18 AM, John Gilmore jwgli...@gmail.com said: A minimal requirement for their integrity is that two dispatchables not access one of them concurrently. No. That is an unnecessary and insufficient condition. The rules for accessing control blocks safely vary depending on the control block and the type of access. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New way to do UCB lookups
In cae1xxdhz-ibb1gjc4actg0ojpy_x8xxzwr2e+sjcpvb2uxw...@mail.gmail.com, on 11/17/2012 at 01:41 PM, John Gilmore jwgli...@gmail.com said: Some of the computer science literature talks instead about serialization and semaphores Serialization is not ENQ/DEQ; it is more general. Nor is ENQ/DEQ the only serialization mechanism in z/OS. Semaphores are a specific type[1] of serialization (Dijkstra's term, a metaphoric hijacking of the European word for what Americans usually call 'traffic lights'). No. Noun: A system of sending messages by holding the arms or two flags or poles in certain positions according to an alphabetic code. The use of the term semaphore to designate traffic lights came later. [1] Well, two related types. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Diagnosing VTOC error
In CAHTvvRUZbLmfQqzxqXPxkrv_7bn6T9q2f+L=pconbdas2rh...@mail.gmail.com, on 11/16/2012 at 03:53 PM, Jake anderson justmainfra...@gmail.com said: I have few volumes while browsing it via ISPF 3.4 interface it shows VTOC error. Have you tried bebuilding the VTOCIX? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding Time Sharing
In -21782995201426460@unknownmsgid, on 11/17/2012 at 10:30 AM, Quasar Chunawala quasar.chunawa...@gmail.com said: 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. You might try skimming The ABC's of Systems Programming, paying particular attention to the Workload manager (WLM). However, be aware that a lot of things have changed over the decades. You might also scrounge around in bitsavers. I would like you to throw some light on the technical underpinnings of how TSO really accomplishes the feat of time-sharing. In current systems, there is no significant difference between a TSO session and a batch job; the same resource allocation methods apply to both. In the original TSO there were mechanisms that applied only to TSO sessions. 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)? That's not how time-slicing works. If a task is waiting for, e.g., an I/O operation then it doesn't get control of the CPU just because a time-slice interval has expired. The Dispatcher assigns a CPU to a ready unit of wok, not to one that is nondispatchable or in a wait state. BTW, the concept of AID applies to 3270 displays; while they are by far the most common today, they are not the only terminals that TSO supports. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding Time Sharing
In 50a7b9c0.6050...@mentor-services.com, on 11/17/2012 at 11:22 AM, Mike Myers m...@mentor-services.com said: 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 logged on. No, TSO introduced changes to multiple parts of OS/360, including the Dispatcher. You're probably thinking of the TCAS, but it wasn't responsible for CPU dispatching. Except for select address spaces (those marked non-swappable), an address space in a wait state was eligible for swap-out. Any address space was eligible for a swap-out, not just those in a wait state, e.g., due to high CPU use. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding Time Sharing
In CA+Myz1VcB0i2LMr7R=1uc1t5sdc5kna-o+dmtxezd2hoovz...@mail.gmail.com, on 11/17/2012 at 11:29 PM, Quasar Chunawala quasar.chunawa...@gmail.com said: 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. No you haven't; there is no color in e-mail. 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? A component called the TIOC[1] or VTIOC[2] handles the interface to the communications access method. It is responsible for signalling the completion of, e.g., TGET, TPUT, to the TSO user's address space. The [V]TIOC uses the same cross-memory mechanisms as amy other activity that could cause an address space to become ready. And if that's the case, how does it really differ from the transaction monitor CICS? CICS runs multiple users in a single Application Owning Region (AOR); TSO has no equivalent. When there are multiple CICS address spaces, CICS uses, e.g., VTAM, to communicate among them. [1] Obsolete; was used for TCAM. [2] Used for VTAM -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
