Bill, I appreciate your explanation. One point is that us older sysprogs and developers were used to IBM PLMs and we no long have those manuals that I am aware of. Many of us those and ource code were our source of leaning. I learned CICS that way and VM , many moons ago. My point is the industry needs more working examples, like what you referred to in you explanation. I understand designing and writing the code, but many times your in a time crunch and why reinvent the wheel...
Scott ford www.identityforge.com On Sep 13, 2012, at 9:23 AM, Bill Fairchild <[email protected]> wrote: > Look in SYS1.MACLIB(IOSDIOBE) for the IOB Extension DSECT. I don't know what > the book says about using all these fields, as I have not coded an EXCP in > many years. But if these fields are in the IOBE, I would assume that > unauthorized programs, which have always been able to use EXCP, can also now > use the iOB extension and some of these 64-bit-related fields and/or flag > bits. > Try doing this: build a chain of Format 1 CCWs in virtual storage; turn on > the IOBEFMT1 flag bit to tell EXCP that you are using Format 1 CCWs; in the > 4-byte data address area in your read or write CCW, store the 31-bit address > of your virtual indirect address list which consists of one or more double > word addresses; follow the description in the Principles of Operations as you > build the many 8-byte entries in the indirect address list that you will need > (each entry covers a maximum of 4K bytes); turn on the IOBEEIDA flag bit to > tell EXCP that your indirect address list has 8-byte-long entries each of > which transfers up to 4K bytes. Also turn on the IDAL flag bit in the > read/write CCW that is transferring data into or out of your I/O buffer above > the bar. > Most of the other flag bits in the IOBE look as if they ought to require APF > authorization to use, but not necessarily the MIDAW bit. > > What should happen is this: Your 31-bit addressing mode program does the > EXCP; EXCP knows your channel program has only virtual addresses in it; EXCP > builds another indirect address list with 8-byte real addresses in it that > corresponding to successively higher 4K virtual addresses in your virtual > indirect address list pointed to by your read/write CCW; EXCP builds all the > STARTIO-level control block structure based on your IOB and DEB, mostly, then > queues the I/O request with a STARTIO macro; IOS starts the I/O with a SSCH > instruction and returns to your next instruction after the EXCP macro; you > WAIT on an ECB linked to this I/O request; when the WAIT is satisfied, voila! > There is your data above the bar if you were doing a read operation. > Be prepared for some interesting ABENDs, GTF traces, and general mayhem and > merriment. Sooner or later there will be great joy in Muddville, as hope > deferred makes the heart sick, but when the desire comes it is a tree of life. > > If EXCP can now support I/O directly to a virtual buffer address above the > bar, then QSAM and BSAM can, too, since they use EXCP internally to do their > I/O requests. I found the following quote in my copy of the dfp Advanced > Services book, which describes how to use EXCP: > "When the CCW points to an indirect address list (IDAL), each indirect address > list word (IDAW) in the list points to a 31-bit or 64-bit I/O buffer, > depending on > whether 31-bit or 64-bit IDAWs are used..." > And I found the following quote in my copy of the Macro Instructions for Data > Sets book: > "There are only two non-VSAM access method macros that accept a 64-bit virtual > address. The READ and WRITE macros support the data area address being a > 64-bit virtual address if the data set is extended format and not compressed > format. Your program must be running in 31-bit mode. You must code the SF64 or > SF64P option on the READ or WRITE macro." > Using a READ or WRITE macro means you are using BSAM, so therefore BSAM now > is documented as supported 64-bit virtual addresses for data buffers. > > Bill Fairchild > Programmer > Rocket Software > 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA > t: +1.617.614.4503 * e: [email protected] * w: > www.rocketsoftware.com > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Farley, Peter x23353 > Sent: Wednesday, September 12, 2012 5:02 PM > To: [email protected] > Subject: Re: Data spaces vs hiperspaces > > PMFJI here, but even if that's true at "a level lower than EXCP", I don't > think any of the standard access methods (xSAM, x=B/Q/V) yet supports 64-bit > buffers or returned record/buffer addresses, do they? Aren't we mere mortal > application programmers still limited to 31-bit buffers? > > Peter > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Bill Fairchild > Sent: Wednesday, September 12, 2012 5:44 PM > To: [email protected] > Subject: Re: Data spaces vs hiperspaces > > Data no longer must be read into buffers in 31-bit storage. You can now do > I/O directly into or out of 64-bit virtual addresses with real backing also > in 64-bit addressing. I have been doing it for several years with BAM > (Bill's Access Method) that uses I/O services at a level lower than EXCP. > I'm sure that DB2 and other strategic products of IBM are also doing I/O with > 64-bit buffer addresses. > > Bill Fairchild > Programmer > Rocket Software > 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA > t: +1.617.614.4503 * e: [email protected] * w: > www.rocketsoftware.com > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected]] > On Behalf Of Gainsford, Allen > Sent: Wednesday, September 12, 2012 3:58 PM > To: [email protected] > Subject: Re: Data spaces vs hiperspaces > >> That said, there are circumstances where the opposite may be true: that a >> hyperspace may provide better performance than 64-bit storage. I had a case >> recently, with a program that generates large amounts of data that it needs >> to hold temporarily in storage. I tried both ways, and found that a >> hyperspace gave better performance. > >> The reason, I eventually decided, was that the data had to be initially read >> from a dataset -- and thus had to be read into 31-bit storage -- and later >> written back to a dataset -- again, having to be written from 31-bit >> storage. When it came to storing the data away, the overhead of copying it >> above the bar, and later copying it back again, was greater than the >> overhead of leaving it where it was and using a hyperspace. > >> If I'd been able to create, and later consume, the data entirely in 64-bit >> storage, the reverse would probably have been true. > >> Allen Gainsford > Info Developer, Banking Shared Services > HP Enterprise Services (South Pacific) > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system.
