Idest limit
dear all As you may know, the SDSF IDEST parameters has been limited with only 4 destinations. I need help to initialize the user's panel with more than four destination, but not all destination? could any one do this! _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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: Fw: Binder API...broke or working as designed
Thanks for the responses. After reading the manual, and writing the code to use the API's, I have to say it is(at least for me) one of the more obtuse pieces of code and manual I have ever come in contact with. I've adjusted the code to handle the situation, and will move on. --Dave Day -- 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: SHARE in Denver
Hi, First SHARE didn't take humbridge at anything. In a nutshell it was too big and awkward and annoyed people who were trying to sit at the table. I had good intentions but it didn't work well. The IBM-MAIN table has not been a big draw for folks who actually knew what it was in a while. The IBM-MAIN folks mostly wind up sitting at SCIDS at the MVS table so that is a good place to look for folks with similar interests. Here are my notes from the IBM-MAIN slide I had in the Fully Wired presentation deck in Baltimore. IBM-MAIN Sign * Purchased in February 2001 by CBTTAPE.ORG * $221.97 * W 24 x H 60 * Too big! * Made several appearances at SHARE * Retired to Sam's coat closet * Being relocated to UA following SHARE My wife suggested I get rid of it or move it to the garage attic. I still really would love to get a picture of Ed, Darren or both with the sign. Guys and Gals who cares? For anyone lucky enough to have a job and to attend SHARE where you can learn new technologies, skills, network with peers, IBM, and other vendors just be delighted and get all you can from it. Try to put some value back into the community by sharing your experience with others too. Volunteer contributions and sharing of information are generally returned to you many fold. Do have some fun! Go to the big reception Monday, project dinners Tuesday, meet new people, pick up some chotchkies or mainframe T-Shirt to take back home. Learn a lot and have fun but don't obsess about any icons that may have come and gone. It's not the pins, paddles, IBM-MAIN sign and other project signs, handouts, ribbons, or other artifacts that make SHARE unique and valuable. It is the people! So if someone thinks an IBM-MAIN sign or totem would be a big draw and would help you meet other IBM-MAIN folks feel free to take a stab at it. Ed Finnell thanks for the IBM-MAIN stickers! They were fun! We gave them away at the MVS and/or IBM-MAIN table at SHARE for free whenever they showed up. I will be happy to snub any of you if I get the chance :-) Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Finnell Sent: Friday, August 21, 2009 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SHARE in Denver In a message dated 8/21/2009 12:17:32 P.M. Central Daylight Time, edja...@phoenixsoftware.com writes: it's not connected with SHARE in any way. (Not that anyone would complain if someone did set up an IBM-MAIN table Sunday or Thursday night. I certainly wouldn't.) I guess SHARE took humbridge at something. Sam Knutson packed up the IBM-Main sign and shipped it to Darren a few years back. I made ibm-main stickers for a while but they didn't sell very well. Nobody asked for any more. The intersection of the Venn diagram is the people with an interest in making things better by pooling our knowledge and experiences. This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Hourglass usermod question
Paul: BEWARE of usermods to *ANY* IBM product. Also be extremely careful of any front ends to any IBM modules/svcs etc. It gets real fun when the vendor is not current and you have to wait for them to come up with with ZAPS etc. I had exposure (and got rid of) at least 2 products that did that. The first question after reading the doc is IF any product does this then I automatically disqualify it from being looked at. If you need ammo just talk with a knowledgeable auditor and they will help you out. We had one that front ended an IBM module and all it took was one outage to convince management to get rid of it (rather quickly). It was purchased before I got there and I had to tangle with IBM level 2 a few times. Remember friends do not let friends do front ends or zaps or replacements of IBM modules.The *ONLY* one that I allowed was a UCC (now CA product) that (since) no one used NSL it was a pretty much who cares.Ed --- On Fri, 8/21/09, Paul Peplinski paul.peplin...@wpsic.com wrote: From: Paul Peplinski paul.peplin...@wpsic.com Subject: Hourglass usermod question To: IBM-MAIN@bama.ua.edu Date: Friday, August 21, 2009, 12:47 PM We have Hourglass (now an IBM product) that zaps DB2's DSNXGRDS and L/E's CEEPLPKA. The zaps for DB2 modify some - but not all - CSECTs in DSNXGRDS. I know less about the L/E module but I suspect it is the same. Does anyone have a sample that works for something like this? It seems every PTF I put on hits DSNXGRDS. Does / will IBM ever provide one? Paul -- 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: SHARE in Denver
On Sat, Aug 22, 2009 at 5:19 PM, Knutson, Sam sknut...@geico.com wrote: Hi, First SHARE didn't take humbridge at anything. In a nutshell it was too big and awkward and annoyed people who were trying to sit at the table. I had good intentions but it didn't work well. The IBM-MAIN table has not been a big draw for folks who actually knew what it was in a while. The IBM-MAIN folks mostly wind up sitting at SCIDS at the MVS table so that is a good place to look for folks with similar interests. Back when there WAS an IBM-MAIN table, I never saw anyone sitting at that table who even knew what IBM-MAIN was. None of the project signs seem to mean much at all once the place begins to fill up. All of the usual suspects (you know who you are!!) can be found milling around near the open bar until the food is served and then they can be found hanging out with the MVS project people or the JES project people or they just snag an open table and hope to be snubbed by everyone nearby. Go figure. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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
new mainframe software releases (C compiler mainly)
Jujitsu are pleased to announce the release of the following software: GCC 3.2.3 MVS 7.5 - GCC C compiler for z/OS, MVS/380, MVS/370. Delivered in xmit format. GCC 3.2.3 CMS 7.5 - GCC C compiler for z/VM, VM/380, VM/370. Delivered in vmarc format. PDPCLIB 2.00 - C (C90-compliant) runtime library for MVS (all flavours), CMS (all flavours), Windows 32, MSDOS, OS/2, Linux (new with this release), PDOS. Provided in source form only, but also delivered as part of GCCMVS and GCCCMS. Hercules/380 3.06 v6.0 - Used to run MVS/380. It now does S/380 even if you specify S/370, so that Hercgui will work. Now has native support for ftp-rdw files (ie files that have been transferred from z/OS using ftp with the RDW option), so that you can quickly get your files restored to a V dataset. Windows executables provided. Unix users need to compile from source. You can find the products at: http://gccmvs.sourceforge.net http://pdos.sourceforge.net http://mvs380.sourceforge.net (respectively). Initial documentation can be found in gccmvs.txt, pdpclib.txt and README.S380 respectively. Any comments/questions please post over at: http://tech.groups.yahoo.com/group/hercules-os380 where our complaint department is in operation 24 hours a day, even during Ramadan - may Allah have mercy on our souls. BFN. Paul. -- 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: ACP, One of the Oldest Open Source Apps
The following message is a courtesy copy of an article that has been posted to alt.folklore.computers,bit.listserv.ibm-main as well. John A Pershing Jr persh...@alum.mit.edu writes: At the time (I'm pretty sure this was with the 308x processor family) IBM offered special TPF machines for a premium price, or so I was told when I was working with TPF Development. As I recall, they sorted the critical chips and constructed the CEC with chips that could tolerate overclocking, and then overclocked them by 10 or 15%. They also did something to completely disable the DAT function, which would buy them an additional 5% or so even in DAT-off mode (note that TPF, at the time, ran everything in Supervisor state, DAT-off, key zero). The resultant processor was called a 9083 (I believe), and was sold to the major TPF customers who were red-lining their existing processors. Of course, it could only run TPF. I remember hearing that a certain major airline only used 1/3 of the cylinders on their DASD packs, in order to reduce seek times. Of course, TPF could mirror its files (which the big customers exploited) for performance and availability (they would balance reads over the two packs to increase throughput). In fact, essentially everything that TPF and its customers did was focused on performance, performance, and availability (in that order). They did some nifty hacks in their SNA network support, such that TPF could take a dive and restart without losing the network connections. If they did lose the network, TPF could restart it in a matter of minutes: again through the application of some very clever hacks. If nobody observed it, then it never happened. re: http://www.garlic.com/~lynn/2009l.html#13 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#15 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#17 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#43 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#44 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#45 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#46 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#47 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#55 IBM halves mainframe Linux engine prices http://www.garlic.com/~lynn/2009l.html#58 ACP, One of the Oldest Open Source Apps for 370 two processor cache machines ... they slowed the processor cycle time by ten percent to account for cross-cache signaling ... i.e. each processor ran at .9 of a uniprocessor machine ... or two processor base hardware was 1.8 times that of a uniprocessor machine (actual invalidates and other cache overhead ... plus increased multiprocessor software pathlength might slow system thruput down to 1.5 times or less than that of uniprocessor). I had done some multiprocessor supervisor slight of hand that got very close to the 1.8 times (nearly straight hardware speed). Also for some of the multiprocessors at HONE ... I was able to get better than two times a uniprocessor operation because of some further slight of hand regarding cache hit ratios (i.e. uniprocessor operation with lots of interrupts would loose cache locality and have increased cache miss rate ... with two processors ... i could play some more games with preserving cache locality execution ... with much higher cache hit rate ... so effectively the MIP thruput rate was better than normally rated for the machines because of improvement in cache hit rate). 3081 being a standard two processor machine (and initially there wasn't going to be any uniprocessors) already had both processors speed slowed by ten percent (to handle the cross-cache signaling). TPF didn't have multiprocessor support at the time ... so eventually they had to come out with a crippled 3081 only running a single processor and because there wasn't cross-cache signaling going on ... they could bump the processor cycle time up (sort of the reverse of 370 with single processor being normal and two-processor being slowed down ... 3081 had two processor being normal ... and so single processor was speed up) ... for 3083. There were also various comments that work on 3083 uniprocessor for TPF was because of various clone single processor products (not aggregate as fast as two processors in 3081 but more than any of the older single processor machines offfered by IBM). from: http://www.isham-research.co.uk/mips_chart.html 3081k was 14.6 aggregate mips or about 7.3mips/processor ... turning off x-cache signaling should up that to about 8.11mips/processor 3081kx2 was 15.4 aggregate mip rate or about 7.7mips/processor ... turning off x-cache signaling should up that to about 8.6mips/processor 3083jx comes in only at 8.12mips (vanilla 3081k processor with x-cache signaling turned off). some old email indicates that even 9083 hand-picked only came in marginally
Fw: Fw: Binder API...broke or working as designed
Chris Craddock crashlu...@gmail.com wrote in message news:b0c6f15b0908212236g510fd9cbq661ae41f9627e...@mail.gmail.com... On Fri, Aug 21, 2009 at 11:29 PM, Bill Klein wmkl...@ix.netcom.com wrote: snip Bill K... this is a can of worms best left unopened. Suffice to say Bill Blair's commentary is not actually a rant at all, but is based entirely on his own (and my own) direct personal experience with said component. He does not need any help composing a SHARE requirement and in any case, as he indicated obliquely the chances of such a requirement being delivered within the expected lifetime of the universe is pretty slim. I have promised my friends in IBM that I won't keep picking on the binder in public every time the subject comes up, so I will just bite my tongue. You might want to as well. I am sorry that your experience has been so bad. However, I will keep harping on the fact that IBM has indicated that they will process binder requirements in the ASM project of SHARE. As I say, I certainly can't guarantee what will be accepted and when such will be implemented, but I *do* repeat that unless/until the SHARE requirement process is tried for such things, it seems wrong to me to assume that it will NEVER work. -- 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: ACP, One of the Oldest Open Source Apps
John A Pershing Jr persh...@alum.mit.edu writes: At the time (I'm pretty sure this was with the 308x processor family) IBM offered special TPF machines for a premium price, or so I was told when I was working with TPF Development. As I recall, they sorted the critical chips and constructed the CEC with chips that could tolerate overclocking, and then overclocked them by 10 or 15%. They also did something to completely disable the DAT function, which would buy them an additional 5% or so even in DAT-off mode (note that TPF, at the time, ran everything in Supervisor state, DAT-off, key zero). The resultant processor was called a 9083 (I believe), and was sold to the major TPF customers who were red-lining their existing processors. Of course, it could only run TPF. I remember hearing that a certain major airline only used 1/3 of the cylinders on their DASD packs, in order to reduce seek times. Of course, TPF could mirror its files (which the big customers exploited) for performance and availability (they would balance reads over the two packs to increase throughput). In fact, essentially everything that TPF and its customers did was focused on performance, performance, and availability (in that order). They did some nifty hacks in their SNA network support, such that TPF could take a dive and restart without losing the network connections. If they did lose the network, TPF could restart it in a matter of minutes: again through the application of some very clever hacks. If nobody observed it, then it never happened. re: http://www.garlic.com/~lynn/2009l.html#58 ACP, One of the Oldest Open Source App http://www.garlic.com/~lynn/2009l.html#65 ACP, One of the Oldest Open Source App In the move to 3380 ... the total mbytes of data per arm increased by much larger ratio than the ratio for accesses/sec increase (resulting in accesses/sec per mbyte decrease and potentially system thruput decrease). There was a session at SHARE discussing problems with getting datacenter managers to not completely fill every byte of disk space (or at least fill-out with relatively dormant data). There was a semi-facetious suggestion that a special microcode load for 3880 controllers that would significantly cut the number of accessable 3380 cylinders ... and market it as a high performance 3380 at a higher price (getting datacenter managers to pay more for a reduced-sized, high performance 3380 ... was viewed as a much simpler task than trying to get datacenter managers to only partially fill a 3380). for some other ACP discussion ... old email by Jim looking at typical ACP airline res system activity profile http://www.garlic.com/~lynn/2008i.html#email800325 in this post http://www.garlic.com/~lynn/2008i.html#39 and followup post mentioning tribute to jim last year http://www.garlic.com/~lynn/2008i.html#40 referencing some old email http://www.garlic.com/~lynn/2007.html#email801006 http://www.garlic.com/~lynn/2007.html#email801016 about Jim when he was leaving for Tandem, trying to palm off on me database consulting with IMS group ... and consulting with various (financial institution) customers looking at doing relational dbms Now, part of the name change from ACP to TPF was some number of financial institutions starting to use ACP for financial transactions ... including ATM machine transactions. There was a large california financial institution in the late 70s that implemented a customized ATM machine transaction processingon VM370 ... and claimed that its VM370 implementation running on 370/158 ... had higher thruput than ACP doing the some workload on 370/168. The issue wasn't so much processor consumption ... it was better intelligent scheduling of disk arms. They had a gimick with transactions coming into a service virtual machine and then being offloading to transaction server virtual machines ... where each server virtual machine owned a whole disk and the associated disk arm. They had done extensive study of ATM transaction patterns ... and tailored disk arm scheduling to transaction history patterns (something that was much more difficult to do in ACP environment ... including delaying some transactions in an attempt to improve disk arm locality of reference). post from last year with some discussion of the implementation: http://www.garlic.com/~lynn/2008g.html#14 as mentioned, at some time in the past, my wife had been con'ed into going to POK to be in charge of loosely-coupled (aka mainframe cluster) architecture ... while there she did the peer-coupled shared data architecture http://www.garlic.com/~lynn/submain.html#shareddata which except for IMS hot-standby ... saw very little uptake until sysplex ... which contributed to her not staying long POK. the other problem was battles with the SNA crowd over whether or not SNA had to be used for loosely-coupled/cluster operation ... eventually there was a (temporary) truce where she didn't have to use SNA within the walls of the
