Re: Group Capacity Limit
Fine Bob, GCL is a feature provided by IBM. I am trying to found out what its implications are, as the detail available out there is a bit sketchy. I would have loved some feedback from the IBMers as to all the potential benefits. Is this not what this group is about? Errol, Pardon me for jumping in here, but I suggest you engage Al in a consulting gig. He was kind enough to answer your original question, but the information you are requesting here he makes his living providing. Just my $.02. I'm sure Al will correct me if I am wrong. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
>I think you missed the forest for the trees. Do you have to editorialise, when somebody asks a question? I did say I didn't know. >Even if the blocksize were 23000 or larger, the blocks would still be 800 >because each member is one block, and each block is ten records of 80 bytes. >A larger blocksize would be useful only if users had more than one member >(already ruled out in previous messages). Thank you for the answer, at least. I did say I hadn't used it since the 1980's, so I didn't know. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
Ted MacNEIL wrote: I think you missed the forest for the trees. Do you have to editorialise, when somebody asks a question? I did say I didn't know. I apologize. My original text had a smiley graphic, but that seems to have disappeared. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
>>> I think you missed the forest for the trees. >> >> Do you have to editorialise, when somebody asks a question? >> I did say I didn't know. >I apologize. My original text had a smiley graphic, but that seems to have >disappeared. No problem. My understanding of UADS is over 20 years out of date. And, I admit I didn't understand all the nuances, back then. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Eliminate IKJ56862I
I've written a new "Dynamic Allocation Input Validation" exit (IEFDB401). In this exit I issue my own message when the allocation request is to be failed. Does anyone know if it's possible to eliminate the "IKJ56862I DYNAMIC ALLOCATION REQUEST NOT PERFORMED, REQUEST DENIED BY INSTALLATION EXIT" message? Thanks for any advice. Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
On Sat, 31 Jan 2009 02:39:34 -0500, Gerhard Postpischil wrote: >Paul Gilmartin wrote: >> And all the discussion of 800-byte blocks seems to miss the mark. >> Shouldn't we be concerned, rather, with multiples of 172? > > From existing data, we know that the usual space needed is more >than 720 bytes, and no more than 800. The same data with >LRECL=172 would occupy 860 byte blocks, taking more DASD space >and more processing time and storage. > Mystifying. The manual cited avers: 4.2.2.1 Allocating a new UADS ... Figure 25 shows an example of using a batch job to allocate the new UADS. A logical record length (LRECL) of 172 is suggested but not required. Are you saying that the "suggested" logical record is BS, and should be ignored? And the manual gives no help with the allowable limits on LRECL. You favor LRECL=80, but would LRECL= be a workable alternative? Would LRECL=1 work? The manual doesn't prohibit it. What's the motivation for 172, anywway? --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
I think these arguments are all pretty meaningless. I suspect that these days most UADS have one member in them (IBMUSER0), and RACF/ACF2/whatever is where the real data is. So it really doesn't matter what the lrecl/blksize is. Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
On Sat, 31 Jan 2009 16:02:08 -0600, Richard Peurifoy wrote: >I think these arguments are all pretty meaningless. >I suspect that these days most UADS have one member >in them (IBMUSER0), and RACF/ACF2/whatever is where >the real data is. So it really doesn't matter what >the lrecl/blksize is. > "really doesn't matter" ... Are you saying, in other words, that LRECL=1,BLKSIZE=5 would work just fine? The manual suggests, but doesn't require that LRECL=172, and the only requirement it places on BLKSIZE is that it be a multiple of LRECL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYS1.UADS Format
--- On Sat, 1/31/09, Ted MacNEIL wrote: > From: Ted MacNEIL > Subject: Re: SYS1.UADS Format > To: IBM-MAIN@bama.ua.edu > Date: Saturday, January 31, 2009, 9:41 AM > >>> I think you missed the > forest for the trees. > >> > >> Do you have to editorialise, when somebody asks a > question? > >> I did say I didn't know. > > >I apologize. My original text had a smiley graphic, but > that seems to have disappeared. > > No problem. > My understanding of UADS is over 20 years out of date. > And, I admit I didn't understand all the nuances, back > then. Ted: LONG TIME AGO and far far away I had to dissect UADS. It was reasonably well thought out (for the time). My memory is vague but IIRC a single user could have multiple members ie IBMUSER0 (must) IBMUSER1 (maybe) etc etc.. The "reason" it was possible to have one user having multiple passwords and account numbers (and a few other items but I do not remember for sure) That way if the blocksize of uads was "small" and you needed addition passwords (with an different proc) the "overflow when it exceeded what ever number it was the system would automatically look for the next pds member with a 1 or 2 or whatever. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort vs competitors
--- On Fri, 1/30/09, Mark Zelden wrote: Date: Friday, January 30, 2009, 2:29 PM > On Fri, 30 Jan 2009 12:18:25 -0600, > Lupher, Fred > wrote: > > >We are a long time Syncsort customer. Our > contract with them will be up > for renewal soon, so this is a good time to consider the > competitors. Does > anyone have experience migrating away from Syncsort you'd > care to share? Or > if you looked into switching but decided not to, I'd be > interested in > knowing what stopped you? > > I have done a couple of conversions but that was more than 10 years ago so anything I write could be out of date so take it for what its worth. During various conversions we ran into some interesting (yet small IMO) differences. Syncsort sorts a little differently than DFSORT in some cases. This showed up with any records with equal keys. IIRC syncsort sorted them FIFO and DFSORT sorted them equally. We resolved this issue with the EQUALS install option. The other thing that stopped most people from converting (one way or the other way) was that SYNCSORT's language was slightly different than DFSORT. The "language" I am talking about is the reporting language (forgot the name it been so long). One of the issues in this was that SYNCSORT would come up with something and it would take DFSORT a few months to do the same it was a leap frog type environment so a programmer could do something in SYNCSORT and it may or may not be available in DFSORT. At one installation we discouraged the use of the language so it was pretty trivial conversion. At one time DFSORT was cheaper but SYNCSORT used less resources. Once they became equal as far as resources we went DFSORT. This is a personal observation and no grounds to prove it. Both support teams were good but the issue with SYNCSORT (again this was 10+ years ago) was that they sent zaps out and you had to key in the zaps by hand. This was prone to errors and IIRC they used checksum (superzap ) to verify the zaps were coded correctly. The side issue was that at times a module had so many zaps on it that you had to relink the module by hand to accommodate the zap (extra IDRDATA). IBM sent out module replacements that made SMPE work easy to do. It was a little bit easier to figure out what was on (maintenance wise) with DFSORT. Again this is old information. Both products work well and at least (again 10+ years ago) performance wise DFSORT narrowly beat SYNCSORT . I am trying to think back if we ever had to call the syncsort people in the middle of the night and I cannot remember doing so (if we did the support must have been OK or else I would have moved to get us off SYNCSORT sooner. A long time ago SYNCSORT was really fast and efficient and it would beat the pants off of DFSORT but the DFSORT people equalled and maybe a little bit surpassed SYNCSORT. One thing that I really liked about SYNCSORT is that you could override any sort parameters with a $ortparm dd statement. I used that quite often debugging sorts invoked by cobol. I do not remember off the top of my head if DFSORT ever came up with a similar option, memory says maybe but check the books to make sure. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Changing LPAR Weights
I tried to get this manual Zseries API, but I could not find it. What the manual number. Thanks, Mohamed Juma --- On Thu, 1/29/09, Edward Jaffe wrote: From: Edward Jaffe Subject: Re: Changing LPAR Weights To: IBM-MAIN@bama.ua.edu Date: Thursday, January 29, 2009, 1:14 PM gsg wrote: > Edward, > > Do we have to be running our HMC on Unix? We have not converted our HMC to unix. Yet. > No. The zSeries API has been around for many years--long before the Linux-based HMC/SE. We first started using it on our z800 with an OS/2-based HMC/SE. I suggest you download and read the zSeries API manual from IBM's site. That book should answer any further questions you might have. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Changing LPAR Weights
Mohamed Juma wrote: I tried to get this manual Zseries API, but I could not find it. What the manual number. http://www.ibm.com/support/docview.wss?uid=isg27c10b677aa79464885256ced004fb19a -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Syncsort vs competitors
We have just over 700 clients and the current split on their configurations seems to be that about 70% of them are using DFSORT. Which doesn't mean anything to the "real" split in all sites, just the subset that we have worked at, but I though might be interesting to toss out there. In the few clients that I have spoken to in the past about their choice, "difference" in cost never seems to come up as a "big deal" and it appears that if you are running SYNCSORT, that IBM will "make you a deal" and vice-versa. We have handled the conversions both ways, and I can assure it it's fairly painless. The really funny thing (to me at least) is that most times their choices are based on what we would probably consider to be "silly" if it weren't that they were paying us to take care of something on their site. Silly is probably a bad way to put it, but choosing your sort product on a free poster/calendar/pen/ashtray or how "hot" your marketing rep looks is really not a valid basis. Well, maybe it is, I suppose it depends on the relative "hot-ness" compared to the ability to perform a sort really-really fast. :) There are some "philosophy" differences in how the products are implemented and used, but I honestly can't say that one is "noticeably faster" or that much "better" than the other for all types of tests. There are features that each do better/faster, and of course that's what they push marketing wise, but I'm sure that since you are currently running SYNCSORT, that if you get your IBM' marketing rep's "BEST PRICE" that your current vendor will meet or beat it. Both products have paid for their development and support costs many times over, so they have nothing to loose in lowering their price, except maybe upsetting other customers and getting you as a client and away from the "other guy" :). You probably have better things to do than change sort products, which again I have to stress is not difficult, so unless IBM can give you a price that Syncsort just refuses to meet (or beat), then you should just get the new price and not worry about which one is "slightly" better because no matter which one you choose, there will be something that the other one can do better/faster. They are both very good products, you can't loose either way except on price. On the other hand, I hear that Syncsort is giving away free tee-shirts again. :) Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
