Re: IBM - MLC question
Thanks for the replies to my question. -- 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: Xephon, are they still in business?
I knew some VM'ers that belonged to something called CAVEMEN, is that still active ? On Tue, Apr 15, 2008 at 8:59 PM, Thomas Kern <[EMAIL PROTECTED]> wrote: > You mean a 'new' technology like this reference? > > VMSHARE has been the conferencing system of the VM Cluster of SHARE since > August 1976. After VMSHARE was closed down in August 1998 it was decided > that the database should be kept available for reference. Read here the > announcement of that by Ross Patterson. > The best way to get a feeling for what VMSHARE meant to its users is > probably by browsing through the VMSHARE Archives where you will find > appends like this. > It may also be helpful to read Melinda Varian's History of VM to get a > better understanding of the community that has developed around VM and > VMSHARE. > > http://vm.marist.edu/~vmshare/ > > Daney, C., The VMSHARE Computer Conferencing Facility. In Computer Message > Systems, ed. by Ronald P. Uhlig, North-Holland, Amsterdam, 1982, 115-127. > > /Tom Kern > > > > On Tue, 15 Apr 2008 13:11:47 -0500, Ian <[EMAIL PROTECTED]> wrote: > >Xephon did a great job in providing this service through the years. > >But in this day and age I don't see the need for an expensive service > like > >this. > > > >If you look at the open source communities you will see lots of code and > >ideas freely exchanged between users. > >Apart from the several listservers the mainframe community is the only > one > >that lacks this kind of open exchange of ideas and code. > >The listservers also provided a great servers during the years but it > lacks > >a structured way in categorizing and storing valuable information. > > > >I think its time for us(old mainframers) to jump on the "new " age > >technologies like blogging, forums and wiki's to preserve our knowledge > and > >pass it on to the next mainframe generation. > > > >-- > >Ian > >http://www.cicsworld.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 > > -- Glen J. Gasior (312) 751-4377 [EMAIL PROTECTED] U.S. Railroad Retirement Board Chicago, Illinois 60611 "The contents of this message are mine personally and do not reflect any position of the Government or my agency." -- 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: "action" in UK33496
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Skip Robinson > > Dang, Patrick, how did I miss the connection? Once upon a > time, JES2 undertook to manage a newfangled print gismo the > same way they always had: > start, stop, ship data, handle glitches, the whole enchilada. > This newly bred puppy, the 3800, proved to be famously ill > mannered. It not only laid waste to the surrounding > landscape, it got its master in serious trouble with the > whole neighborhood. At a time when 'FSS' was still just a > euphemism for something vulgar, JES2 was desperate to impose > some order on the 3800 chaos. > > For one particularly troublesome set of circumstances, a > short term maneuver was proposed: 'throw up our programmatic > hands and start over'. > The problem was how to 'start over' in the middle of some > very complex code? Someone noticed that there was already a > robust error handling routine that got control in case of > JES2 main task abend. This routine cleaned up the 3800 tangle > and returned to a known and workable restart point. Trouble > was, the error condition that required 'recovery' was often > no more than a printer return code that JES2 didn't know what > to do with. > So the ingenious solution was to branch deliberately to a > specific literal string containing a conspicuous 'error > message'. The resulting S0C1 would be recognized as an > intentional punt (US football term), normal recovery would be > invoked, and life would go on. > > Unfortunately, somewhere between conception, testing, and > actual release--come on, did nobody see this before PTF > GA?--the intended literal got (re)rendered as an EBCDIC > string whose hex beginning fatally resembled a decimal OP > code. So instead of S0C1, JES2 took a S0C7, which the > recovery routine was not expecting. JES2 died on the spot, > and sysprogs all over the world scratched their heads in disbelief. > > Now that really was funny. Who'da thunk to _start_ a string with a null character? :-) -jc- -- 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: 3277 terminals and emulators
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Shane > > On Fri, 2008-04-18 at 19:16 -0500, Michael Ross wrote: > > > Folks, > > > > I'm in the process of powering-up my System/3: > > Sorry Mike, can't help. > However I showed your web page page to my other half, who's > always complaining about the amount of "junk" I have around the place. > My comment: "See, I ain't that bad" > Her comment: "*THAT* is divorce material". > > I think she was trying to suggest I don't even think about > heading down the same path... :0) How about a 3174-61R? Got one in the garage. -jc- -- 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: 3277 terminals and emulators
Mike, Sorry, can't help with 3340 info, but I am pretty sure that if you plugged in a 3277 model 2 ( much more common) It would electrically work ok. The fields displayed might be in the wrong place, but I think the S/3 should not know the difference. One point though... Is the S/3 actually co-ax, or is it twin-ax like the s/34, s/38 /as/400 family that it spawned? My two bob's worth, Phil Steele -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Michael Ross Sent: Saturday, 19 April 2008 10:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 3277 terminals and emulators Folks, I'm in the process of powering-up my System/3: http://www.corestore.org/3.htm One vital component I don't have is a console terminal. The System/3 uses a 3277 console - specifically, a 3277 Model 1 (yes, the 12 lines x 40 characters one!). So: 1. Does anyone reading this list have one, or have any leads on where one might be found? 2. Failing that, I'm looking for any 3rd party compatible terminals, or device combinations that could add up to 3277-1 compatibility. So far, the only leads I have are that the 3270 card in the XT/370 desktop mainframe machine did 3277 emulation - but I don't know if it supported Model 1 mode. Ditto for the 'Appleline' external 3270 box for early Mac & Lisa machines; again I've heard that supported 3277, but don't know about Model 1 specifically. What about the machine that was marketed as the XT/3270 - did that support 3277 Mod. 1, for instance? Any clues, leads, or suggestions would be most welcome! And, while I'm looking for desperately rare things, I'm also going to need 3340 disk drives at some point... anyone know where those might be found? Who made 100% plug-compatible 3340 clones? Thanks! Mike -- 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 *** PLEASE NOTE: This internet email message has been checked for viruses and appropriate content to ensure it complies with TABCORP's electronic communication policy. *** *** The information in this e-mail message and any files transmitted with it are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The confidentiality of and privilege applying to this message and files is not waived if this message or files has been sent to you by mistake. If the reader of this message or files is not the intended recipient, you are notified that retention, distribution or copying of this message and files are strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this message and files for viruses. Thank you. *** -- 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: "action" in UK33496
Dang, Patrick, how did I miss the connection? Once upon a time, JES2 undertook to manage a newfangled print gismo the same way they always had: start, stop, ship data, handle glitches, the whole enchilada. This newly bred puppy, the 3800, proved to be famously ill mannered. It not only laid waste to the surrounding landscape, it got its master in serious trouble with the whole neighborhood. At a time when 'FSS' was still just a euphemism for something vulgar, JES2 was desperate to impose some order on the 3800 chaos. For one particularly troublesome set of circumstances, a short term maneuver was proposed: 'throw up our programmatic hands and start over'. The problem was how to 'start over' in the middle of some very complex code? Someone noticed that there was already a robust error handling routine that got control in case of JES2 main task abend. This routine cleaned up the 3800 tangle and returned to a known and workable restart point. Trouble was, the error condition that required 'recovery' was often no more than a printer return code that JES2 didn't know what to do with. So the ingenious solution was to branch deliberately to a specific literal string containing a conspicuous 'error message'. The resulting S0C1 would be recognized as an intentional punt (US football term), normal recovery would be invoked, and life would go on. Unfortunately, somewhere between conception, testing, and actual release--come on, did nobody see this before PTF GA?--the intended literal got (re)rendered as an EBCDIC string whose hex beginning fatally resembled a decimal OP code. So instead of S0C1, JES2 took a S0C7, which the recovery routine was not expecting. JES2 died on the spot, and sysprogs all over the world scratched their heads in disbelief. Now that really was funny. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Patrick O'Keefe <[EMAIL PROTECTED] AMU.NET> To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> Re: "action" in UK33496 04/20/2008 08:06 PM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson <[EMAIL PROTECTED]> wrote: >... >There was a note of caution that I found almost funny: the new OP code >would not cause a problem for any program *unless* that program were >depending on the OP code *not* to be valid. Where's my S0C1? I need my >S0C1! After all these years in the business, I would not bet the farm on >there being no such program. >... I remember seeing such a program sometime within the last 15 years. I don't remember what "character string" used to create the S0C1, but I remember thinking that some day it would be a valid opcode and there was going to be some very unanticipated behavior in that program. Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) Pat O'Keefe -- 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
My Crystal Ball is Broken (Was: "action" in UK33496)
Skip Robinson wrote: I once had to explain to the author of a very silly CLIST why it suddenly failed to enter an expected (!) ERROR routine because underscore was no longer invalid in labels. I didn't feel very guilty about that one. What a dope. I remember reading about a new OP code being introduced on a processor. There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. Lots of people get "burned" by the introduction of new opcodes, syntax, or compiler diagnostics. The most famous example was the MSG instruction. It conflicted with many home-grown "message" macros with the same name. No program can be guaranteed to compile or work forever. The "owner" of any such a program must always be prepared to adapt... -- 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: "action" in UK33496
On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson <[EMAIL PROTECTED]> wrote: >... >There was a note of caution that I found almost funny: the new OP code >would not cause a problem for any program *unless* that program were >depending on the OP code *not* to be valid. Where's my S0C1? I need my >S0C1! After all these years in the business, I would not bet the farm on >there being no such program. >... I remember seeing such a program sometime within the last 15 years. I don't remember what "character string" used to create the S0C1, but I remember thinking that some day it would be a valid opcode and there was going to be some very unanticipated behavior in that program. Sheesh! Everybody knows you're supposed to EX and EX in such circumstances, not execute some clever word. You need a more intuitive, self-explanatory abend like S0C3 to aid your debugging. :-) Pat O'Keefe -- 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: "action" in UK33496
I remember back when a very fundamental utility changed to SDB by default. I believe it was IEBGENER itself. If we had HOLDDATA back then, I'm not sure how big a deal we made of it. In any case, one major application had an 'outage' because a particular job step had been counting on the historic default where output blocksize was equal to input blocksize. Their master file was required to be a certain blocksize. For years the offending utility step copied the file without specifying blocksize. Suddenly with SDB the output changed, and subsequent steps failed. I once had to explain to the author of a very silly CLIST why it suddenly failed to enter an expected (!) ERROR routine because underscore was no longer invalid in labels. I didn't feel very guilty about that one. What a dope. I remember reading about a new OP code being introduced on a processor. There was a note of caution that I found almost funny: the new OP code would not cause a problem for any program *unless* that program were depending on the OP code *not* to be valid. Where's my S0C1? I need my S0C1! After all these years in the business, I would not bet the farm on there being no such program. The HOLDDATA cited by Radoslaw falls short of sounding the proper alarm, but it's not misguided. Muted and vague, but not wrong. The most innocent of changes we implement can wreak havoc on applications we would not otherwise have met in a dark alley. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] "R.S." <[EMAIL PROTECTED] LTIBANK.COM.PL>To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> "action" in UK33496 04/19/2008 12:12 PM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> HOLD(UK33496) SYS FMID(HCI6500) REASON(ACTION) DATE(08037) COMMENT (If the SYSPRINT file is being written to a data set, please note that a System Defined Blocksize will be allocated if no BLKSIZE is defined or a BLKSIZE of 0 is defined on the DD card. My humble questions: 1. Is it really ACTION to perform ? 2. Isn't the behaviour obvious and expected ? If yes, then why to mention it under any HOLD type ? 3. Is it funny ? I also found ACTION which was ...documentation change (in other PTF). -- Radoslaw Skorupka -- 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: how to audit the usage of IND$FILE
Thanks all your information and sharing. Actually, there are so many ways to transfer files from HOST system but we still have to cope with the internal/external auditor each year. We can't say "nothing we can do". Nothing is prefect, but taking notes/remember the coding and picture some photo we can stop it. We can just try our best to protect the shop resources. To be a system programmer, we have responsibility to deal with it. Frankly, we have many communication path, AFTP (protect by program) , FTP (we are not open yet), Ind$file (I create a dummy program on top of it), HDS (rapidxchange disk/share open & host, can trace on SMF log volume). * I think we have to stop the way that they can get the files more easily and we are not aware, such as ind$file path. How many pictures you have to take or remember if there are thousand of program coding? regards On 4/21/08, Patrick O'Keefe <[EMAIL PROTECTED]> wrote: > > On Sun, 20 Apr 2008 10:29:28 -0500, Kenneth E Tomiak > <[EMAIL PROTECTED]> wrote: > > >After awhile I start to spot a trend from some people posting here that > they > >are not trying to learn how to do something, they have figured out how to > get > >IBM-MAIN to do their job for them. > >... > > Let me present another interpretation of some of those trends (but > not, I think, applicable to the original poster of this thread). > > I'm not knew to system programming - I chased my first CDE chain > in about 1970 (on MVT) - but I've been involved in communication- > related software for so long that nobody would mistake me for an > experienced MVS system programmer any more. I'm woefully out > of date regarding anything but very basic MVS concepts. So I > sometimes ask really bonehead questions. And if you search the > archives you may find that I've asked the same bonehead questions > years earlier. > > Does that mean I'm lazy and am trying to get IBM-Main to do my > work? I hope not. It might mean I didn't incorporate the answers > into my working knowledge because the topic was too peripheral to > my usual work. Or it might be an indication of a failing memory. (And > it definitely means I'm to lazy or forgetful to have searched the > archives.) > > > >So if someone asks how to audit a program 'A' and then later asks how to > >audit program 'B', did they learn anything the first time? ... > > If this happens too many times (and twice is too many) my paranoia > kicks in. Many of the responses to "How do I audit IND$FILE?" have > been "That isn't sufficient because ...". I can just picture someone > taking notes: "I can avoid the auditing if ...". > > Far fetched? Sure. I said it was my paranoia. But it's something to > consider when answering questions like that. > > Pat O'Keefe > > -- > 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: TIOT filling up: too many dynamic concatenations
David: I am just now digging through 2000+ IBM-MAIN messages, so this is a bit old by now. It has been a very long time since I was digging through dynamic allocation and concatenations as part of a JES2 user mod. What I remember was that my code had a loop where I read a dataset name, allocated it to a system assigned DDNAME, and then added it to the current concatenation. The problem was that the TIOT filled up very quickly because it was full of holes of ever increasing size. What was happening was the new concatenation was larger than any of the available holes in the TIOT, so it got placed at the end of the used space, and the TIOT ended up full of free space blocks of size 2x, 3x, 4x, 5x, etc, followed by the real proclib allocation space. It seemed that IBM was not going back and consolidating the free space blocks caused by the earlier concatenations. Assuming that this is still the case, one thing that you could try doing would be to allocate all of the datasets and then do a single massive concatenation, rather than doing all of the intermediate ones. I hope this helps. -jack - Original Message - From: "David Eisenberg" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Wednesday, April 09, 2008 2:35 PM Subject: Re: TIOT filling up: too many dynamic concatenations Ed, Field S99ERROR (after the dynamic concatenation request to DYNALLOC) is coming back with a value of X'0238': "Space unavailable in task input output table (TIOT)." The manual says that the application should "Reduce the total number of allocated DDs and devices. Deallocate data sets that are not needed simultaneously." The only way I've found to reduce the total number of allocated DDs is to reduce the number of files in the folder. I can't deallocate any of the component allocations once they've been concatenated. I did use IDF to step through and watch the TIOT grow. With each new concatenation call, there is an entry which keeps growing in size until the TIOT fills up. I think that what I need to know is if I'm missing some approach/technique that can get around what is probably a legitimate limitation. David -- 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: "action" in UK33496
On Sun, 20 Apr 2008 09:51:55 -0500, Kenneth E Tomiak wrote: >Programs can write to SYSPRINT as long as the blksize is compatible with >LRECL so if an installation previoulsy hardcoded a valid blksize instead of >using >a system determined blksize then no action is required. > >This is one of those annoying actions we spend too much time researching >only to learn we can ignore it. > >It is a shame when one IBMer could not put sufficient information in the HOLD >data causing thousands of us to go hunt down the APAR. > Several years ago, I was hit by something similar. In Rexx, I had done: RC = BPXWDYN( 'allocate dd(SYSPRINT) recfm(V,B) lrecl(137) path(...)...' ) ... omitting BLKSIZE. I always assume the OS knows best. In fact, it was not the OS, but a subsequent EXECIO that set a usable BLKSIZE. But a customer rightly reported that EXECIO was thwarting the proper operation of SDB (as in PK59467/UK33496), so IBM removed the setting of BLKSIZE from EXECIO. So, what did SDB select for a subsystem data set with recfm(V,B) lrecl(137)? 80! IBM recommended that I specify BLKSIZE at allocation; an ironic consequence of SDB. SDB has been fixed by APAR (although) IBM support cautioned me that the value of 80 was documented, and if another customer complained they'd be required to break it again. It's regrettable that a rudimentary SDB was not present in OS/360 from the beginning. It's a good enhancement, and customers should adopt the habit of relying on it, or reporting its unreliability. The OS knows best. -- gil -- 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: how to audit the usage of IND$FILE
On Sun, 20 Apr 2008 10:29:28 -0500, Kenneth E Tomiak <[EMAIL PROTECTED]> wrote: >After awhile I start to spot a trend from some people posting here that they >are not trying to learn how to do something, they have figured out how to get >IBM-MAIN to do their job for them. >... Let me present another interpretation of some of those trends (but not, I think, applicable to the original poster of this thread). I'm not knew to system programming - I chased my first CDE chain in about 1970 (on MVT) - but I've been involved in communication- related software for so long that nobody would mistake me for an experienced MVS system programmer any more. I'm woefully out of date regarding anything but very basic MVS concepts. So I sometimes ask really bonehead questions. And if you search the archives you may find that I've asked the same bonehead questions years earlier. Does that mean I'm lazy and am trying to get IBM-Main to do my work? I hope not. It might mean I didn't incorporate the answers into my working knowledge because the topic was too peripheral to my usual work. Or it might be an indication of a failing memory. (And it definitely means I'm to lazy or forgetful to have searched the archives.) >So if someone asks how to audit a program 'A' and then later asks how to >audit program 'B', did they learn anything the first time? ... If this happens too many times (and twice is too many) my paranoia kicks in. Many of the responses to "How do I audit IND$FILE?" have been "That isn't sufficient because ...". I can just picture someone taking notes: "I can avoid the auditing if ...". Far fetched? Sure. I said it was my paranoia. But it's something to consider when answering questions like that. Pat O'Keefe -- 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: [CICS-L] TPX, CICS and 0821 Sense Codes Update
On Sat, 19 Apr 2008 09:19:57 -0400, Lizette Koehler wrote: >Well, I never did find the cause of this issue. It just stopped happening >and the CICS Sys Prog said he did not do anything. >I am having an issue with TPX terminating sessions with 0821 Vtam sense >codes when accessing SOME but not all CICS regions we have here. >IST663I CINIT REQUEST FAILED, SENSE=0821 364 >IST664I REAL OLU=USSCEG01.TPXGR001 REAL DLU=USSCEG01.CICSPB >IST889I SID = F6E3F2C462F4730F >IST314I END You can get 0821 sense code if you are trying to logon to CICS using autoinstall and another terminal is already logged on which has the same last 4 characters as your terminal name. If the problem stopped happening without your CICS sysprog doing anything it just means that the other R001 happened not be be logged at the same time as you. Or perhaps you logged on first, and the other guy is now puzzling why he got an 0821 :-) Roger Bowler -- 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: how to audit the usage of IND$FILE
--- Are you referring to me? If so it doesn't take much. I feel like a hero every time I come home and my cats recognize me. If I can get an assembler program to make it to the linkedit step, I feel like a demigod. -- You took the time and effort to make the change yourself. In so doing, I'm sure that you learned something. That, to me, demonstrates that you're willing to take some initiative for yourself. It's called "self help" and we like to see that. We mostly all came up to where we are by the same route. "Dogs have owners; cats have staff" (I'm a former cat "staffer" myself. :-) ) -- 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: Command pgm from CBT file 19
-- I re-added my changes with appropriate comments as well as additions to the documentation and sample JCL. What should I do now? Should I contact one of the two people I see who have made changes and ask them? Drop a quick line to Sam Golob (address on CBT Web site) and he'll walk you through the whole process. He's "good people" and very easy to work with. Never mind that he's also a damn fine personnal friend. -- 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: Command pgm from CBT file 19
On Sun, 20 Apr 2008 19:02:43 +0200, Lindy Mayfield <[EMAIL PROTECTED]> wrote: >I re-added my changes with appropriate comments as well as additions to >the documentation and sample JCL. > >What should I do now? Should I contact one of the two people I see who >have made changes and ask them? > That would be a good place to start. If someone is still maintaining file 019, you should go through them. Otherwise go though Sam Golob. [EMAIL PROTECTED] Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: how to audit the usage of IND$FILE
Are you referring to me? If so it doesn't take much. I feel like a hero every time I come home and my cats recognize me. If I can get an assembler program to make it to the linkedit step, I feel like a demigod. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak Sent: 20. huhtikuuta 2008 18:29 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to audit the usage of IND$FILE If they ask for a program to use the SMF data and someone directs them to a working assembler sample on cbttape.org but it isn't the exact report they want, fixing the program for them makes the fixer an enabler and unpaid-consultant. That goes beyond sharing knowledge. Showing how to fix a few lines of code is sharing, rewriting the program is doing their job for them. Feeling like a hero for providing the answer does not mean they original poster learned anything. -- 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: how to audit the usage of IND$FILE
In a message dated 4/20/2008 12:05:33 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: (and not a CLIST that CALLs a program); therefore you can create an SMF type 32 record for each use of the command. >> But aren't they already cut in type 30? I think I stumbled on this while looking at ANAL30DD(slightly modified) after we went to mostly TN3270 and was trying to looking at FTP statistics or something and discovered high use of IND$FILE. Turns out the emulators didn't trust FTP back then. **Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos. (http://autos.aol.com/used?NCID=aolcmp0030002851) -- 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: how to audit the usage of IND$FILE
I believe IND$FILE is implemented as a Command Processor (and not a CLIST that CALLs a program); therefore you can create an SMF type 32 record for each use of the command. The SMF Manual discusses enablement in Chapter 4. Barry Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 [EMAIL PROTECTED] http://www.mxg.com admin questions: [EMAIL PROTECTED] technical questions: [EMAIL PROTECTED] tel: 214 351 1966 fax: 214 350 3694 -- 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: Command pgm from CBT file 19
I re-added my changes with appropriate comments as well as additions to the documentation and sample JCL. What should I do now? Should I contact one of the two people I see who have made changes and ask them? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: 20. huhtikuuta 2008 19:23 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Command pgm from CBT file 19 (was. system rexx questions) On Sat, 19 Apr 2008 21:37:50 +0200, Lindy Mayfield <[EMAIL PROTECTED]> wrote: >You were right, Rick. I only had to add 5 lines of code. (It was where >to put them that was the hard part. (-: ) > You should contribute your change to the CBT. I'm not sure if a specific person still maintains all of file 019 or if it is a group effort. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: DB2 V7.1 going down
>Here in the USA that means you should have migrated to V8 before V7 went >past >end-of-support last month I show DB2 V7 EOS as 30 June 2008. Bob Shannon Rocket Software -- 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: Command pgm from CBT file 19 (was. system rexx questions)
On Sat, 19 Apr 2008 21:37:50 +0200, Lindy Mayfield <[EMAIL PROTECTED]> wrote: >You were right, Rick. I only had to add 5 lines of code. (It was where >to put them that was the hard part. (-: ) > You should contribute your change to the CBT. I'm not sure if a specific person still maintains all of file 019 or if it is a group effort. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: DB2 V7.1 going down
Go back in your change mgmt system and see what you changed during the last 3 months. The manual states: Determine the module that failed and the registers at the time of the error. If you suspect an error in DB2, refer to Part 2 of DB2 Diagnosis Guide and Reference for information on identifying and reporting the problem. Here in the USA that means you should have migrated to V8 before V7 went past end-of-support last month. Check LOGREC, the SVCDUMP, and since V7 is past support, make sure you have all good maintenance on. If you find you changed something in the past 3 months, see if you can undo it. On Fri, 18 Apr 2008 11:03:29 +0330, Farzad E. Yazdi <[EMAIL PROTECTED] BANK.COM> wrote: >Could anyone offer any help with this repeated DB2 V7.1 failure? > >We have had failures of DB2 sometimes in Prod since 3 months ago and during >the last two weeks It has happened every 2 days. >The reason code is 00F30420 and after that the Abend 0D7 & 04F or just 04F >in DBM1 address space. > >As I found , the problem can be related to storage leakage and released more >storage for this address space via decreasing the buffer space (VP >allocations) ,since we had high VP Allocations for them much more than the >required amount >According to the Omegamon monitoring.with this change, we released 300M from >600M allocation for BPs. Also, the following parameters have been set in >DB2 zparm too: > >ContSTOR = Yes >MinStor = Yes > > >Here is the messages in system log: > >*DSNV086E + DB2 ABNORMAL TERMINATION REASON=00F30420 --- >this was for DB2PDBM1 > IEA989I SLIP TRAP ID=X13E MATCHED. JOBNAME=DB2PDBM1, ASID=005C. > IEA995I SYMPTOM DUMP OUTPUT 558 > SYSTEM COMPLETION CODE=0D7 REASON CODE=0024 > TIME=14.26.15 SEQ=06870 CPU=0041 ASID=005B > PSW AT TIME OF ERROR 077C 9713A7F2 ILC 4 INTC 24 >NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME >NAME=UNKNOWN >DATA AT PSW 1713A7EC - 05DDB20A 2000B228 003E >AR/GR 0: 935B4396/2533_ 1: /_0B80 > 2: /_8B241870 3: /_805B > 4: /_ 5: /_158BD280 > 6: /_13F82E78 7: /_57ED8030 > 8: /_158B2418 9: /_ > A: /_0C20 B: /_58F01380 > C: /2533_97139FAC D: /_7EE71DA0 > E: 958A62DE/_935B4396 F: 13F82E78/_ > END OF SYMPTOM DUMP > IEA989I SLIP TRAP ID=X13E MATCHED. JOBNAME=DB2PDIST, ASID=005D. > IEA989I SLIP TRAP ID=X13E MATCHED. JOBNAME=DB2PDBM1, ASID=005C. > > >Regards > > >-- >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: how to audit the usage of IND$FILE
agree 100%. I was especially insulted by a post a few weeks ago where the subject line contained verbiage similar to what our tech support group sees, "Emergency, High Priority Application Failure! " Like we drop what we're doing to help them out... We should quit being baby sitters for those who won't exhaust their own channels before dealing with this group. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak Sent: Sunday, April 20, 2008 10:29 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to audit the usage of IND$FILE After awhile I start to spot a trend from some people posting here that they are not trying to learn how to do something, they have figured out how to get IBM-MAIN to do their job for them. So if someone asks how to audit a program 'A' and then later asks how to audit program 'B', did they learn anything the first time? If they ask for a program to use the SMF data and someone directs them to a working assembler sample on cbttape.org but it isn't the exact report they want, fixing the program for them makes the fixer an enabler and unpaid-consultant. That goes beyong sharing knowledge. Showing how to fix a few lines of code is sharing, rewriting the program is doing their job for them. Feeling like a hero for providing the answer does not mean they original poster learned anything. If the auditors are truly coming up with all of these problems, maybe they need to provide the solution for the fee they are paid, too. Is the LISTSERV to share information or do the job for someone else for free? On Fri, 18 Apr 2008 12:27:00 -0500, Tom Schmidt <[EMAIL PROTECTED]> wrote: > >We all read & post here to both seek & share our knowledge, don't we? Or >have I completely misunderstood ibm-main's purpose? > >-- >Tom Schmidt > -- 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 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.2/1387 - Release Date: 4/19/2008 11:31 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.2/1387 - Release Date: 4/19/2008 11:31 AM -- 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: how to audit the usage of IND$FILE
This post: Use of SPFEDIT in my own program Bob Rutledge <[EMAIL PROTECTED]> is a fine example of how to educate the OP instead of doing their work for them. On Sun, 20 Apr 2008 10:29:28 -0500, Kenneth E Tomiak <[EMAIL PROTECTED]> wrote: >After awhile I start to spot a trend from some people posting here that they >are not trying to learn how to do something, they have figured out how to get >IBM-MAIN to do their job for them. > >So if someone asks how to audit a program 'A' and then later asks how to >audit program 'B', did they learn anything the first time? If they ask for a >program to use the SMF data and someone directs them to a working >assembler sample on cbttape.org but it isn't the exact report they want, fixing >the program for them makes the fixer an enabler and unpaid-consultant. That >goes beyong sharing knowledge. Showing how to fix a few lines of code is >sharing, rewriting the program is doing their job for them. Feeling like a hero >for providing the answer does not mean they original poster learned anything. > >If the auditors are truly coming up with all of these problems, maybe they >need to provide the solution for the fee they are paid, too. > >Is the LISTSERV to share information or do the job for someone else for free? > > > >On Fri, 18 Apr 2008 12:27:00 -0500, Tom Schmidt ><[EMAIL PROTECTED]> wrote: > >> >>We all read & post here to both seek & share our knowledge, don't we? Or >>have I completely misunderstood ibm-main's purpose? >> >>-- >>Tom Schmidt >> > >-- >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: Untrusted Access (Was how to log IND$FILE)
Keystrokes and mouse clicks go only so far, you need the program that captures screen images too. The additional security you mention only permits access to data, which like auditing is not proof of anything if they are working with data pertinent to their job. You need to catch them transferring the data to a medium they should not be. Adding the audit of programs that help copy data is part of that. And tracking how data is used. The notion that monitoring IND$FILE does anything by itself falls short. I can use a program by any name to make a copy of production data to &sysuid..test.data and then file transfer that by any of several methods to a thumb drive. If IND$FILE shows I transfered test.data, does a red flag go up? So if you think someone stole data, you need to follow the data from file to file to end point. On the PC side they could rename the file from test.data to puzzle.log and then copy it to the thumb drive or even junk.txt and include it as an attachment in an email. How did you track that? What if junk.txt was in an hfs and your web server allowed anyone who knew the name to use a web browser from home to retrieve the file. Next day they delete the hfs file, so even though your web server log shows the file was fetched, it no longer exists to see what it was. Back to trying to follow how it got created. Catching them with data they should not have on a non-company device would help. Accessing what they should is proof they were doing their job. Retina scanners, RACF, or other measures only help ensure the people who should access data do, nothing about what they do with it. And I still add on, pencil/pen and paper were used to copy data long before FTP. Do you install cameras overhead? On Fri, 18 Apr 2008 16:55:08 -0400, Lizette Koehler <[EMAIL PROTECTED]> wrote: >Thought I would see if this might be expanded to what do you do if you had >someone in your organization you thought was stealing company priority >information (source code, data, etc) > >I would think that if that person were working on a company supplied PC then >the company could install some sort of SPYWARE that would trace key strokes >and mouse movements (?). They would then have a complete audit trail of >what was accessed during that persons access time. They might even go >further and have installed the optic readers for retina or finger prints >that would not allow access to those items unless they passed the scan. > >Of course we could go one more level with security and RFID chips, but I >thought I would stop here. > >Any thoughts? > >Lizette > >-- >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: how to audit the usage of IND$FILE
After awhile I start to spot a trend from some people posting here that they are not trying to learn how to do something, they have figured out how to get IBM-MAIN to do their job for them. So if someone asks how to audit a program 'A' and then later asks how to audit program 'B', did they learn anything the first time? If they ask for a program to use the SMF data and someone directs them to a working assembler sample on cbttape.org but it isn't the exact report they want, fixing the program for them makes the fixer an enabler and unpaid-consultant. That goes beyong sharing knowledge. Showing how to fix a few lines of code is sharing, rewriting the program is doing their job for them. Feeling like a hero for providing the answer does not mean they original poster learned anything. If the auditors are truly coming up with all of these problems, maybe they need to provide the solution for the fee they are paid, too. Is the LISTSERV to share information or do the job for someone else for free? On Fri, 18 Apr 2008 12:27:00 -0500, Tom Schmidt <[EMAIL PROTECTED]> wrote: > >We all read & post here to both seek & share our knowledge, don't we? Or >have I completely misunderstood ibm-main's purpose? > >-- >Tom Schmidt > -- 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: How fast is XCF
Ron MacRae wrote: My company has a product that runs in muliple address spaces on multiple LPARS and on windows & unix boxes. Due to the relative response times of XMS and TCPIP we've had to put the high msg activity ASIDs on on the same LPAR as TCPIP is many orders of magnitude slower than XMS. We had hoped XCF would give us some relief from this issue but our testing has shown that XCF is even slower than TCPIP between LPARs on the same complex. TCPIP ping time is 1-2mSecs and XCF comes in at 9-11mSecs on average. Are our figures for XCF performance reasonable? I'm sure by playing with dedicated hardware etc we could get it in line with TCPIP but even if we tune things to the Nth degree and throw hardware at the issue what sort of response times can we hope to see? Regards, Ron MacRae. If the LPARs are on the same box and you are sharing the same OSA's on the LPAR's TCPIP will most likely be faster than XCF. When sharing OSA's the path never leaves the OSA adapter, so the data never leaves the box. Depending on what you are using for your XCF path it could be leaving the box and thus be a bit slower. How busy is your XCF path? Since everything is on the same box, I would suggest you may want to test HiperSockets. It should be faster than sharing OSA's as it is basically a memory to memory move. When we tested HiperSockets ping times were 0ms between a z/OS LPAR and a zLinux virtual machine running under z/VM. Are your messages a lot of little messages that are all sent on unique TCP connection, or a few big messages sent on the same TCP connection? Typically latency/RTT will only have a big impact if you need to start/stop a lot of TCP connections and you are sending a lot of little messages that must have their own TCP connection. If you are sending larger messages, once the TCP connection is started, windowsizes should lessen the impact of latency/RTT. -- 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: COBOL / VSAM question.
The timing of it happening and being diagnosed with a recent unrelated change. On Fri, 18 Apr 2008 16:20:42 -0700, CICS Guy <[EMAIL PROTECTED]> wrote: >IIRC (early VSAM & DOS) >What is it about the sysplex that prompts the 97? > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris >Sent: Friday, April 18, 2008 2:30 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: COBOL / VSAM question. > >snip > >Given that the problem has been around since VSAM started doing implicit verifies on OPEN when a verify situation >existed (well over 20 years ago), I am surprised that the problem hadn't surfaced long before this year. > -- 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: "action" in UK33496
Programs can write to SYSPRINT as long as the blksize is compatible with LRECL so if an installation previoulsy hardcoded a valid blksize instead of using a system determined blksize then no action is required. This is one of those annoying actions we spend too much time researching only to learn we can ignore it. It is a shame when one IBMer could not put sufficient information in the HOLD data causing thousands of us to go hunt down the APAR. On Sun, 20 Apr 2008 05:00:13 -0500, Big Iron <[EMAIL PROTECTED]> wrote: >Since the blocksize that would have been used before this PTF was not >the "System Defined Blocksize", then some installations may have already >adjusted their procedures to be compatible with the previous incorrect >behaviour. They may now need to take some action to deal with the >change in behaviour introduced by this PTF. > >In other cases, similar (or even more drastic) changes are classified as >documentation change which can cause grief when people assume that >applying those PTFs will not require changes to existing production >applications. > >Also, the information contained on the HOLD may not always be sufficient >to understand all the implications of applying the maintenance and it may >sometimes be necessary to examine the APAR/PTF text. > >Bill > >On Sat, 19 Apr 2008 21:12:13 +0200, R.S. <[EMAIL PROTECTED]> wrote: > >>HOLD(UK33496) SYS FMID(HCI6500) REASON(ACTION) DATE(08037) >>COMMENT >> (If the SYSPRINT file is being written to a data set, please >> note that a System Defined Blocksize will be allocated if no >> BLKSIZE is defined or a BLKSIZE of 0 is defined on the DD card. >> >>My humble questions: >>1. Is it really ACTION to perform ? >>2. Isn't the behaviour obvious and expected ? If yes, then why to >>mention it under any HOLD type ? >>3. Is it funny ? >> >>I also found ACTION which was ...documentation change (in other PTF). >> >>-- >>Radoslaw Skorupka >>Lodz, Poland >> >> >>-- -- 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: How fast is XCF
Ron MacRae wrote: My company has a product that runs in muliple address spaces on multiple LPARS and on windows & unix boxes. Due to the relative response times of XMS and TCPIP we've had to put the high msg activity ASIDs on on the same LPAR as TCPIP is many orders of magnitude slower than XMS. We had hoped XCF would give us some relief from this issue but our testing has shown that XCF is even slower than TCPIP between LPARs on the same complex. TCPIP ping time is 1-2mSecs and XCF comes in at 9-11mSecs on average. Are our figures for XCF performance reasonable? XCF runs your code in SRB-mode and allows you to process messages on all CPs simultaneously. In my experience, nothing is faster. However, I have seen XCF slow down considerably when DELIVERMSG=ORDERED is specified on IXCMSGO macros. Also, I have not benchmarked TCP/IP over HiperSockets -- which is essentially a QDIO memory-to-memory copy between LPARs. If that's what you're using, your results could be interesting. It's probably worth ensuring that you don't have resource issues with XCF. Insufficient or wrong-sized buffers will introduce slow-downs. (RMF reports can help here.) Also, XCF messages can flow over either CTCs or CF structures -- the latter being the slower medium AFAIK. To eliminate such variables, I would start by comparing the two techniques between address spaces on a single image and work from there. If you do discover XCF inefficiencies, you might consider reporting them to IBM. XCF is the messaging protocol used by all system components -- including TCP/IP. It should be fast! -- 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: "action" in UK33496
Since the blocksize that would have been used before this PTF was not the "System Defined Blocksize", then some installations may have already adjusted their procedures to be compatible with the previous incorrect behaviour. They may now need to take some action to deal with the change in behaviour introduced by this PTF. In other cases, similar (or even more drastic) changes are classified as documentation change which can cause grief when people assume that applying those PTFs will not require changes to existing production applications. Also, the information contained on the HOLD may not always be sufficient to understand all the implications of applying the maintenance and it may sometimes be necessary to examine the APAR/PTF text. Bill On Sat, 19 Apr 2008 21:12:13 +0200, R.S. <[EMAIL PROTECTED]> wrote: >HOLD(UK33496) SYS FMID(HCI6500) REASON(ACTION) DATE(08037) >COMMENT > (If the SYSPRINT file is being written to a data set, please > note that a System Defined Blocksize will be allocated if no > BLKSIZE is defined or a BLKSIZE of 0 is defined on the DD card. > >My humble questions: >1. Is it really ACTION to perform ? >2. Isn't the behaviour obvious and expected ? If yes, then why to >mention it under any HOLD type ? >3. Is it funny ? > >I also found ACTION which was ...documentation change (in other PTF). > >-- >Radoslaw Skorupka >Lodz, Poland > > >-- >BRE Bank SA >ul. Senatorska 18 >00-950 Warszawa >www.brebank.pl > >S±d Rejonowy dla m. st. Warszawy >XII Wydzia³ Gospodarczy Krajowego Rejestru S±dowego, >nr rejestru przedsiêbiorców KRS 025237 >NIP: 526-021-50-88 >Wed³ug stanu na dzieñ 01.01.2008 r. kapita³ zak³adowy BRE Banku SA wynosi 118.642.672 z³ote i zosta³ w ca³o¶ci wp³acony. > -- 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: How fast is XCF
What kind of path topology are you using for XCF? CTCs or ICF CF structures? Or what? And to what degree have you tuned XCF? I'm not making any speed claim or promise. Just trying to understand your situation in a little more detail. Thanks, Martin 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
How fast is XCF
My company has a product that runs in muliple address spaces on multiple LPARS and on windows & unix boxes. Due to the relative response times of XMS and TCPIP we've had to put the high msg activity ASIDs on on the same LPAR as TCPIP is many orders of magnitude slower than XMS. We had hoped XCF would give us some relief from this issue but our testing has shown that XCF is even slower than TCPIP between LPARs on the same complex. TCPIP ping time is 1-2mSecs and XCF comes in at 9-11mSecs on average. Are our figures for XCF performance reasonable? I'm sure by playing with dedicated hardware etc we could get it in line with TCPIP but even if we tune things to the Nth degree and throw hardware at the issue what sort of response times can we hope to see? Regards, Ron MacRae. -- 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
