Re: 5 Byte Device Addresses?
In 1250849277558111.wa.haroldberglasyahoo...@bama.ua.edu, on 03/03/2012 at 07:25 AM, Myname Is haroldberg...@yahoo.ca said: pardon the language, sir, but did u know that the jcl keyword UNIT=[/]n would create an internal text specification Yes. I also know that the Internalt Text Buffer Buffer contains character data. since u can't see beyond your very large nose, Since the best you can do is an ad hominem attack, of won't bother to address the rest of your misguided nattering. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
pardon the language, sir, but did u know that the jcl keyword UNIT=[/]n would create an internal text specification that would require internal testing of either 3 4 OR now 5 characther length, this would be simliar to the-svc 99- checking of the length field as well, since u can't see beyond your very large nose, why do u need to use profanity to make your point, when in fact u have no point to make. beyond the JCL, you need to also add the confusion involved in the DEVICES Saf class where the resource name is now 5 digits as well, meaning that the mask condition is also affected, much like the 3/4 transition is akin to the 4/5 transition . see sample in manual that refers to A20* mask which could be A200- A20F , or just A20 (as in 0A20). NOW expand that to 5 digits to cover the new ranges , and see if you have NO problems at all. It's funny how the people who think they know a lot, know very little AT ALL. Perhaps u have a GK (goishe kopt)? hmm? imagine if we made an adjustment to the following situation to add a new 5th item? the havoc it would create upgrade/transition/documentation, etc etc etc... user retraining, OY! You shall set in it FOUR rows of stones. A row of sardius, topaz, and carbuncle shall be the first row; and the second row an emerald, a sapphire, and a diamond; and the third row a jacinth, an agate, and an amethyst; and the fourth row a beryl, an onyx, and a jasper. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In 2280839336598964.wa.haroldberglasyahoo...@bama.ua.edu, on 02/29/2012 at 11:26 AM, Myname Is haroldberg...@yahoo.ca said: and 3 bytes would upset the world of ZOS, (JCL, JCL? NFW. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
check the iocp manual - it's the CSS-ID (the logical channel subsystem id). http://www-01.ibm.com/support/docview.wss?uid=isg2de3388ad7e19bffc85257768003f170eaid=1 page 68 and of course page 303, which says the 2817 has max of 3 for css-id, and a max of 2 for subchanel set id. p.s. i loved the history lessons, most of them being fairy tales. and dark distant foggy memories. The truth though is more fascinating . it's sad people can't let go device addressing was 3 digits(hex) . let it go... it's all now chanell-sets and iodf device numbers. the old days are gone, and should be forgotten. let it go, ok? A few yerars back IBM was well aware of the device number running outproblem, they addressed in a few ways, 1) more data per the addressed-device - notably the dasd devices. 2) add channel sets and 3) add virtual layering. The thought was that this would allow the HCD/IOCP/HSA areas to be managed better(controlled). and circumvent the software intrusion into created 3or4-byte addressing i.e. 5 hex digites need 3 bytes to live in. and 3 bytes would upset the world of ZOS, (JCL,control blocks, etc etc). Imagine the 2 byte fields abcd (that reresented 4 digits in 2 bytes) expanding to larger size as well. it was a nightmare, to change pgms that dated back years and decades to evaluate and change, let alone user-pgms sysprogs wrote. a lot of money here. best solution- keep 4 char device numbers asis, add a new plane of existance and let the hotshot sysprogs deal with it. first confusion, then awareness (i.e. read newera software share presentation handout --session 10471 last march titled IODF, etc., and/or other share sessions in last 20th century hosted by IBMers in a freeforall on this topic, it's been over a decade -- where were you?) so, it was decided to go another route instead - the one they implemented starts at the IOCP level, and will one day be better known. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
Myname Is haroldberg...@yahoo.ca wrote in message news:2280839336598964.wa.haroldberglasyahoo...@bama.ua.edu... check the iocp manual - it's the CSS-ID (the logical channel subsystem id). http://www-01.ibm.com/support/docview.wss?uid=isg2de3388ad7e19bffc852577 68003f170eaid=1 page 68 and of course page 303, which says the 2817 has max of 3 for css-id, and a max of 2 for subchanel set id. p.s. i loved the history lessons, most of them being fairy tales. and dark distant foggy memories. The truth though is more fascinating . it's sad people can't let go device addressing was 3 digits(hex) . let it go... it's all now chanell-sets and iodf device numbers. the old days are gone, and should be forgotten. let it go, ok? A few yerars back IBM was well aware of the device number running outproblem, they addressed in a few ways, 1) more data per the addressed-device - notably the dasd devices. 2) add channel sets and 3) add virtual layering. How about: 0) invent the 3705? That was decentralizing, shifting thousands of addresses behind one 37x5 device address. Kees. The thought was that this would allow the HCD/IOCP/HSA areas to be managed better(controlled). and circumvent the software intrusion into created 3or4-byte addressing i.e. 5 hex digites need 3 bytes to live in. and 3 bytes would upset the world of ZOS, (JCL,control blocks, etc etc). Imagine the 2 byte fields abcd (that reresented 4 digits in 2 bytes) expanding to larger size as well. it was a nightmare, to change pgms that dated back years and decades to evaluate and change, let alone user-pgms sysprogs wrote. a lot of money here. best solution- keep 4 char device numbers asis, add a new plane of existance and let the hotshot sysprogs deal with it. first confusion, then awareness (i.e. read newera software share presentation handout --session 10471 last march titled IODF, etc., and/or other share sessions in last 20th century hosted by IBMers in a freeforall on this topic, it's been over a decade -- where were you?) so, it was decided to go another route instead - the one they implemented starts at the IOCP level, and will one day be better known. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
glen herrmannsfeldt g...@ugcs.caltech.edu writes: It seems to me that adaptive algorithms are more likely to sync to each other when nested. But how about one that examines every Nth page, (hopefully N is prime), such that they won't be the exact same pages. Or even using a more random path, such as from a CRC polynomial. So the path through the pages will be different, and so different approximately LRU pages will be selected. Never having tried this, those are the ones I think up. re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#27 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#28 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#29 5 Byte Device Addresses? that is strickly deterministic ... these are all approximate LRU selection for replacement. The theory behind choosing least recently used pages is that they have shown to be the least probable being used in the future. if the VM system is choosing virtual machine pages for replacement based on least recently used ... and the guest MVS system is looking for pages have been also least recently used ... they both will tend to concentrate on selecting from the same subset of pages ... the guest MVS selecting their least recently used virtual machines and the VM system selecting the MVS guest virtual machine pages that the corresponding MVS virtual pages occupy. That significantly increases the probability that the page the guest MVS selects for replacement and the corresponding virtual machine page to use ... that guest virtual page has also been selected by the VM system for replacement and removal from real memory. Running a least recently used replacement algorithm under a least recently used replacement algorithm violates the assumption that the least recently used page is the least likely to be used in the future. They don't have to be strickly in sync ... but it will drastically increase the probability that there is double paging ... aka the virtual machine page that the MVS system wants to start using is a page that the VM system has removed from memory. As I previously mentioned, something similar happens with a large DBMS cache being managed by least recently used ... running in a virtual memory operating system. It is one of the reasons that virtual memory operating systems tend to have ways of biasing against selecting large DBMS cache pages (because they useage patterns tend to violate the assumption that the least recently used page will be the least probable page to be used in the future). misc. past posts mentioning virtual memory replacement http://www.garlic.com/~lynn/subtopic.html#clock old email mentioning various aspects page replacement ... including work related to big page, full-track page transfers implementation also resulted in tweaks that resulted in underminning least recently used (corresponding to something similar done for the original SVS implementation that continued well into MVS releases) http://www.garlic.com/~lynn/lhwemail.html#globallru -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
glen herrmannsfeldt g...@ugcs.caltech.edu writes: I sort of know how the algorithms work, but now I looked at: http://en.wikipedia.org/wiki/Page_replacement_algorithm I had thought that for the clock algorithm that there would be some parameter that affects how the clock works, a time constant of some kind. The above page doesn't seem to describe one, though. But for the adaptive CAR algorithm, I could easily imagine the two would sync with each other. On the other hand, random replacement shouldn't have such problems. re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Addresses? misc. past posts mentioning page replacement virtual memory management http://www.garlic.com/~lynn/subtopic.html#clock long winded description of clock (which is class of algorithms that attempt to approximate LRU replacement) and slight-of-hand hack on clock that I did in the early 70s that would dynamically switch between approximate-LRU and random. so the simplest that I did in the 60s was one-handed clock that rotated around resetting/selecting virtual page ... so the elapsed time between resetting reference bit and again examining the page for use/replacement was the time to completely examine all pages. This resulted in a dynamically adapting algorithm ... the greater the demand, the faster it rotated ... however, the faster it rotated, the smaller the interval between reset re-examine ... the smaller interval which increases the number of pages not referenced, which slows things down ... two opposing effects that results in dynamically adapting to configuration/supply and workload/demand. The idea isn't to find page that hasn't been used in fixed amount of time but to differentiate the lower used from the higher used (which is going to be relative passed on configuration and load). So one-handed clock has the cursors doing the resetting selecting traveling around all virtual pages in sync. Two-handed clock has the hand/cursor doing the resetting traveling around all pages at a fixed offset ahead of the hand/cursor doing the selection. The issue here is that while one-handed clock dynamically adapts ... that past a certain elapsed time when there are really large number of pages, LRU assumptions break down ... if you haven't reset/examined virtual page for very long time ... there is little predictive correlation about whether a specific page will be used or not used in near future. Having the reset of the used/reference less than full rotation around all pages tries to keep the elapsed time between reset examine below threshold where the interval is predictive. So that is the standard clock ... which attempts to approximate true LRU (where all virtual pages are exactly ordered as to most recent reference ... based on theory that the page that has been least recently used in the past is least likely to be used in the future ... for some specific kinds of access patterns). There is a problem that there are number situations that violate the correlation between use in the past and use in the future. In the early 70s, I did a slight-of-hand hack on two-handed clock ... where the code appeared to looktaste almostly exactly like two-handed block ... except it had peculiar characteristic of approximating true LRU in conditions were LRU did well and approximate random in conditions that LRU performed poorly (dynamically w/o any observable change in the code executed). In simulations studies with full instruction tracing ... it was possible to compare various clock implementations as well as various other kinds of LRU-approximation algorithms ... against a true LRU (i.e. keeping exact ordering of page references and exactly choosing the least recently used) ... various approximatations would tend to perform within approximately 10-15percent of true LRU. However, for my slight-of-hand hack on clock ... it was possible to perform approximately 10percent better than true LRU. However two recursive algorithms (one running virtually under the other) where both approximate LRU (even if the exact code is different) ... the 2nd level algorithm would tend to exhibit the behavior that the least recently pages were the most likely to be used next (because they are selected for replacement) ... as least from the standpoint of the lowest level algorithm (violating the LRU assumption that the least recently used pages are the least likely to be used in the near future). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
glen herrmannsfeldt g...@ugcs.caltech.edu writes: Some of this is described in the above mentioned web page. It seems that some improvements have been made along the way. Also described is precleaning, where you write out a page in anticipation of its need for replacement. re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#27 5 Byte Device Addresses? misc. past posts mentioning page replacement virtual memory management http://www.garlic.com/~lynn/subtopic.html#clock there were two issues with the early SVS/MVS replacement ... regarding selecting non-changed pages before changed pages ... one was eliminating the work and overhead of the write ... and the other is the issue of eliminating any synchronous latency related to waiting for the write. most implementations early on, implement a pool of immediately available pages for replacement (that had been pre-selected) ... rather than synchronously running the replacement with the selection (immediately available eliminates synchronous latency associated with selection and potential writes). the pool could be also run with min/max ... so when pool of immediately available pages dropped below a min ... it was replenished to the max (trying for some slight efficiency batching selection process). there was also big pages starting in the early 80s (done for both MVS VM) ... that always did writes ... collecting set of pages and doing single write operation for full 3380 track of pages. the issue was that while 3380 transfer rate was 10 times that of 3330 ... the access latency (arm rotation) only marginally increase. The theory was that the increase in 3380 efficiency always doing full-track writesreads (single access for full-track of pages) ... offset the increased overhead having to unnecessarily write unchanged pages. This would have further highlighted the downside effects of choosing non-changed before changed that I argued before they first shipped ... and they finally realized in the late 70s. however, the big pages selection processing violated LRU in other ways ... this is old email discussing LRU ... including some of how big pages undermined LRU: http://www.garlic.com/~lynn/lhwemail.html#globallru -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#27 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#28 5 Byte Device Addresses? misc. past posts mentioning page replacement virtual memory management http://www.garlic.com/~lynn/subtopic.html#clock and some old email http://www.garlic.com/~lynn/lhwemail.html#globallru a recent thread in comp.arch discussion started out asking about mainframe queued i/o processing (in thread on interrupt paradigm overhead) http://www.garlic.com/~lynn/2012c.html#20 M68k add to memory is not a mistake any more http://www.garlic.com/~lynn/2012c.html#23 M68k add to memory is not a mistake any more also discusses various device optimization for page i/o operations. this has survey and taxonomy of i/o systems ... including some discussion of mainframe queued i/o http://www.cs.clemson.edu/~mark/io_hist.html there is also reference to longer discussion in IBM JRD ... which used to be available free but is journals are now behind IEEE paywall http://ieeexplore.ieee.org/Xplore/login.jsp?reload=trueurl=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5288520%2F5390413%2F05390415.pdf%3Farnumber%3D5390415authDecision=-203 In '75 ... besides endicott con'ing me into doing a lot of stuff for 138/148 ECPS (microcode assist) ... old post with part of data used in determining ECPS: http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist at the same time a group in POK con'ed me into doing a lot of design for 5-way SMP. The processor technology had lots of provision for microcode ... so I dropped some amount of multiprocessor dispatching complexity into the microcode (reminiscent of later intel 432 ... or current mainframe LPAR dispatch management) ... as well as a queued i/o channel interface ... superset of the later 811 (370-xa specification named for nov78 date on lot of the specifications). some past posts http://www.garlic.com/~lynn/submain.html#bounce for whatever reason, the 5-way SMP project got canceled ... but a little later reborn as 16-way SMP effort ... and some of the 3033 processor engineers were con'ed into helping in their spare-time. This saw a lot of early acceptance ... but then somebody mentioned to the head of POK, that it might be decades before MVS could effectively support 16-way SMP ... and the head of POK told the 3033 processor engineers to get their noses back to the grindstone (and stop being distracted) ... and others got invited to never visit POK again (this was all before 3033 first shipped). misc. past general posts mentioning SMP support and/or compareswap instruction http://www.garlic.com/~lynn/subtopic.html#smp misc past posts mentioning dispatching dynamic adaptive scheduling (also started when I was undergraduate in the 60s) http://www.garlic.com/~lynn/subtopic.html#fairshare -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
glen herrmannsfeldt g...@ugcs.caltech.edu writes: It would seem less likely that they would use the exact same replacement algorithm, but could eventually lock, anyway. re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? least recently used is well studied characteristic ... that says that of all the current virtual pages ... the current least recently used page is the least likely to be used in the future. since the least recently used page is the least likely to be used in the future it becomes the basis for LRU replacement algorithms ... trying to select the least likely to be used page (based on being the least recently used). so lots of systems have implemented LRU replacement algorithms based on well studied program behavior ... although they all may have slightly different code implementations ... they would tend to select approximately the same virtual page for replacement. so running a LRU strategy under a LRU strategy ... vm370 will look at all the virtual machine pages and select the least recently used for replacement. The guest operating system will be looking at all its virtual pages and select the least recently used for replacement. The issue is that the guest virtual page that is selected for replacement occupies a guest virtual machine page ... and useage patterns are based on the same criteria. The result is vm370 will remove/replace a virtual machine page when it hasn't been used while the guest operating system will select the contents of the same virtual machine page for its replacement and start using that same virtual machine page with a different guest operating system virtual page. The effect is from the vm370 stand-point, the guest operating system is violating all the studies that have shown that the least recently used (virtual machine) virtual page is the least likely to be used in the future (because the guest operating system wants to select that same virtual machine page for use for replacement). There are other ways of treaking the algorithms. Lots of the AOS protype stuff for what would become OS/VS2 SVS came from cp67 ... like cp67's channel program translator, CCWTRANS was cobbled into the side of EXCP processing. However the POK performance group came up with a tweak for SVS LRU-replacement algorithm, before it first shipped. They observed if they selected/replaced non-changed LRU pages before changed pages ... they wouldn't first have to write the current virtual page to disk before being able to fetch the replacement page into the location. I argued strongly against it since it significantly distorted the LRU relationship ... but they went ahead anyway. Well late into the MVS release cycle, they discovered that the strategy resulted in choosing for replacement; higher-use, shared, non-changed linkpack virtual pages before lower-use, non-shared, private, changed application specific virtual pages. The cast had changed in POK and new people got awards for fixing the earlier work having done it wrong ... and somebody eventually contacted me if something similar could be fixed in vm370. My reply was that I had never done it that way since I was undergraduate in the 60s. lots of past posts mentioning virtual memory management and page replacement algorithms http://www.garlic.com/~lynn/subtopic.html#clock My 60s undergraduate work got me sucked into an academic uproar ... Jim Gray had left for Tandem but at 14-16Dec1981 ACM SIGOPS meeting asked me if I could lend a hand with somebody trying to get their Stanford PHD. It involved an area that I had originally worked on as undergraduate in the 60s. I had done something different than what was being done in the academic circles in the 60s. The primary person behind the 60s academic work was violently objecting to the Stanford PHD being awarded (because it was in conflict with his work). My work was being shipped in cp67. However, in the early 70s, the Grenoble Science Center had modified their version of cp67 to correspond with the 60s academic strategy. The Cambridge Science Center 360/67 with 768k memory (104 pageable pages after fixed kernel storage requirements) with my strategy gave about the same performance with 80 users as the Genoble Sicence Center 360/67 with 1mbyte memory (154 pageable pages after fixed kernel storage requirements) with 35 users (almost identical workloads). CSC 360/67, with my strategy could support approx. twice the number of users as GCS 360/67 with the academic strategy (and 50% more pageable storage). It was possibly the only direct apples-to-apples comparison of my strategy and the 60s academic strategy. Past post on the subject http://www.garlic.com/~lynn/2006w.html#46 the above contains this response that I was finally allowed to send nearly a year later (after the request at ACM SIGOPS)
Re: 5 Byte Device Addresses?
In af2ee1ca5139d947b1ccdbf226607e8e02b9d...@tad03.tad.org, on 02/19/2012 at 07:36 PM, Fred Hoffman fhoff...@tad.org said: I thought os/vs1 was MFT with virtual storage. That doesn't conflict with what anybody wrote in this thread, although it is an oversimplification. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
I thought os/vs1 was MFT with virtual storage. Fred From: IBM Mainframe Discussion List on behalf of Shmuel Metz (Seymour J.) Sent: Fri 2/17/2012 12:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: 5 Byte Device Addresses? In p06240802cb635acf006e@[192.168.1.11], on 02/16/2012 at 08:23 PM, Robert A. Rosenberg hal9...@panix.com said: No Bill is right. No. OS/VS2 Release 2 WAS MVS But MVS wasn't OS/VS2 Release 2. like OS/VS2 Release 1 was SVS. The difference is that SVS was *only* release 1; MVS was *not* only release 2. SVS was OS/360 MVT with Virtual Addresses That depends on what was was. SVS was missing OS/360 component and had some significant differences from OS/360 MVT over and above paging. BTDT,GTS -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
glen herrmannsfeldt g...@ugcs.caltech.edu writes: That is, as I understand it, pretty close to how it started out. Among others, though OS/VS1 has special features for running under VM that OS/VS2 never got. It has the ability to switch to a different task while VM is paging a task. That avoids the double paging problem that otherwise occurs. customers had previously made such changes to MVT ... which is possibly where at least the idea of the VS1 change. In OS/VS2 SVS it had single 16mbyte virtual memory laid out almost as if MVT running in 16mbyte real machine. When MVT ran in virtual machine ... when a virtual SIO was done ... CP67 would scan the virtual channel program and create a shadow copy with real addresses ... which would be the channel program that got executed. This routine from cp67 (ccwtrans) was cribbed into the side of EXCP processing ... i.e. with transition to virtual memory then all the OSes had the same issue with channel programs passed in EXCP ... needing creating nearly identical channel programs but with real addresses in place of virtual addresses. In OS/VS1 case, it had things laid out in a 4mbyte virtual address space (as if it was running on real 4mbyte machine). In the OS/VS1 handshaking case ... a 4mbyte virtual machine was created with OS/VS1 4mbyte virtual address space mapped one-for-one to the virtual machine address space. Whenever, vm370 had a os/vs1 virtual machine page fault ... if the machine was running in application (and not in os/vs1 kernel) ... vm370 would reflect special page fault to the virtual machine. OS/VS1 could then do task-switch as if it was a OS/VS1 application virtual page fault. Later when vm370 had fetched the OS/VS1 virtual machine virtual page ... vm370 would reflect a special interrupt to OS/VS1 (indicating the page was available). From Melinda's VM and the VM Community http://web.me.com/melinda.varian/Site/Melinda_Varians_Home_Page.html Dewayne Hendricks reported at SHARE XLII, in March, 1974, that he had successfully implemented MVT-CP handshaking for page faulting, so that when MVT running under VM took a page fault, CP would allow MVT to dispatch another task while CP brought in the page. At the following SHARE, Dewayne did a presentation on further modifications, including support for SIOF and a memory-mapped job queue. With these changes, his system would allow multitasking guests actually to multitask when running in a virtual machine. Significantly, his modifications were available on the Waterloo Tape. ... and ... then was able to get MFT MVT running faster under vm370 than it ran on bare machine By SHARE 49, Dewayne was able to state that, It is now generally understood that either MFT or MVT can run under VM/370 with relative batch throughput greater than 1. That is to say, they had both been made to run significantly faster under VM than on the bare hardware. Dewayne and others did similar work to improve the performance of DOS under VM. Other customers, notably Woody Garnett(122) and John Alvord, soon achieved excellent results with VS1 under VM. ... snip ... There is a separate issue with OS/VS2 (of any ilk) running under vm370 ... which is pathelogical case of a virtual memory operating system system managing with least recently algorithm in virtual machine which manages its virtual memory with least recently algorithm. The scenario is that a virtual machine page that hasn't been used for awhile ... is the virtual page that vm370 is likely to select for replacement/removal. However, the operating system in the virtual machine ... if it is also doing paging ... may also select the very same page to be the next one to use (after it has just been selected for removal). From a theoritical standpoint cascading LRU-algorithms will appear to violate least-recently-used replacement assumptions (i.e. a least-recently-used page can be the next most likely to be used rather than the least likely to be next used). This characteristic also exhibits itself with DBMS caches that are managed with LRU strategy when running in a virtual memory operating system that also manages with LRU strategy. The VS1 handshaking isn't actually a double paging issue ... that was handled by configuration of VS1's virtual address space the same as the virtual machine storage size. The handshaking worked with MVTMFT as well as VS1 ... allowing the guest operating system to task switch while vm370 was handling page fault. more detailed discussion pg.25 vm/vs handshaking http://www.bitsavers.org/pdf/ibm/370/vm370/GC20-1800-6_VM370intr_Oct76.pdf -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In CAPD5F5oS=2wrluhxwtpjbcjbx8v0m9-nymvcfyjpbzket9u...@mail.gmail.com, on 02/16/2012 at 11:45 AM, John Gilmore johnwgilmore0...@gmail.com said: The original System/360 scheme was simple and in its way elegant. 01F---decodable unambiguously into (multiplexor) channel 0, control unit 1, and that control unit's device F or 15 Actually it was ambiguos, lacking knowledge of the particular controller. The address was cuu, where uu specified the controller and the device, but there could be multiple controlles with the same 4 high bits and there could be controllers with more than 16 devices. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In 77142d37c0c3c34da0d7b1da7d7ca346c...@nwt-s-mbx1.rocketsoftware.com, on 02/16/2012 at 08:55 PM, Bill Fairchild bfairch...@rocketsoftware.com said: Seymour is right that we have had subchannel numbers since 1983 instead of device addresses, but we have also had device numbers since 1983. At the same time, and not necessarily with the same values. As John Gilmore explained in an earlier post, we used to have 12-bit device addresses composed of three parts, the channel number, control unit number within the channel, and device number within the control unit within the channel. It wasn't quite that clean; the uu part of the cuu split differently depending on the control unit. The 8 bits of uu were presented on the channel and it was up to the control units to recognize which belonged to it and which didn't. Some control units had fewer than 16 devices, some had more. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In p06240802cb635acf006e@[192.168.1.11], on 02/16/2012 at 08:23 PM, Robert A. Rosenberg hal9...@panix.com said: No Bill is right. No. OS/VS2 Release 2 WAS MVS But MVS wasn't OS/VS2 Release 2. like OS/VS2 Release 1 was SVS. The difference is that SVS was *only* release 1; MVS was *not* only release 2. SVS was OS/360 MVT with Virtual Addresses That depends on what was was. SVS was missing OS/360 component and had some significant differences from OS/360 MVT over and above paging. BTDT,GTS -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
W dniu 2012-02-16 01:55, Dan pisze: Thanks Radoslaw Bob. I figured there must be some explanation for the additional byte other than some new extended device ranges. This is still a DOC problem as the manual simply states these are device addresses. Radoslaw, are you saying there is a way of creating an IPLable device with a 5 byte device address after z/OS 1.7? How is that possible when UCBCHAN only provides space for 4 byte addresses (which D U,... uses)? I have never tried it, but you can put PPRC secondary volumes to SS1 and then IPL from such device by providing in HMC dialogs 5-byte addresses. Last, but not least: it is quite new feature, it wasn't available at the time of z/OS 1.7 GA. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
They haven't been device addresses since 1983 with the advent of MVS/XA, in spite of the fact that people who had been calling them device addresses since 1964, for the most part, still call them device addresses. They have been device numbers since XA's redesign of the I/O architecture. And developers and documenters still create screen displays and tech doc with the now 31-years-obsolete nomenclature. I complain now and then to deaf ears. But that's ok, since I still call z/OS by the name MVS. At least I don't still call it OS/VS2 Release 2. Lol Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dan Sent: Wednesday, February 15, 2012 6:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: 5 Byte Device Addresses? This is still a DOC problem as the manual simply states these are device addresses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
W dniu 2012-02-16 15:14, Bill Fairchild pisze: They haven't been device addresses since 1983 with the advent of MVS/XA, in spite of the fact that people who had been calling them device addresses since 1964, for the most part, still call them device addresses. They have been device numbers since XA's redesign of the I/O architecture. And developers and documenters still create screen displays and tech doc with the now 31-years-obsolete nomenclature. I complain now and then to deaf ears. But that's ok, since I still call z/OS by the name MVS. At least I don't still call it OS/VS2 Release 2. Lol Yes, in z/OS (OS/390,...) there are device numbers, not adresses. Device numbers replaced device addresses in some sense (like VARY command, etc.). However people still use device address in place of device number. We discussed about fifth byte of the device number, and nobody was harmed by usage of device address. Everyone knew what are we talking about. IMHO that's the most important. Similar problems: KiB vs kB (1024 vs 1000) Unix System Services vs USS -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
Predictably--I am the pedant who insists on distinguishing KB and KiB--Bill Fairchild's point seems to me to be important. Quaint, long familiar terminology should be avoided where it is misleading. The original System/360 scheme was simple and in its way elegant. 01F---decodable unambiguously into (multiplexor) channel 0, control unit 1, and that control unit's device F or 15---was, for example, the usual device address of the card punch circa 1965, when punches were still real rather than virtual devices. Whatever its historical interest may be, this scheme and its progressively less elegant, patched together successors are now architecturally irrelevant; and it is time to 1) give the old terminology a decent burial and 2) talk about device numbers instead. On 2/16/12, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2012-02-16 15:14, Bill Fairchild pisze: They haven't been device addresses since 1983 with the advent of MVS/XA, in spite of the fact that people who had been calling them device addresses since 1964, for the most part, still call them device addresses. They have been device numbers since XA's redesign of the I/O architecture. And developers and documenters still create screen displays and tech doc with the now 31-years-obsolete nomenclature. I complain now and then to deaf ears. But that's ok, since I still call z/OS by the name MVS. At least I don't still call it OS/VS2 Release 2. Lol Yes, in z/OS (OS/390,...) there are device numbers, not adresses. Device numbers replaced device addresses in some sense (like VARY command, etc.). However people still use device address in place of device number. We discussed about fifth byte of the device number, and nobody was harmed by usage of device address. Everyone knew what are we talking about. IMHO that's the most important. Similar problems: KiB vs kB (1024 vs 1000) Unix System Services vs USS Radoslaw Skorupka Lodz, Poland tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s bowego adresata. Odbiorc e by jedynie jej adresat z wy czeniem dost pu os b trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy c odpowied oraz trwale usun wiadomo czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorc w KRS 025237, NIP: 526-021-50-88. ug stanu na dzie 01.01.2012 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 168.410.984 z otych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
johnwgilmore0...@gmail.com (John Gilmore) writes: The original System/360 scheme was simple and in its way elegant. 01F---decodable unambiguously into (multiplexor) channel 0, control unit 1, and that control unit's device F or 15---was, for example, the usual device address of the card punch circa 1965, when punches were still real rather than virtual devices. trivia ... 009 was 1052-7 console 00C was 2540 reader 00D was 2540 punch 00E was 1403 printer some other configurations had 01F as 1052-7 console address (instead of 009) ... making the controller abstraction on the multiplexor channel slightly more consistent. tale of cp40 http://www.garlic.com/~lynn/cp40seas1982.txt done at the science center in the 60s some past posts http://www.garlic.com/~lynn/subtopic.html#545tech cms started out operating system being done on regular 360/40 with interactive commands on the 1052-7 operator's console cp40 was hardware modifications to 360/40 providing virtual memory, cp40 then implemented 360/40 virtual machines ... and cms ran on either bare-hardware or in cp40 virtual machine. when 360/67 became available standard with virtual memory, cp40 morphed into cp67. the default cms virtual machine configuration tended to stay the same that it started out from the real 360/40 configuration (256kbyte real memory configuration). additional history can be found in documents at Melinda's website http://web.me.com/melinda.varian/Site/Melinda_Varians_Home_Page.html this talks about 360/40 360/50 having integrated console at 01f (aka when it was not at 009): http://en.wikipedia.org/wiki/IBM_System/360 cp67 default configuration for cms virtual machine: http://www.bitsavers.org/pdf/ibm/360/cp67/ GH20-0859-0_CP67_Version_3_Users_Guide_Oct70.pdf pg. 5 ... shows the 009 configuration for 1052-7 console note the cp67 users guide also described 2741, 1052, and tty terminals when cp67 was originally delivered to the univ, it only has 2471 1052 terminal support ... but had dynamic terminal type identification support ... being able to use the SAD controller command to switch between the 2741 and 1052 line-scanner for each port/address. the univ. had a lot of tty terminals and so I had to add tty support (which was picked up and released with the product). I looked at the 2741/1052 and added the tty support so it also did dynamic terminal type identification ... being able to use SAD command to dynamically switch the different (2471, 1052, tty) line-scanners for each port. I then wanted to do a single dial-up hunt-group for dial-up terminals ... aka a common pool of phone numbers/modems with a single dial-in number for all terminals. It turns out that dynamic worked for leased lines ... but wouldn't work for common pool for all dial-up terminals. The problem was that while it was possible to dynamically switch the type of line-scanner (with SAD command) on per port basis ... the line speed was hard-wired for each port. This was somewhat the motivation for the univ. to start a clone controller project ... which could do both dynamic termainal type as well as dynamic line speed (i.e. 2741 1052 had the same line speed ... but different line-scanner ... tty had both a different line-scanner as well as different line speed). later four of us get written up as being responsible for (some part of) clone controller market. misc. past posts mentioning clone controller http://www.garlic.com/~lynn/subtopic.html#360pcm This reference has clone controller competition a primary motivation for the Future System effort: http://www.ecole.org/Crisis_and_change_1995_1.htm Then Ferguson Morris, Computer Wars: The Post-IBM World, Times Books, 1993 ... describe the distraction of the Future System (and internal politics killing 370 efforts) allowed clone processors to gain market foothold ... misc. past posts mentioning Future System http://www.garlic.com/~lynn/submain.html#futuresys -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In 77142d37c0c3c34da0d7b1da7d7ca346c...@nwt-s-mbx1.rocketsoftware.com, on 02/16/2012 at 02:14 PM, Bill Fairchild bfairch...@rocketsoftware.com said: They haven't been device addresses since 1983 with the advent of MVS/XA, in spite of the fact that people who had been calling them device addresses since 1964, for the most part, still call them device addresses. They have been device numbers since XA's redesign of the I/O architecture. Make that Subchannel Number[1]. But that's ok, since I still call z/OS by the name MVS. Is that not the official name of the BCP in z/OS? At least I don't still call it OS/VS2 Release 2. Well, it isn't. Program product versions of MVS haven't installed on top of the free base for decades, and before then the release number had climbed to 3.8. [1] To complicate matters, the subchannel-set identifier (SSID) and the Subchannel Number in the subsystem-identification word (SID) are not contiguous but have an intervening 1. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In 4f3d172f.9030...@bremultibank.com.pl, on 02/16/2012 at 03:48 PM, R.S. r.skoru...@bremultibank.com.pl said: Yes, in z/OS (OS/390,...) there are device numbers, not adresses. No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In 0156585592475057.wa.mvsjes2sympatico...@bama.ua.edu, on 02/14/2012 at 07:06 AM, Dan D mvs-j...@sympatico.ca said: Subject: 5 Byte Device Addresses? ITYM 5-digit device addresses[1], unless you're talking about 4-bit bytes. IAC, the subchannel-set identifier (SSID) is not formally part of the Subchannel Number. I'm wondering when 5 byte UCBs The UCB is not the device address, it's a control block. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? The last I heard, device addresses for base exposures were limited to CSS 0, so 4 digits is adequate. As for alias addresses, I assume that part of PAV was adding new fields to the UCB; check IEFUCBOB or the data areas manual (It's one of the diagnosis manuals, but I don't recall the exact title.) BTW. the description of IPL in PoOps only mentions the 4-digit device number, not the SSID. [1] More properly, 5-digit Subchannel Numbers -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
@bama.ua.edu Subject: Re: 5 Byte Device Addresses? In 77142d37c0c3c34da0d7b1da7d7ca346c...@nwt-s-mbx1.rocketsoftware.com, on 02/16/2012 at 02:14 PM, Bill Fairchild bfairch...@rocketsoftware.com said: They haven't been device addresses since 1983 with the advent of MVS/XA, in spite of the fact that people who had been calling them device addresses since 1964, for the most part, still call them device addresses. They have been device numbers since XA's redesign of the I/O architecture. Make that Subchannel Number... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
At 13:12 -0500 on 02/16/2012, Shmuel Metz (Seymour J.) wrote about Re: 5 Byte Device Addresses?: In 77142d37c0c3c34da0d7b1da7d7ca346c...@nwt-s-mbx1.rocketsoftware.com, on 02/16/2012 at 02:14 PM, Bill Fairchild bfairch...@rocketsoftware.com said: But that's ok, since I still call z/OS by the name MVS. Is that not the official name of the BCP in z/OS? At least I don't still call it OS/VS2 Release 2. Well, it isn't. Program product versions of MVS haven't installed on top of the free base for decades, and before then the release number had climbed to 3.8. No Bill is right. OS/VS2 Release 2 WAS MVS like OS/VS2 Release 1 was SVS. SVS was OS/360 MVT with Virtual Addresses (SVS was a single 16MB Address Space with which was divided into smaller areas for the programs to use, just like MVT). MVS made the program's area into duplicate address ranges which sat between and shared the low and high address ranges which belonged to the Operating System. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
hal9...@panix.com (Robert A. Rosenberg) writes: No Bill is right. OS/VS2 Release 2 WAS MVS like OS/VS2 Release 1 was SVS. SVS was OS/360 MVT with Virtual Addresses (SVS was a single 16MB Address Space with which was divided into smaller areas for the programs to use, just like MVT). MVS made the program's area into duplicate address ranges which sat between and shared the low and high address ranges which belonged to the Operating System. old post about os/vs2 release 1 (svs), release 2 (mvs), and glide path to release 3 ... operating system for future system http://www.galric.com/~lynn/2011d.html#73 past future system posts http://www.garlic.com/~lynn/submain.html#futuresys really long-winded post about the transition to MVS and pointer-passing API causing enormous problems ... involved image of MVS occupying 8mbytes of every application virtual address space ... in order for kernel code to access application data ... and common segment for passing data between applications and semi-priviledged subsystems now in separate virtual address spaces ... and there needing to be sufficient sized common segment to handle all applications subsystems ... larger installations were having common segment threatening to increase to 6mbyte ... leaving only 2mbytes for application in every private 16mbyte virtual address space. http://www.garlic.com/~lynn/2012b.html#66 3081 370xa with 31bit addressing was taking so long to get out after future system failure ... that dual-address space was retrofitted to 3033 in attempt to somewhat alleviate the common segment pressure on what little was left for application use out of 16mbytes. some discussion getting out 3081 (and eventually 31bit addressing) after future system failure http://www.jfsowa.com/computer/memo125.htm -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
To stay young requires unceasing cultivation of the ability to unlearn old falsehoods (Robert A Heinlein) Some-how seemed appropriate. Must be time I went back and re-read some of his work. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
Thanks Radoslaw Bob. I figured there must be some explanation for the additional byte other than some new extended device ranges. This is still a DOC problem as the manual simply states these are device addresses. Radoslaw, are you saying there is a way of creating an IPLable device with a 5 byte device address after z/OS 1.7? How is that possible when UCBCHAN only provides space for 4 byte addresses (which D U,... uses)? Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
W dniu 2012-02-14 14:06, Dan D pisze: I'm wondering when 5 byte UCBs came into service and where this data comes from. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? D IPLINFO IEE254I 18.36.23 IPLINFO DISPLAY SYSTEM IPLED AT 17.34.39 ON 01/10/2012 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD00 IN SYS1.IPLPARM ON 02020 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 00 IEASYS LIST = (00,01) (OP) IODF DEVICE: ORIGINAL(02020) CURRENT(02020) IPL DEVICE: ORIGINAL(03100) CURRENT(03100) VOLUME(SCARS1) I've looked at the IEE254I message in the doc but it just says... The device number of the volume where the I/O configuration ... The D U command still only shows 4 bytes. Any ideas? 1. 5-byte device address can be misunderstood. There is no simple support for 5-byte addresses, the fifth byte have to be zero for most devices. Also, in many places you can use only 4-byte (or 0) addresses. 2. Subchannel Set 1 was introduced in z9 (2094) and AFAIR z/OS 1.7. 3. Support for 5-byte adresses is growing up constantly, for example at the time of z9 and z/OS 1.7 there was no possibility to IPL from 1 devices, there was no SS2, the only supported devices in SS1 were aliases. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
On this DISPLAY of IPLINFO, the first position is the channel set, the last four the device address. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Tuesday, February 14, 2012 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 5 Byte Device Addresses? W dniu 2012-02-14 14:06, Dan D pisze: I'm wondering when 5 byte UCBs came into service and where this data comes from. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? D IPLINFO IEE254I 18.36.23 IPLINFO DISPLAY SYSTEM IPLED AT 17.34.39 ON 01/10/2012 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD00 IN SYS1.IPLPARM ON 02020 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 00 IEASYS LIST = (00,01) (OP) IODF DEVICE: ORIGINAL(02020) CURRENT(02020) IPL DEVICE: ORIGINAL(03100) CURRENT(03100) VOLUME(SCARS1) I've looked at the IEE254I message in the doc but it just says... The device number of the volume where the I/O configuration ... The D U command still only shows 4 bytes. Any ideas? 1. 5-byte device address can be misunderstood. There is no simple support for 5-byte addresses, the fifth byte have to be zero for most devices. Also, in many places you can use only 4-byte (or 0) addresses. 2. Subchannel Set 1 was introduced in z9 (2094) and AFAIR z/OS 1.7. 3. Support for 5-byte adresses is growing up constantly, for example at the time of z9 and z/OS 1.7 there was no possibility to IPL from 1 devices, there was no SS2, the only supported devices in SS1 were aliases. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
