Re: EXCP access methos
In [EMAIL PROTECTED], on 06/11/2008 at 10:37 AM, Rick Fochtman [EMAIL PROTECTED] said: Makes perfect sense to me. Under OS/360, we didn't have the protection that CCW translation gives us today and it was incredibly easy to destroy part of the OS Not by pointing a CCW at it; storage protection was good enough for that. The holes were things like failure to ensure that key 0 code came from authorized libraries.. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In [EMAIL PROTECTED], on 06/11/2008 at 06:50 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: I don't know what VSAM-like access methods are. ACB/RPL. That includes VTAM and access to SPOOL data sets. I believe that JES2 still uses EXCPVR but JES3 uses STARTIO. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In [EMAIL PROTECTED], on 06/11/2008 at 04:58 PM, J R [EMAIL PROTECTED] said: I don't think so. I remember writing code for OS/360 that, during early testing, incorrectly calculated a buffer size requirement. Sure enough, when a subsequent READ CCW tried to read into beyond the end of the GETMAINed area, a S0C4 was the result The CCW-related failure was not an ABEND S0C4, but an error code in the IOB. If you got an 0C4 it was not from executing the CCW. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In [EMAIL PROTECTED], on 06/11/2008 at 05:38 PM, Gerhard Postpischil [EMAIL PROTECTED] said: You had storage? All of our programmers had core, and persisted in that usage even into the late seventies. Yeah, but not all shops saved money by buying a 370/155 after the 370/158 had been announced :-( In PCP all of storage was fair game, I believe that PCP supported storage protection, although, of course, it shared the exposures that MFT and MVT had. (there were a couple of loopholes in SVC parameter validity checking that IBM fixed eventually). There were more that IBM never fixed in OS/360, and some that they didn't fix in SVS. lucking out with an add-on memory whose protection capability had not been configured correctly. At least you didn't have an alternate tape channel that hadn't been upgraded to support IDA :-( -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In [EMAIL PROTECTED], on 06/12/2008 at 11:39 AM, Edward Jaffe [EMAIL PROTECTED] said: And, EXCP is an ordinary unauthorized interface. STARTIO and EXCPVR are not. Are you a betting man? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In [EMAIL PROTECTED], on 06/11/2008 at 08:25 AM, Paul Gilmartin [EMAIL PROTECTED] said: It has always struck me as bizarre that the OS supports running channel programs built by problem-state programs. This is secure only if the channel programs are in effect interpreted rather than executed directly. It was secure when it was designed, since storage protection kept the application from overlaying someone else's storage. It was only with virtual storage that translation was necessary. It was only with MVS that the protection key no longer provided adequate security. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In [EMAIL PROTECTED], on 06/11/2008 at 08:03 AM, Bob Shannon [EMAIL PROTECTED] said: This indicates that EXCP is used under the covers by the higher access methods. While BSAM and QSAM use EXCP[VR], some access methods use STARTIO directly. Is there a DCB option to enable EXCP for extended data sets? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Paul, Did you my earlier response? Extended format Sequential datasets (DSORG=PS-E) can be accessed by QSAM and BSAM access methods. ADRDSSU does not use BSAM or QSAM. It uses EXCP. That's it. Ron Paul, It is not the DSORG that has to support Extended Format, it is the ACCESS METHOD. The DSORG defines and extended format dataset, but the Access Method has to support IO to it. As far as I know QSAM and BSAM are the only Access Methods that support PS-E. Before converting to PS-E on a large scale you need to check for datasets that are being accessed by other Access Methods. You can find this in the Type 14 and 15 SMF records. If you have MXG this is a relatively simple exercise - sometimes the harder part is incorporating the results into your ACS logic. Also be aware that some utilities like DFSORT and SYNCSORT will automatically detect PS-E and use BSAM to process the files in place of EXCP. You don't have to exclude datasets just because you sort them. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ip Sent: Wednesday, June 11, 2008 6:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] EXCP access methos Hi all, Can anyone give me another hint on this?? I am confused with what makes an output of ADRDSSU DUMP can't be Extended Format? On Wed, 11 Jun 2008 08:51:26 -0500, Paul Ip [EMAIL PROTECTED] wrote: Thanks for the reply! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Rick Fochtman wrote: Dear God, how I wish there was a documented interface to STARTIO; I'd like to play around with Format-1 CCW's. :-) Format-1 CCWs have been supported by EXCP for some time. To enable their use, simply turn on bit IOBEFMT1 in the IOB extension (mapped by IOSDIOBE). While you're at it, you might also wish to play around with 64-bit IDAWs, enabled via bit IOBEEIDA, used for I/O areas above the bar. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Oh, I missed your reply since I used the full subject search... Now, I've used Strobe to perform some testings and it matches what you've said: 1. ADRDSSU DUMP uses EXCP so I can only use DSNTYPE=LARGE 2. ICEGENER (DFSORT) uses (auto detects) EXCP for non-EF datasets and BSAM for EF datasets 3. IDCAMS uses QSAM for either EF or non-EF datasets 4. COBOL uses QSAM for either EF or non-EF datasets Well, it is clear that my concept was wrong: DSORG=PS uses QSAM access method only Paul On Wed, 11 Jun 2008 23:04:25 -0700, Ron Hawkins [EMAIL PROTECTED] wrote: Paul, Did you my earlier response? Extended format Sequential datasets (DSORG=PS-E) can be accessed by QSAM and BSAM access methods. ADRDSSU does not use BSAM or QSAM. It uses EXCP. That's it. Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Paul, Mou man tai. My spellchecker changed the heading in my earlier post. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Ip Sent: Thursday, June 12, 2008 12:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] EXCP access methos Oh, I missed your reply since I used the full subject search... Now, I've used Strobe to perform some testings and it matches what you've said: 1. ADRDSSU DUMP uses EXCP so I can only use DSNTYPE=LARGE 2. ICEGENER (DFSORT) uses (auto detects) EXCP for non-EF datasets and BSAM for EF datasets 3. IDCAMS uses QSAM for either EF or non-EF datasets 4. COBOL uses QSAM for either EF or non-EF datasets Well, it is clear that my concept was wrong: DSORG=PS uses QSAM access method only Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
On Thu, 12 Jun 2008 01:14:26 -0700, Ron Hawkins [EMAIL PROTECTED] wrote: Paul, Mou man tai. My spellchecker changed the heading in my earlier post. Ron Mou man tai ---You know Cantonese??! (thanks for your reply) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
On Thu, 12 Jun 2008 01:14:26 -0700, Ron Hawkins [EMAIL PROTECTED] wrote: Paul, Mou man tai. My spellchecker changed the heading in my earlier post. Ron Mou man tai - You know Cantonese??! (Thanks for your reply) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In a message dated 6/11/2008 7:27:53 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: I wish there was a documented interface to STARTIO; I'd like to play around with Format-1 CCW's. :-) In AUG 1987 there were two sessions by two different presenters (I was one of them) at SHARE in Chicago on how to use STARTIO. In my session, I distributed a simple, sample program that used STARTIO to read the volume label from a DASD volume. If you can find this session in the SHARE archives, that handout is in the proceedings. IBM has not chosen to make STARTIO an externally documented interface. The main danger in using STARTIO is when you build a channel program with real addresses that has read CCWs in it, as you can easily overlay storage that is not yours. Write CCWs will not overlay storage, but you will write the wrong data out to the I/O device if you get those real addresses wrong. As with any other authorized service, STARTIO must be used cautiously. Or, as Ed Jaffe suggested, you can use Format 1 CCWs with EXCP in unauthorized code. If your code is authorized, there is a lot more you can do by modifying DEB fields after you OPEN your DCB. Bill Fairchild Rocket Software **Vote for your city's best dining and nightlife. City's Best 2008. (http://citysbest.aol.com?ncid=aolacg0005000102) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
snip- Oh, I missed your reply since I used the full subject search... Now, I've used Strobe to perform some testings and it matches what you've said: 1. ADRDSSU DUMP uses EXCP so I can only use DSNTYPE=LARGE 2. ICEGENER (DFSORT) uses (auto detects) EXCP for non-EF datasets and BSAM for EF datasets 3. IDCAMS uses QSAM for either EF or non-EF datasets 4. COBOL uses QSAM for either EF or non-EF datasets Well, it is clear that my concept was wrong: DSORG=PS uses QSAM access method only ---unsnip- Some of the older utilities still use BSAM; like IEHMOVE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
-snip- Or, as Ed Jaffe suggested, you can use Format 1 CCWs with EXCP in unauthorized code. If your code is authorized, there is a lot more you can do by modifying DEB fields after you OPEN your DCB. ---unsnip BTDT. I once modified AMASPZAP to a full-volume ZAPPER by modifying the extent fields in the DEB. If you specified a dsname of FORMAT5.DSCB on the SYSLIB DD statement, I opened the VTOC, then modified the extent values in the DEB. Fun to play with, but didn't really serve any useful purpose. I have no idea where that program is now. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
(IBM Mainframe Discussion List) wrote: ... The main danger in using STARTIO is when you build a channel program with real addresses that has read CCWs in it, as you can easily overlay storage that is not yours. Write CCWs will not overlay storage, but you will write the wrong data out to the I/O device if you get those real addresses wrong. As with any other authorized service, STARTIO must be used cautiously. Real CCW addresses are also used by the documented EXCPVR interface. The biggest problem with STARTIO is that there is no allocation, DCB, or OPEN required. All it needs is an IOSB -- which contains pointers to the channel program and UCB. Using STARTIO, you can construct a channel program to read or write any records anywhere on any device. This puts you one subtle programming error away from wiping out something important that isn't yours. The other danger is having to write code that executes in SRB mode -- with PSW key zero -- to manage I/O completion. Without question, STARTIO is a dangerous interface -- made even more dangerous by the total lack of documentation on its use. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
---snip- Real CCW addresses are also used by the documented EXCPVR interface. The biggest problem with STARTIO is that there is no allocation, DCB, or OPEN required. All it needs is an IOSB -- which contains pointers to the channel program and UCB. Using STARTIO, you can construct a channel program to read or write any records anywhere on any device. This puts you one subtle programming error away from wiping out something important that isn't yours. The other danger is having to write code that executes in SRB mode -- with PSW key zero -- to manage I/O completion. Without question, STARTIO is a dangerous interface -- made even more dangerous by the total lack of documentation on its use. unsnip-- Given the potential risks, I think that I'll stick to EXCP with Format-1 CCW's. If this is going to be a public-domain program, I'd rather be safe than sorry; and I don't want to give someone the rope they might use to hang themselves. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In a message dated 6/12/2008 11:42:05 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Real CCW addresses are also used by the documented EXCPVR interface. True. And you have to get the real addresses correct with EXCPVR, or you will hose storage on read commands. The biggest problem with STARTIO is that there is no allocation, DCB, or OPEN required. I never considered this a problem but a major benefit, and one of several reasons why I use STARTIO. If you are authorized enough to use EXCPVR, you can also use EXCP, modify the DEB, and get to any device which you have not allocated, enqueued upon, or OPENed a DCB for. There are times when such things are necessary. The lower the level access method you use, the more flexibility you have, the more things you can do, sometimes the more things you have to do (e.g., block/deblock with BSAM but not with QSAM), and, at a low enough level, the more dangerous it becomes. All it needs is an IOSB -- which contains pointers to the channel program and UCB. Using STARTIO, you can construct a channel program to read or write any records anywhere on any device. This puts you one subtle programming error away from wiping out something important that isn't yours. Which is why you test your STARTIO code, and anything else you build that is authorized, on test systems that everyone else knows may not survive your test. You can also wipe out something that is not yours with an incorrect real address on a read command using the much safer EXCPVR. When you are building authorized code, you must write each instruction with the awareness that you can unexpectedly hose almost any conceivable part of MVS if you err. The other danger is having to write code that executes in SRB mode -- with PSW key zero -- to manage I/O completion. Many posters have demonstrated a familiarity with coding SRBs. I assume a poster is competent enough to do whatever is necessary whenever he finds out whatever prompted him to post a question. The original mention of STARTIO seemed to me more like intellectual curiosity than a desire to build a production program with possibly massive, hidden dangers in it. There are plenty of other dangers, too; e.g., in STARTIO you must build your channel program in and have all your data in fixed storage, and also make your address space nonswappable. You can screw up either of these and possibly hose something. Without question, STARTIO is a dangerous interface -- made even more dangerous by the total lack of documentation on its use. Not completely total. Only officially. Long ago intrepid developers discovered several IBM software products using STARTIO (JES3, IMS) whose source code was distributed, and they copied the code surrounding those STARTIOs. I learned how to do it from a photocopy of a photocopy of a ... from someone in Amdahl in 1985. And when I explained publicly how to use STARTIO in SHARE, I emphasized many times how easy it was to hose things with STARTIO and to be very, very careful. Bill Fairchild Rocket Software **Vote for your city's best dining and nightlife. City's Best 2008. (http://citysbest.aol.com?ncid=aolacg0005000102) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
(IBM Mainframe Discussion List) wrote: All it needs is an IOSB -- which contains pointers to the channel program and UCB. Using STARTIO, you can construct a channel program to read or write any records anywhere on any device. This puts you one subtle programming error away from wiping out something important that isn't yours. Which is why you test your STARTIO code, and anything else you build that is authorized, on test systems that everyone else knows may not survive your test. You can also wipe out something that is not yours with an incorrect real address on a read command using the much safer EXCPVR. When you are building authorized code, you must write each instruction with the awareness that you can unexpectedly hose almost any conceivable part of MVS if you err. The wiping out I was talking about was when writing to the disk. STARTIO does no prefixing. EXCPVR does. So, unless you do something to overlay the DEB extent information, or set the flag in the DEB to tell the system you will provide your own prefix, you are saved by MVS from accidentally writing on something important when you use EXCPVR. I agree that if you supply bad buffer addresses for read CCWs, you will clobber storage. That goes without saying. Obviously, mistakes with real storage addresses have worse (more random) ill effects and are harder to track down than mistakes with virtual addresses. Good thing we have GTF. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Rick Fochtman wrote: Given the potential risks, I think that I'll stick to EXCP with Format-1 CCW's. If this is going to be a public-domain program, I'd rather be safe than sorry; and I don't want to give someone the rope they might use to hang themselves. :-) And, EXCP is an ordinary unauthorized interface. STARTIO and EXCPVR are not. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EXCP access methos
Hi, Today, I was trying to have a DSORG=PS DASD dataset (output from ADRDSSU DUMP) with Extended Format, it failed with IEC143I 213-B8, where B8 means An OPEN was attempted against an extended-format data set with a DCB that specified EXCP. EXCP is not supported for extended-format data sets according to manul. Finally, I specified DSNTYPE=LARGE instead to overcome the 65535 tracks per volume limit. However, I don't know that output file (DSORG=PS) from ADRDSSU is using EXCP access method and how do I know if a DASD dataset was proccessed by EXCP instead of QSAM access method?? Is that the DCB=(DSORG=PS,LRECL=0,RECFM=U,BLKSIZE=27998) means the dataset was processed by EXCP access method?? Can anyone give me a hint? Thanks Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Every access method uses Excp, every Excp uses STARTIO and every STARTIO uses SSCH. On 6/11/08, Paul Ip [EMAIL PROTECTED] wrote: Hi, Today, I was trying to have a DSORG=PS DASD dataset (output from ADRDSSU DUMP) with Extended Format, it failed with IEC143I 213-B8, where B8 means An OPEN was attempted against an extended-format data set with a DCB that specified EXCP. EXCP is not supported for extended-format data sets according to manul. Finally, I specified DSNTYPE=LARGE instead to overcome the 65535 tracks per volume limit. However, I don't know that output file (DSORG=PS) from ADRDSSU is using EXCP access method and how do I know if a DASD dataset was proccessed by EXCP instead of QSAM access method?? Is that the DCB=(DSORG=PS,LRECL=0,RECFM=U,BLKSIZE=27998) means the dataset was processed by EXCP access method?? Can anyone give me a hint? Thanks Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Paul Ip wrote: [...] Is that the DCB=(DSORG=PS,LRECL=0,RECFM=U,BLKSIZE=27998) means the dataset was processed by EXCP access method?? EXCP is low level access method, so DSORG is not a clue. In fact EXCP access method is a kind of general description for any untypical access methods and their possible untypical shortcomings. It can be no support for extfmt-PS, it can be limitation to first 64k tracks on volume (afaik it existed in Adabas), it can be geometry-dependance etc. etc. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
R.S. [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Paul Ip wrote: [...] Is that the DCB=(DSORG=PS,LRECL=0,RECFM=U,BLKSIZE=27998) means the dataset was processed by EXCP access method?? EXCP is low level access method, so DSORG is not a clue. In fact EXCP access method is a kind of general description for any untypical access methods and their possible untypical shortcomings. It can be no support for extfmt-PS, it can be limitation to first 64k tracks on volume (afaik it existed in Adabas), it can be geometry-dependance etc. etc. -- Radoslaw Skorupka At a higher level, the difference between EXCP and an Access Methods is that if 'you' do I/O with EXCP, 'you' build your own channel programs i.s.o. the Access Method, so 'you' must enhance your application to support extended format datasets, i.s.o. the Access Method. If you use an Access Method you can expect IBM to enhance the Access Method to support the new datasets. Kees. ** 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
On Wed, 11 Jun 2008 08:03:27 -0400, Bob Shannon wrote: In fact EXCP access method is a kind of general description for any untypical access methods and their possible untypical shortcomings. It can be no support for extfmt-PS, it can be limitation to first 64k tracks on volume (afaik it existed in Adabas), it can be geometry-dependance etc. etc. EXCP is a perfectly valid access method; it just requires more skill, and more detailed work, then using something such as QSAM. Regardless of the access method, CCWs are used to access data on a volume. This indicates that EXCP is used under the covers by the higher access methods. The only reason that EXCP cannot be used for extended format datasets or PDSEs is that IBM installed checks to prevent it. There is nothing inherent in EXCP itself that prevents it from being used for any data type. I'm naive here. I suspect many of my misconceptions will be promptly corrected. It's my understanding that for many decades EXCP has not executed channel programs in place and as provided by the caller. Rather, they are moved to protected storage so the user can not modify them on the fly; they are prefixed to prevent seeks to prohibited tracks; virtual addresses are translated to real; etc. I'd further expect changes to CCW architecture to accommodate XA and later 64-bit addressing and new I/O architecture. So the checks to prevent it may be a matter of IBM's resource allotment: rather than continually update EXCP code to all new hardware features, it's easier simply to prohibit use of EXCP for such purposes. It has always struck me as bizarre that the OS supports running channel programs built by problem-state programs. This is secure only if the channel programs are in effect interpreted rather than executed directly. A more rational layering of functions should have channel programs built only by trustworthy supervisor-state code. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Thanks for the reply! In fact, my target is to overome the 65536 tracks limit on a volume for SMS Datasets, so there are two approaches for me: 1. Extended Format 2. DSNTYPE=LARGE At the beginning, I tried to apply Extended Format for all SMS datasets, if the dataset is an output of COBOL program, assigning Extended Format is ok (DSORG=PS-E). However, it is failed when I tried to apply the Extended Format for output of ADRDSSU DUMP... Form the RC IEC143I 213-B8, it said ...a DCB that specified EXCP... I should rephrase my question as: why the output of ADRDSSU DUMP can't be assigned with Extented Format? What is actually a DCB that specified EXCP means from IEC143I 213-B8 (I was wondering if it is talking about the dataset is under a dataset type of 'EXCP'...)? ...In addition, I don't know there is a dataset type called 'EXCP' until I found the following from DFDSSdss Storage Admin. Guide: DFSMSdss can copy, dump, and restore data sets of the following types: DATABASE 2(TM) (DB2?;) Direct access EXCP (execute channel program) Dataset Type = EXCP??? Partitioned, including: PDS (partitioned data set) PDSE (partitioned data set extended) HFS (hierarchical file system) data set Sequential, including extended-format data sets and Large Format data sets VSAM data sets that are cataloged in an ICF catalog, including: ESDS (entry-sequenced data set) KSDS (key-sequenced data set) KSDS with key ranges LDS (linear data set) RRDS (relative record data set) VRRDS (variable relative record data set) Extended-format ESDS, KSDS, LDS, RRDS, and VRRDS, including striped ESDS, KSDS, LDS, RRDS, and VRRDS Extended-addressable VSAM ESDS, KSDS, LDS, RRDS, and VRRDS, including striped ESDS, KSDS, LDS, RRDS, and VRRDS zFS (zSeries? file system) data set Unmovable data set types (PSU, POU, DAU, ABSTR, ISU, and direct with OPTCD=A). Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Wednesday, June 11, 2008 8:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: EXCP access methos On Wed, 11 Jun 2008 08:03:27 -0400, Bob Shannon wrote: SNIP I'm naive here. I suspect many of my misconceptions will be promptly corrected. It's my understanding that for many decades EXCP has not executed channel programs in place and as provided by the caller. Rather, they are moved to protected storage so the user can not modify them on the fly; they are prefixed to prevent seeks to prohibited tracks; virtual addresses are translated to real; etc. I'd further expect changes to CCW architecture to accommodate XA and later 64-bit addressing and new I/O architecture. So the checks to prevent it may be a matter of IBM's resource allotment: rather than continually update EXCP code to all new hardware features, it's easier simply to prohibit use of EXCP for such purposes. It has always struck me as bizarre that the OS supports running channel programs built by problem-state programs. This is secure only if the channel programs are in effect interpreted rather than executed directly. A more rational layering of functions should have channel programs built only by trustworthy supervisor-state code. SNIP Ok, here goes from about the 10,000' level. You are basically correct when it comes to VM. If you are not a preferred guest, then expect ALL your CCWs to be interpreted. If you are a preferred guest, then you get dispatched with SIE (Start Interpretive Execution, or some equivalent in the IEF, Interpretive Execution Facility -- been gone from H/W for too long) where VM sets certain masks And so some or all of your CCWs will basically be run as written. NOW for the MVS world. The system will start your CCWs AFTER it has run its initial chain (by a TIC to your first CCW). Depending on the H/W (devices, controllers, channels, etc.) will determine which of the control CCWs will be executed to LIMIT what your CCW string is allowed to do (such as setting CYL LIMITS where you can't seek outside of those without getting your hand slapped). I'm sure that others will be able to take you down to the settings of the ORB, SCHIB, etc. should it be needed. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Paul Ip wrote: Hi, Today, I was trying to have a DSORG=PS DASD dataset (output from ADRDSSU DUMP) with Extended Format, it failed with IEC143I 213-B8, where B8 means An OPEN was attempted against an extended-format data set with a DCB that specified EXCP. EXCP is not supported for extended-format data sets according to manul. Finally, I specified DSNTYPE=LARGE instead to overcome the 65535 tracks per volume limit. However, I don't know that output file (DSORG=PS) from ADRDSSU is using EXCP access method and how do I know if a DASD dataset was proccessed by EXCP instead of QSAM access method?? Is that the DCB=(DSORG=PS,LRECL=0,RECFM=U,BLKSIZE=27998) means the dataset was processed by EXCP access method?? Can anyone give me a hint? Thanks Technically, you can never really be sure if EXCP was used for a supported data set. The gentleman's agreement used by z/OS applications is the specification of MACRF=E on the DCB at OPEN time. For EF data sets, that triggers the abend you are seeing. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
-snip- I'm naive here. I suspect many of my misconceptions will be promptly corrected. It's my understanding that for many decades EXCP has not executed channel programs in place and as provided by the caller. Rather, they are moved to protected storage so the user can not modify them on the fly; they are prefixed to prevent seeks to prohibited tracks; virtual addresses are translated to real; etc. I'd further expect changes to CCW architecture to accommodate XA and later 64-bit addressing and new I/O architecture. So the checks to prevent it may be a matter of IBM's resource allotment: rather than continually update EXCP code to all new hardware features, it's easier simply to prohibit use of EXCP for such purposes. -unsnip--- Don't forget adjustments made for non-contiguous real storage areas containing buffers, etc. (IDAW anyone?) :-) snip It has always struck me as bizarre that the OS supports running channel programs built by problem-state programs. This is secure only if the channel programs are in effect interpreted rather than executed directly. A more rational layering of functions should have channel programs built only by trustworthy supervisor-state code. --unsnip Makes perfect sense to me. Under OS/360, we didn't have the protection that CCW translation gives us today and it was incredibly easy to destroy part of the OS. But EXCP is much of the mechanism for developing support for new or exotic devices, like the old MCR/OCR gear that was so doggone timing-sensitive. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
--snip- Every access method uses Excp, every Excp uses STARTIO and every STARTIO uses SSCH. --unsnip--- IIRC, VSAM and the VSAM-like access methods use STARTIO directly. At least those AM's that are ACB/RPL based. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
In a message dated 6/11/2008 8:25:57 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: It's my understanding that for many decades EXCP has not executed channel programs in place and as provided by the caller. Back in the days before paging systems, back when there was no virtual or real storage, back when storage was just called storage, EXCP would execute the channel program in place and as provided by the caller, but with extra CCWs in front of the caller's first CCW. These extra CCWs were added to insure data set integrity; i.e., the caller's channel program cannot go to any track that is not in the list of allocated extents created by OPEN. I don't remember for sure, but it was probably possible for a caller to have a read command executed with a storage address that would cause data being read to overlay storage that was outside his region, partition, or whatever the big chunk of storage was called. So you could clobber the operating system as well as other users' central storage with read commands. The various DASD access methods on these systems (OS/360, DOS/360, TOS/360, and BPS/360) were QSAM, BSAM, BPAM, BDAM, ISAM, and QISAM. They all used EXCP internally to do I/O requests, except for possibly ISAM which sometimes had a naked SIO instruction (or so I was told). I don't know very much about the other access methods for devices other than DASD and tape (e.g., TCAM, QTAM, and BTAM), but I would guess that they all also used EXCP internally. With the advent of virtual and real storage, IBM chose to require that the data addresses inside CCWs be interpreted by the I/O hardware as real addresses. Thus a scheme was needed to convert from virtual addresses to real addresses in order to make the transition to the new systems transparent to customers. The MVS architects decided to create a new I/O concept called IOS Driver which is a new layer of software that performs I/O requests without having to use EXCP. They also invented a new access method called STARTIO which replaced EXCP as the lowest possible level access method. The ancient DASD access methods, QSAM etc., still use EXCP, but EXCP was redesigned to interface between the callers of EXCP (ancient access methods), which present EXCP with channel programs containing virtual addresses, and the new lower level and thus intermediate, internal access method called STARTIO, which assumes that the channel program is in non-pageable storage, with real addresses of data, and which was built by a trusted software component. Many new functions in MVS were designed to use STARTIO directly themselves, such as the paging supervisor, while some new MVS components were designed to use EXCP, probably in order to get the new code written most quickly. JES2, e.g., originally used EXCP (I haven't dealt with JES2 internals now for 20+ years, so it may be different now), probably because JES2 was developed from HASP, which used EXCP, and that code was already well debugged, so why rewrite it? Rather, they are moved to protected storage so the user can not modify them on the fly Yes, unless you have EXCP appendages, but these must be loaded from an authorized library, so the customer can control their use. they are prefixed to prevent seeks to prohibited tracks; virtual addresses are translated to real; etc. I'd further expect changes to CCW architecture to accommodate XA and later 64-bit addressing and new I/O architecture. Correct on all counts. So the checks to prevent it may be a matter of IBM's resource allotment: rather than continually update EXCP code to all new hardware features, it's easier simply to prohibit use of EXCP for such purposes. I concur. Also IBM would like to encourage users to migrate all applications to the latest and greatest software and hardware solutions; namely, VSAM, DFSMS, ESS controllers, etc., so typically IBM adds support to strategic products and components first and then maybe, reluctantly and much later, to non-strategic components. They, too, have limited resources for developing new products and adding support for new products into other, older, products that must interface with the new products. It has always struck me as bizarre that the OS supports running channel programs built by problem-state programs. This is secure only if the channel programs are in effect interpreted rather than executed directly. A more rational layering of functions should have channel programs built only by trustworthy supervisor-state code. I don't know to what you are referring here by the OS. Problem-state programs in z/OS build channel programs which are then converted to safe, trusted equivalent channel programs by trusted software components before being started by IOS. In VM, CCWs are not interpreted as far as I know, but rather the channel program is scanned before being
Re: EXCP access methos
I don't remember for sure, but it was probably possible for a caller to have a read command executed with a storage address that would cause data being read to overlay storage that was outside his region, partition, or whatever the big chunk of storage was called. So you could clobber the operating system as well as other users' central storage with read commands. I don't think so. I remember writing code for OS/360 that, during early testing, incorrectly calculated a buffer size requirement. Sure enough, when a subsequent READ CCW tried to read into beyond the end of the GETMAINed area, a S0C4 was the result because the following storage was in Key0. (This may have been either MFT or MVT -- can't remember. I seem to remember that MVT was more robust in terms of storage keys for OS related control blocks, etc.) Date: Wed, 11 Jun 2008 11:51:26 -0400 From: [EMAIL PROTECTED] Subject: Re: EXCP access methos To: IBM-MAIN@BAMA.UA.EDU In a message dated 6/11/2008 8:25:57 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: It's my understanding that for many decades EXCP has not executed channel programs in place and as provided by the caller. Back in the days before paging systems, back when there was no virtual or real storage, back when storage was just called storage, EXCP would execute the channel program in place and as provided by the caller, but with extra CCWs in front of the caller's first CCW. These extra CCWs were added to insure data set integrity; i.e., the caller's channel program cannot go to any track that is not in the list of allocated extents created by OPEN. I don't remember for sure, but it was probably possible for a caller to have a read command executed with a storage address that would cause data being read to overlay storage that was outside his region, partition, or whatever the big chunk of storage was called. So you could clobber the operating system as well as other users' central storage with read commands. The various DASD access methods on these systems (OS/360, DOS/360, TOS/360, and BPS/360) were QSAM, BSAM, BPAM, BDAM, ISAM, and QISAM. They all used EXCP internally to do I/O requests, except for possibly ISAM which sometimes had a naked SIO instruction (or so I was told). I don't know very much about the other access methods for devices other than DASD and tape (e.g., TCAM, QTAM, and BTAM), but I would guess that they all also used EXCP internally. With the advent of virtual and real storage, IBM chose to require that the data addresses inside CCWs be interpreted by the I/O hardware as real addresses. Thus a scheme was needed to convert from virtual addresses to real addresses in order to make the transition to the new systems transparent to customers. The MVS architects decided to create a new I/O concept called IOS Driver which is a new layer of software that performs I/O requests without having to use EXCP. They also invented a new access method called STARTIO which replaced EXCP as the lowest possible level access method. The ancient DASD access methods, QSAM etc., still use EXCP, but EXCP was redesigned to interface between the callers of EXCP (ancient access methods), which present EXCP with channel programs containing virtual addresses, and the new lower level and thus intermediate, internal access method called STARTIO, which assumes that the channel program is in non-pageable storage, with real addresses of data, and which was built by a trusted software component. Many new functions in MVS were designed to use STARTIO directly themselves, such as the paging supervisor, while some new MVS components were designed to use EXCP, probably in order to get the new code written most quickly. JES2, e.g., originally used EXCP (I haven't dealt with JES2 internals now for 20+ years, so it may be different now), probably because JES2 was developed from HASP, which used EXCP, and that code was already well debugged, so why rewrite it? Rather, they are moved to protected storage so the user can not modify them on the fly Yes, unless you have EXCP appendages, but these must be loaded from an authorized library, so the customer can control their use. they are prefixed to prevent seeks to prohibited tracks; virtual addresses are translated to real; etc. I'd further expect changes to CCW architecture to accommodate XA and later 64-bit addressing and new I/O architecture. Correct on all counts. So the checks to prevent it may be a matter of IBM's resource allotment: rather than continually update EXCP code to all new hardware features, it's easier simply to prohibit use of EXCP for such purposes. I concur. Also IBM would like to encourage users to migrate all applications to the latest and greatest software and hardware solutions; namely, VSAM, DFSMS, ESS controllers, etc., so typically IBM adds support
Re: EXCP access methos
(IBM Mainframe Discussion List) wrote: Back in the days before paging systems, back when there was no virtual or real storage, back when storage was just called storage, EXCP would execute You had storage? All of our programmers had core, and persisted in that usage even into the late seventies. remember for sure, but it was probably possible for a caller to have a read command executed with a storage address that would cause data being read to overlay storage that was outside his region, partition, or whatever the big chunk of Potential storage overlays were controlled by protect keys, providing the hardware supported them and the operating system set them correctly. In PCP all of storage was fair game, in MFT and MVT it was harder (there were a couple of loopholes in SVC parameter validity checking that IBM fixed eventually). I do remember clobbering storage in MVT reading a 2314 sized track buffer from a 3330, and lucking out with an add-on memory whose protection capability had not been configured correctly. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (, IBM Mainframe Discussion List) writes: In VM, CCWs are not interpreted as far as I know, but rather the channel program is scanned before being executed in order to determine how to let it run safely on its own. The only way I can think of to execute a channel program interpretively is to do a separate I/O request for each CCW in the channel program (of course, with the necessary CCWs in front of it for it to work correctly). Then if a CCW reads data, the data would be read somewhere that VM could trust, and then move that data into the caller's buffer. This is similar to how interpretive machine instruction is handled. But the overhead in interpreting channel programs would be prohibitive, I believe, so they are not really interpreted. They are first made safe with the proper CCWs in front of those supplied by the problem-state caller and then allowed to run on their own. CCWTRANS was the CP67 routine that created a shadow copy of virtual machine channel program. channels run with real data transfer addresses. virtual machine (and VS system application EXCP ) channel programs have virtual address. CCWTRANS scanned the virtual machine channel program ... creating a shadow copy of the virtual machine channel program ... fetching/fixing the related virtual addresses ... and replacing the virtual addresses with real addresses. The original translation of os/360 to virtual storage operation included crafting a copy of (cp67's) CCWTRANS into the side of VS2 ... to perform the equivalent function of EXCP channel programs (whether application or access methods). VS2 (SVS then MVS) has had the same problem with access methods (and other applications) creating channel programs with virtual addresses ... and then issuing EXCP. At that point, EXCP processing has the same problem as virtual machine emulation ... translating channel programs built with virtual addresses into shadow copy that has real addresses. EXCPVR was introduced to indicate that a channel program with real addresses was being used (rather than traditional EXCP channel program). A discussion of EXCPVR: http://publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.idas300/efcprs.htm#efcprs disk seek channel commands ... for virtual machine non-full-pack minidisks would have also result in a shadow made of the seek argument ... adjusting it as appropriate (i.e. a minidisk could be for 30 cyls starting at real cylinder 100 ... the shadow would have cylinder numbers adjusted by 100 ... unless it attempted to access more than 30 cyls ... which would result in shadow being adjusted to an invalid cylinder number). OS360 used 3 channel command prefix ... SEEK, followed by set file mask command and then TIC (transferred) to the channel program referenced by EXCP (didn't need to scan/translate the passed channel program ... just position the arm and then prevent the passed channel program from moving the arm again. There was a version of CP67 that was converted to run on 370s (CP67-I system) ... which was used extensively inside IBM pending availability of VM370 product. In the morph of CP67 to VM370 product, the CCWTRANS channel program translation routine became DMKCCW. past posts mentioning VS2 effort started out by crafting cp67 CCWTRANS to get channel program translation for EXCP: http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love? http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline? http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline? http://www.garlic.com/~lynn/2001l.html#36 History http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?) http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post) http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems http://www.garlic.com/~lynn/2002n.html#62 PLX http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not all or nothing. Re: Multics Concepts For http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect http://www.garlic.com/~lynn/2004n.html#54 CKD Disks? http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005b.html#49 The
Re: EXCP access methos
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. Anne Lynn Wheeler [EMAIL PROTECTED] writes: There was a version of CP67 that was converted to run on 370s (CP67-I system) ... which was used extensively inside IBM pending availability of VM370 product. In the morph of CP67 to VM370 product, the CCWTRANS channel program translation routine became DMKCCW. re: http://www.garlic.com/~lynn/2008i.html#68 EXCP access methos an early use of the internal network was distributed development project between the science center and endicott. the internal network technology was created at the science center (as well as cp67, gml, lots of other stuff) http://www.garlic.com/~lynn/subtopic.html#545tech the internal network was larger than the arpanet/internet from just about the beinning to possibly mid-85 http://www.garlic.com/~lynn/subtopic.html#internalnet the 370 virtual memory hardware architecture was well specified ... and endicott approached the science center about providing 370 virtual machine support for early software testing ... i.e. in addition to providing 360 and 360/67 virtual memory emulation ... cp67 would be modified to also provide option for 370 and 370 virtual memory emulation. the original cms multi-level source maintenance system was developed as part of this effort (cms cp67 had source maintenance but was single level update). part of the issue was that this would run on the science center cp67 time-sharing system which including access by numerous non-employees (many from various educational institutions in the cambridge/boston area). 370 virtual memory was a closely held corporate secret and so there had to be a lot of (security) measures to prevent it being divulged. the basic cambridge cp67 time-sharing system ran CP67-L. eventually, in a 360/67 virtual machine, a CP67-H kernel ran which had the modifications to provide 370 virtual machines as an option. This provided isolation, preventing the general time-sharing users from being exposed to any of the 370 features. then a set of updates were created that modified the CP67 kernel to run on 370 hardware a CP67-I kernel would then run in a 370 virtual machine provided by a CP67-H kernel running in a 360/67 virtual machine. CP67-I was in regular operation a year before the first engineeing 370 machine with virtual memory hardware was working. In fact, CP67-I was used as a test case when that first engineering machine became operational. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
On Wed, 11 Jun 2008 10:41:11 -0500, Rick Fochtman [EMAIL PROTECTED] wrote: . . . IIRC, VSAM and the VSAM-like access methods use STARTIO directly. Directly? I thought that the move had been to use the Media Manager. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
On Wed, 11 Jun 2008 10:41:11 -0500, Rick Fochtman [EMAIL PROTECTED] wrote:_ (mailto:[EMAIL PROTECTED] wrote:) IIRC, VSAM and the VSAM-like access methods use STARTIO directly. In a message dated 6/11/2008 5:36:57 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Directly? I thought that the move had been to use the Media Manager. I don't know what VSAM-like access methods are. For the last 15 years or so (or more) IBM has used the Media Manager to do DASD I/O in its new, strategic software products (e.g., DB2). VSAM has been an official access method since the introduction of paging operating systems in the mid-1970s. The Media Manager uses STARTIO to do its I/O. Bill Fairchild Rocket Software **Vote for your city's best dining and nightlife. City's Best 2008. (http://citysbest.aol.com?ncid=aolacg0005000102) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
-snip-. IIRC, VSAM and the VSAM-like access methods use STARTIO directly. Directly? I thought that the move had been to use the Media Manager. unsnip-- You may well be right, today. But Media Manager didn't exist, as such, until long after VSAM and VTAM. In all honesty, I'm not real sure what the sequence of development was, but I have some OLD VSAM source code that uses STARTIO, rather than EXCP, because of the channel programs it creates. It also contains PAGEFIX and PAGEFREE code, so I'm assuming that it's a step above your basic EXCP code. Dear God, how I wish there was a documented interface to STARTIO; I'd like to play around with Format-1 CCW's. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXCP access methos
Hi all, Can anyone give me another hint on this?? I am confused with what makes an output of ADRDSSU DUMP can't be Extended Format? On Wed, 11 Jun 2008 08:51:26 -0500, Paul Ip [EMAIL PROTECTED] wrote: Thanks for the reply! In fact, my target is to overome the 65536 tracks limit on a volume for SMS Datasets, so there are two approaches for me: 1. Extended Format 2. DSNTYPE=LARGE At the beginning, I tried to apply Extended Format for all SMS datasets, if the dataset is an output of COBOL program, assigning Extended Format is ok (DSORG=PS-E). However, it is failed when I tried to apply the Extended Format for output of ADRDSSU DUMP... Form the RC IEC143I 213-B8, it said ...a DCB that specified EXCP... I should rephrase my question as: why the output of ADRDSSU DUMP can't be assigned with Extented Format? What is actually a DCB that specified EXCP means from IEC143I 213-B8 (I was wondering if it is talking about the dataset is under a dataset type of 'EXCP'...)? ...In addition, I don't know there is a dataset type called 'EXCP' until I found the following from DFDSSdss Storage Admin. Guide: DFSMSdss can copy, dump, and restore data sets of the following types: DATABASE 2(TM) (DB2?;) Direct access EXCP (execute channel program) Dataset Type = EXCP??? Partitioned, including: PDS (partitioned data set) PDSE (partitioned data set extended) HFS (hierarchical file system) data set Sequential, including extended-format data sets and Large Format data sets VSAM data sets that are cataloged in an ICF catalog, including: ESDS (entry-sequenced data set) KSDS (key-sequenced data set) KSDS with key ranges LDS (linear data set) RRDS (relative record data set) VRRDS (variable relative record data set) Extended-format ESDS, KSDS, LDS, RRDS, and VRRDS, including striped ESDS, KSDS, LDS, RRDS, and VRRDS Extended-addressable VSAM ESDS, KSDS, LDS, RRDS, and VRRDS, including striped ESDS, KSDS, LDS, RRDS, and VRRDS zFS (zSeries? file system) data set Unmovable data set types (PSU, POU, DAU, ABSTR, ISU, and direct with OPTCD=A). Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
