Re: Common Dataspace
This has become interesting. There are three people (that I've actually met) outside IBM (well another seems to have exited recently) whose opinion I really respect in these levels that are really far outside my current abilities. When two of them argue, I pay attention. Both Shane and Ed's position seems correct, but I don't know nearly all the nuances. Where does the stuff CAS9 leaves around anchor? As a Natural/Adabas shop, we run their global buffer pool (which will (at this time) require me to allow common user key 8). How/where do I check on it's anchor point. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shane Sent: Saturday, December 08, 2007 2:16 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Common Dataspace On Fri, 2007-12-07 at 23:38 -0800, Edward Jaffe wrote: It's a CADS. It's not in *MASTER*. It's simply owned by *MASTER*. There's no code running there, and no storage living, there. And, *MASTER* is the only address space guaranteed for the life of IPL. It's routinely used for this purpose by IBM and ISV code alike. Creating the CADS there is trivial. It's the simplest solution. So ... let's just drop an SRB (which apparently doesn't qualify as code ???) in one of (the ???) most important address spaces in the system. And let's use a justification that includes: quote Correctness the design must be correct in all observable aspects. It is slightly better to be simple than correct. /quote Paying customers been asked about that ???. Shane ... -- 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: Jeff Foxworthy IBM
You might write a Redbook if :-) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: DFDSS and Copy of Offline Volumes
EMC's Infomover product accesses OFFLINE products from the mainframe... and as a result doesn't support dynamic path. Regards Bruce Hewson -- 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: Possible change to MCSOPER processing
Hello Kevin, We are required to have LOGON REQUIRED on all consoles, including SYSCONS. (HMC Operating System Messages). This allows us to IPL and reply to messages until RACF starts up and locks up the console until you sign in.but, tragically, there is no LOGON command available via SYSCONS (not 3270). Since we issue V CN(*),ACTIVATE to establish the SYSCONS, we are not able to issue the DEACTIVATEsince by this time we are not logged in. Maybe we could issue the DEACTIVATE via the process you are considering removing. Regards Bruce Hewson -- 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: Common Dataspace
On Fri, 2007-12-07 at 23:38 -0800, Edward Jaffe wrote: It's a CADS. It's not in *MASTER*. It's simply owned by *MASTER*. There's no code running there, and no storage living, there. And, *MASTER* is the only address space guaranteed for the life of IPL. It's routinely used for this purpose by IBM and ISV code alike. Creating the CADS there is trivial. It's the simplest solution. So ... let's just drop an SRB (which apparently doesn't qualify as code ???) in one of (the ???) most important address spaces in the system. And let's use a justification that includes: quote Correctness the design must be correct in all observable aspects. It is slightly better to be simple than correct. /quote Paying customers been asked about that ???. Shane ... -- 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: Common Dataspace
Ed, Not matter how simple it sounds to hang a CADS on *MASTER*'s back like some sort of KICK ME sign - if it was up to me to design the software I would endevour to find a less intrusive method (like a CADS-owning STC). Accessing the CADS afterwards would typically require storing the ALET somewhere in some anchored storage. The CADS-owning STC can protect itself with ESTAE and RESMGR to ensure that if the started task dies then the anchored storage indicates this by some method that the CADS-using programs/exits recognise. The CADS-owning STC is worth it from an ISV point of view (IMHO) purely because you do not want to be involved in any finger-pointing for problems in ASID(1). Any issues in there and you can bet that once IPCS highlights your CADS existence, then you are only a few minutes away from some problem ticket asking you to prove/state that your software was not the cause of the system problem. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: 08 December 2007 07:39 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Common Dataspace Shane wrote: The benefit (as stated earlier) is that it is *NOT* in *MASTER*. It's a CADS. It's not in *MASTER*. It's simply owned by *MASTER*. There's no code running there, and no storage living, there. And, *MASTER* is the only address space guaranteed for the life of IPL. It's routinely used for this purpose by IBM and ISV code alike. Creating the CADS there is trivial. It's the simplest solution. It's not easy to write an STC that will never terminate. If you try to protect it via SCHEDxx, someone will complain that your ISV program isn't smart enough if must resort such updates. And, the more function you add to it over time, the more likely it will be to crash on its own, need to be canceled, and/or need to be recycled to pick up new code, etc. thus creating exposures for the CADS you were trying to protect in the first place. In the old days, we used to say the best option was KISS. But, Richard Gabriel superseded with his Worse is Better philosophy. A MUST READ for anyone in the software development business. A good synopsis can be found here. http://en.wikipedia.org/wiki/Worse_is_Better Follow the links if you want more detail. The MIT method was a predominant factor in nearly every software project I've ever seen get shelved. -- 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 -- 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: Common Dataspace
Martin, A couple of reasons spring to mind : (1) Short path length to perform instructions to access data in CADS (load the ALET into ARx, init Rx, SAC 512). If you are in a system exit and your purpose is to intercept and store certain information, you need to do this as quickly as possible and then get outta there. (2) Support for earlier os levels? Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Martin Packer Sent: 08 December 2007 11:38 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Common Dataspace Can someone explain to me - in this day and age - why we're talking CADS and not Shared Memory Objects (above The Bar). Thanks! Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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
EC/MCL and PTFs
Is there a way of cross-referencing hardware ECs or MCLs to z/OS software versions or PTFs required to successfully run after installation of such hardware changes? Mike Myers Mentor Services Corporation -- 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: zOS Maintenance Best Practices
On Fri, 7 Dec 2007 10:32:29 -0500, Matt Dazzo [EMAIL PROTECTED] wrote: I'm looking for latest pdf for zOS Maintenance Best Practices. I'd hunt around this area of ibm.com: http://www-03.ibm.com/servers/eserver/zseries/zos/servicetst/ (of course, since the website path hierarchy changes frequently, it may be easier to search ibm.com for Consolidated Service Test) Scott Fagen Enterprise Systems Management -- 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: Common Dataspace
Can someone explain to me - in this day and age - why we're talking CADS and not Shared Memory Objects (above The Bar). Thanks! Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Common Dataspace
Shane wrote: So ... let's just drop an SRB (which apparently doesn't qualify as code ???) in one of (the ???) most important address spaces in the system. Turn on a trace sometime and watch how many SRBs are scheduled into MSTR. Based on your response above, you might want to have a seat first. :-) And let's use a justification that includes: quote Correctness the design must be correct in all observable aspects. It is slightly better to be simple than correct. /quote I wasn't offering Gabriel's work or Wikipedia's summary of it as justification of anything. (But, I hope you found it interesting reading. Helps explain a lot about the rise of C, Windows, UNIX, et al. in spite of alternative developments based on better technology.) Rather, I was simply attempting to reiterate what most everyone already knows to be true: The simplest solution tends to be the one that works best and is least exposed to catastrophic failures in the long run. -- 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: Common Dataspace
Scheduling an SRB into the Master sure seem to be a touchy subject, I have two observations/comments. First, since the SRB is a unit of work that is independent of any existing dispatchable unit in the Master, any normal error that occurs within it has no impact on any other work in the address space. If it abends, it doesn't take a TCB with it. (The SRB must still use appropriate recovery, though.) If the SRB schedules an IRB, the IRB abending can take an unsuspecting TCB down. Of course, the SRB could overlay storage in the Master and cause a systems crash, but anything running in Key 0, Supervisor State in ANY address space can cause enough damage to bring the system down. Running in the Master probably increases this by only a very small percent. Second, the blame really goes back to IBM's design of CADS. By their very nature, any CADS should have been made persistent and NOT tied to the life of the creating address space, i.e., it should have been maintained just like CSA/SQA and not automatically freed when the owner terminated. So the only place to create a CADS that must never go away is the Master. Keith E. Moe Laid Back Software, Inc. http://www.laidbacksoftware.com (408) 749-0655 Creator of the TSO Environment and Administration Manager Product. (I also do MAINVIEW support for BMC Software, Inc.) -- 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: Common Dataspace
Martin Packer wrote: Can someone explain to me - in this day and age - why we're talking CADS and not Shared Memory Objects (above The Bar). Depending on your application, 64-bit shared memory may not be a viable replacement for CADS. 64-bit shared memory objects: o Must be explicitly shared/unshared i.e., the storage is not available to all address spaces (not even the one performing the allocation!) at allocation time. o Cannot be fixed. o Cannot be DREF. -- 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: Code pages (was: Square Brackets in Java?)
Patrick O'Keefe wrote: On Sat, 1 Dec 2007 11:07:06 -0600, Joel C. Ewing [EMAIL PROTECTED] wrote: .. I notice your table doesn't mention the ¬ encoding differences between IBM-1140 and IBM-1047, but perhaps that character wasn't relevant in the context of that discussion. ... Once again, the character seen in your post depends on the codepage used to display it. I see a logical not symbol, and assume that is the character you are refering to. I found lots of references to the IBM-1140 codepage on web but have not seen its contents, so my following comment may be way off base. I think the problem Steve was mentioning was when a character has different codepoint in different codepages. Does IBM-1140 havea not as something ther than x'5F'? Most of the codepages I've looked at (which admitted is not many) either have the not symbol as x'5F' or don't have it at all. Most codepages I've used lately have the caret for x'5F' and don't have a not symbol at all. I've taken to interpretting caret as not. The only places I've seen the not sysmbol used are PL/I and REXX (although I suspect there are many others, too). I haven't had easy access to PL/I since 1988 so I'm absolutely out of date. As far as REXX is concerned there are several alternatives to not - slash-equal and backslash-equal instead of not-equal. In fact, REGINA uses backslash-equal and caret-equal ... assuming I'm using the right codepage to look at the REGINA doc. :-) Pat O'Keefe ... I also have been unable so far to find any on-line reference that actually gives examples or names of established standard graphic representations for the various codepoints in the EBCDIC codesets. I've have been running of necessity under the assumption that there is some standard and that IBM's PComm emulator would conform to it, but that is probably a rash assumption. It's also quite possible (likely?) that whatever standard exists may have left some codepoints undefined, and that PComm could have implemented graphics for those codepoints that differ from other 3270 emulators. I have done some tests to determine the graphic symbols displayed in my own environment with IBM PComm Ver 5.6 sessions set to codesets IBM-037-US, IBM-1047-US, IBM-1140-US, and IBM 924-Multinational and have posted the results (as images to avoid issues with the displayer's text codeset) at http://home.earthlink.net/~jcewing/Codesets/ This shows that by PComm's implementation of the codesets that, among other differences, there is an interchange in the graphics for PL/1 Logical not and the Circumflex or caret at codepoints X'5F' and X'B0' between IBM-037-US and IBM-1047-US. It also shows that the differences between IBM-924-Multinational and IBM-1047 are much more extensive than just the Euro symbol, probably because there was no US-specific IBM-924 variant (at least not in PComm 5.6). These display images were created from a 3270 session at the TSO Ready prompt to avoid any issues with unexpected translations by ISPF, using a quick and dirty REXX exec that simply displays 16 text strings containing the hex character values from x'4x' through x'Fx' for x= 0,...,F. At some point I may try similar tests using ISPF panels, but the combinations of interest become much larger once you add the complexity of ISPF panel CCSID and ISPF terminal type translations to the picture. I believe REXX allows the slash alternative operators precisely because translation with codesets like IBM-037 or IBM-1140 can cause syntax problems and algorithm failure if the caret is used. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: Common Dataspace
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 12/08/2007 10:45:02 AM: First, since the SRB is a unit of work that is independent of any existing dispatchable unit in the Master, any normal error that occurs within it has no impact on any other work in the address space. If it abends, it doesn't take a TCB with it. (The SRB must still use appropriate recovery, though.) If the SRB schedules an IRB, the IRB abending can take an unsuspecting TCB down. Of course, the SRB could overlay storage in the Master and cause a systems crash, but anything running in Key 0, Supervisor State in ANY address space can cause enough damage to bring the system down. Running in the Master probably increases this by only a very small percent. Second, the blame really goes back to IBM's design of CADS. By their very nature, any CADS should have been made persistent and NOT tied to the life of the creating address space, i.e., it should have been maintained just like CSA/SQA and not automatically freed when the owner terminated. So the only place to create a CADS that must never go away is the Master. CADS were not part of the original data space design in SP3.1.0. They were a quick add-on in SP3.1.3, and as such, inherited the property that every data space is owned by some TCB in an address space. If you want to make sure that the CADS does not terminate, the address space must be non-CANCELable, non-FORCEable, and non-memtermable (so you must turn on ASCBNOMT). I agree that it would be preferable to allow a value of zero for the TTOKEN on DSPSERV CREATE and DELETE for SCOPE=COMMON data spaces (as always, feel free to write a requirement). In which case, internally, we have the CADS be owned by Master, associated with a TCB address of zero, so that no task termination could match and delete delete the CADS. Implemented this way, DSPSERVE CREATE could probably do this directly under the workunit of the DSPSERV CREATE, without needed to schedule an asynchronous workunit in Master. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Code pages
Joel C. Ewing wrote: [snip it all] Joel, Here's a few links I've found helpful: http://www-03.ibm.com/servers/eserver/iseries/software/globalization/codepages.html http://www.tachyonsoft.com/cpindex.htm http://www.alanwood.net/unicode/fonts.html http://www.alanwood.net/unicode/index.html http://www.utf8-chartable.de/unicode-utf8-table.pl Once we have a good way to enter Unicode data from a keyboard, we can all move to using only Unicode. I'm intrigued by the possibilities of this keyboard: http://www.artlebedev.com/everything/optimus/ http://community.livejournal.com/optimus_project/ Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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
REGION=0M and LSQA
I wish to ask the group on the pitfalls of coding REGION=0m. Is it true that if more storage is needed up to the region cap, VSM will allocate from LSQA? Thanks, Kenneth J. Kripke [EMAIL PROTECTED] -- 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: Common Dataspace
Keith E. Moe wrote: First, since the SRB is a unit of work that is independent of any existing dispatchable unit in the Master, any normal error that occurs within it has no impact on any other work in the address space. If it abends, it doesn't take a TCB with it. (The SRB must still use appropriate recovery, though.) One of the very nice aspects of SRB design is that, from a recovery point of view, SRBs can function as a logical extension of the scheduler's TCB or other so-called related task. Specifically, when PTCBADDR= is specified on IEAMSCHD, the system percolates errors back to the related TCB -- usually the one from which IEAMSCHD was issued. (You see this as SPRC records in the system trace.) If an SRB without an FRR routine abends, a LOGREC software error record is cut and the related TCB is abended. If that TCB has an ESTAE routine, it gets control. An SRB will want to establish its own FRR for recovery if it allocates resources that must be cleaned up if it abends, if time-of-failure SDUMP is desired for problem diagnosis, if it wants to inhibit LOGREC software error recording, etc. Otherwise, any errors can be dealt with by the related TCB's ESTAE routine ... or 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
Re: REGION=0M and LSQA
Never heard of that. Region cap is a up-limit for low private subpools and high private subpools not restriced by it. Of course, low private and high private cannot meet in the middle. On Dec 9, 2007 5:22 AM, Kenneth J. Kripke [EMAIL PROTECTED] wrote: I wish to ask the group on the pitfalls of coding REGION=0m. Is it true that if more storage is needed up to the region cap, VSM will allocate from LSQA? Thanks, Kenneth J. Kripke [EMAIL PROTECTED] -- 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 -- Best Regards, Johnny Luo -- 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
Contacted for an SMP/E person
I got an email from a head hunter looking for someone to do SMP/E based work for a large retailer located in Arkansas. Here is the crux of what they asked: Minimum 2 years experience with SMPE, System Software Installation Maintenance, MVS Utilities JCL Ok, I've already responded to them that I do SMP/E from the developer's side, but I could find them some serious applicants. Given that some have posted here that they are looking for work, I figured that notifying people via IBM Main would be a good idea. Contact me off list if you are interested. steve t at copper dot net (supply the right stuff and remove the spaces). Regards, Steve Thompson -- 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: REGION=0M and LSQA
As a general observation: In the Private area (as opposed to X-Private), your storage is obtained starting at the bottom of your space going toward the top. System control blocks needed for servicing your address space are obtained in LSQA (Local System Queue Area) which is at the top of your Private area. This is where TCB, xRB, IOB, etc. is allocated. Now, if you specify REGION=0M (or equivalent), you effectively tell the system DO NOT RESERVE LSQA area. So if you write a storage hungry application, and you are doing lots of GETMAIN/FREEMAIN operations AND you get more than you free over time (not necessarily because of storage creep, but just doing more and more work) and at the same time you are doing LOAD, RACROUTE and/or ATTACH (or other system calls that cause LSQA to be used), then you are more likely to have the system and you collide. This will result in various SOS (short on storage) type ABENDs. Now, if you are APF authorized and you can get to KEY0, what you can do is calculate how much below the line storage you need, and then you can modify the LDA to LIMIT your below the line storage so that you have reserved LSQA space. In this way, you can use the 0M limit to give you all the space (above and below) that is available to the catagory of address space you are running in (your upper limit in above storage may be set differently depending on what kind of access you have). I'm sure if I missed anything, other posters will correct it right quickly. Regards, Steve Thompson -- 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
ISVs and their sins: was Common Dataspace
On Sat, 2007-12-08 at 03:42 -0800, Gibney, Dave wrote: Where does the stuff CAS9 leaves around anchor? As a Natural/Adabas shop, we run their global buffer pool (which will (at this time) require me to allow common user key 8). How/where do I check on it's anchor point. G'day Dave. The only good thing about CAS9 is that is a major improvement on the old hooks. Plenty been said in the past about this little puppy - see the archives. Go run Robs MXI auth'd and meander around to see some of what CAS9 does. Never seen Adabas. Shane ... -- 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: ISVs and their sins: was Common Dataspace
Thanks Shane, MXI is on my list of to-do's. Unfortunately it's fairly well down on the priority list. :) And it seems that I now work at a place on the 3 to 5 year ERP and then no mainframe plan. :( -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shane Sent: Saturday, December 08, 2007 8:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: ISVs and their sins: was Common Dataspace On Sat, 2007-12-08 at 03:42 -0800, Gibney, Dave wrote: Where does the stuff CAS9 leaves around anchor? As a Natural/Adabas shop, we run their global buffer pool (which will (at this time) require me to allow common user key 8). How/where do I check on it's anchor point. G'day Dave. The only good thing about CAS9 is that is a major improvement on the old hooks. Plenty been said in the past about this little puppy - see the archives. Go run Robs MXI auth'd and meander around to see some of what CAS9 does. Never seen Adabas. Shane ... -- 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
