Try Googling for a simple sample program using EXCP. I'm sure there must be several on the CBT tape. I think you would have to use EXCP rather than BSAM since BSAM apparently only supports 64-bit buffer addresses for extended data sets, and your data set may not be extended.
Instead of doing an EXCP and WAIT and trying to set up all the control blocks correctly, there is also XDAP which does both an EXCP and immediately after that a WAIT. It also builds the CCWs and control blocks as part of the macro expansion. It's much easier to use than EXCP, but you may also need to manipulate a CCW and some of the control blocks just a little yourself. XDAP is also in the dfp Advanced Services book. 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 Scott Ford Sent: Thursday, September 13, 2012 8:57 AM To: [email protected] Subject: Re: Data spaces vs hiperspaces 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.
