ITOM SAF Resource MENU.ADM?N
(Cross-posted to RACF-L and IBM-MAIN) Greetings all, The IBM Tivoli Output Manager (ITOM) User's Guide has the SAF resource name for the administrator panel listed two different ways - one as MENU.ADMIN and the other as MENU.ADMN. I'd like to know which of the two it really is. If you can tell me, please respond. TIA. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc.*** Celebrating our Twentieth Anniversary *** 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com - 2012 RACF Training - Audit for Results - Boston - OCT 30 - NOV 1 - Securing z/OS UNIX - WebEx - JUL 31 - AUG 2 - Intro Basic Admin - WebEx - OCT 15-19 - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDSE and DFDSS
Either: 1) Open a SR. I had a latch issue and LVL2 provided me with a SLIP. Contention was with DFHSM. It was diagnosed to be a timing issue and they are working on a fix. 2) Try IEBCOPY to a pre-allocated dataset. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Steely Sent: Wednesday, June 13, 2012 11:23 AM To: IBM-MAIN@bama.ua.edu Subject: PDSE and DFDSS I would like to move a PDSE dataset using DFDSS - I have never been able to do this. I am using the following format: COPY DATASET( - INCLUDE( - OS130508.SMPE.SMPPTS- ))- OUTDYNAM((MVASM2)) - CANCELERROR - CATALOG - DELETE PURGE - ALLDATA(*) - ALLEXCP - PROCESS(SYS1,UNDEF) - TGTALLOC(SRC) When I try to execute the job - the job just sits there and then I start receiving PDSE messages that there is a PDSE problem. IGW031I PDSE ANALYSIS Start of Report(SMSPDSE1) 658 -data set name-- -vsgt--- OS130508.SMPE.SMPPTS 01-MVASM2-000104 ++ Unable to latch DIB_Global_Latch:7F3A7680 Latch:7F3A7698 Holder(0088:00AF8748) Holding Job:SDALMFSM ++ Lock GLOBAL DIRECTORY EXCLUSIVE held for at least 47 seconds Hl1b:7FF769A0 HOLDER(0088:00AF8748) Holding Job:SDALMFSM ++ Lock GLOBAL FORMATWRITE EXCLUSIVE held for at least 47 seconds Hl1b:7FF769A0 HOLDER(0088:00AF8748) Holding Job:SDALMFSM PDSE ANALYSIS End of Report(SMSPDSE1) At that point I have to cancel the job. I am z/OS v1r11 any help would be appreciated. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Convert Text to XMIT
Jake, On 2012-06-12 07:54, Jake anderson wrote: Thanks for your reply. I presume this would need little more research and get back to you all once I recover it. I have done something like this in 2005(?). The XMIT file was screwed and I could not get it back, but the contents, a PL/I library had sequence numbers and the PL/I was pretty standard, XXX: PROC ... END XXX; and it was FB(80). I just treated it (on the PC) as a binary file, used a hex-editor to chop off the mangled XMIT headers and then read it into a text editor that could handle fixed length records. Removed the XMIT control characters, obvious from sequence numbers that were suddenly no longer aligned, saved it back as a single record and repeated this process a few more times. It took a couple of hours, but in the end I got all source back. It will take you time, but text is recoverable. Robert -- Robert AH Prins robert(a)prino(d)org On Tue, Jun 12, 2012 at 12:53 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 11 Jun 2012 07:23:22 -0500, McKown, John wrote: If you mean that they FTP transferred an XMIT file via an intermediate system which was ASCII based (such as Windows) and forgot to do a BINary transfer at some stage, you are out of luck. The problem is that, in general, if you do an EBCDIC to ASCII to EBCDIC tranlation which include non printable character, you don't get back the original file. The reason is because multiple EBCDIC characters translate to the same ASCII character. So there is NO way to know what the original character is. The OP sent me, privately, a sample of his data. Excerpts from my analysis/reply to him: It was apparently a PDS containing several (perhaps 5) Rexx EXECs. ... Apparently a TRANSMIT OUTDATASET() was performed. That output data set, about 100kB, was FTPed to the PC in ASCII mode. Is the EBCDIC instance lost from z/OS? ... Recovery is tedious. I haven't the resources to help you further. Some of the members (a little more than half the content) had sequence numbered lines; those numbers could be useful markers in reconstructing the data. [Abby Sciuto or Penelope Garcia would do it in seconds.] You might take this back to IBM-MAIN. ... But, please, answer completely any questions people ask you; don't expect others to do all the detective work. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Weird thought on misuse of a GDG.
At 14:58 -0500 on 06/11/2012, Roberts, John J wrote about Re: Weird thought on misuse of a GDG.: Also, what is the significance of the V00 part of the qualifier? I was always led to believe that it was a vestige of something that was never implemented. It allows you to create a replacement version of Generation without breaking the sequence. Lets say that for some reason you need to replace the contents of X.G0500V00. If you make the replacement X.G0500V01, it will replace the V00 copy in the relative sequence. IOW: When X(-1) is X.G0501V00, X(-2) is X.G0500V01 (in lieu of the replaced V00). This is useful for example if you want to move old files from TAPE to DASD (the V00 signaling that the file was copied to DASD from its original TAPE volume). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)
On 2012-05-17 11:42, Robert AH Prins wrote: On 2012-05-17 11:14, Bernd Oppolzer wrote: I would like to add: with the previous compiler, CALL PLIMOVE enabled us to force the generation of MVCL. Using, for example CALL PLIMOVE (ADDR (target), ADDR (source), length); the compiler generated MVCL, but coding target = source; (if applicable), or BY-NAME-assignments, the compile generated MVCs etc. Now, with V3.9, the compiler generates the same in the two cases, that is MVCs or MVC loops, so we have no possibility to force the generation of MVCL. AFAIK, my co-workers didn't play with the ARCH options, so far. TUNE is TUNE(2), again AFAIK. The TUNE option has been removed from the V4.1 anyway. I have other projects at the moment, so I had not much time so far to investigate this. But remember: the problem showed up by a Strobe Report, so it seems to be significant. But: if PLIMOVE does no better than a simple assignment, using PLIMOVE seems to make no sense to me. In a certain way, this problem is somewhat different from the first problem in this thread. Robert complained about the optimizer doing a bad job, that is: some instructions are generated that are useless, and others are questionable. But here we have a simple instruction of the HLL (PLIMOVE) which I expect to be implemented using the best instructions the machine provides. If this turns out not to be the case, this is IMHO simply a bug, not only a flaw of the optimizer. The programmer already did some kind of optimization him- or herself, when he or she decided to use PLIMOVE. He or she may well expect that the compiler generates the best available machine instruction for this HLL instruction. You hit the nail right on the head! But I do remember that there was a APAR that explains why the MVCL was removed again. I can't point you to it as the link to the PL/I APARs has gone 404. It's back and I have to correct myself, I've only managed to find a APAR telling that the generation MVCLE 's was removed http://www-01.ibm.com/support/docview.wss?rs=619context=SSY2V3q1=%2b5655H3100+%2br370uid=swg1PK79325loc=en_UScs=utf-8cc=uslang=all Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)
On 2012-05-17 11:14, Bernd Oppolzer wrote: I would like to add: with the previous compiler, CALL PLIMOVE enabled us to force the generation of MVCL. Using, for example CALL PLIMOVE (ADDR (target), ADDR (source), length); the compiler generated MVCL, but coding target = source; (if applicable), or BY-NAME-assignments, the compile generated MVCs etc. Now, with V3.9, the compiler generates the same in the two cases, that is MVCs or MVC loops, so we have no possibility to force the generation of MVCL. AFAIK, my co-workers didn't play with the ARCH options, so far. TUNE is TUNE(2), again AFAIK. The TUNE option has been removed from the V4.1 anyway. I have other projects at the moment, so I had not much time so far to investigate this. But remember: the problem showed up by a Strobe Report, so it seems to be significant. But: if PLIMOVE does no better than a simple assignment, using PLIMOVE seems to make no sense to me. In a certain way, this problem is somewhat different from the first problem in this thread. Robert complained about the optimizer doing a bad job, that is: some instructions are generated that are useless, and others are questionable. But here we have a simple instruction of the HLL (PLIMOVE) which I expect to be implemented using the best instructions the machine provides. If this turns out not to be the case, this is IMHO simply a bug, not only a flaw of the optimizer. The programmer already did some kind of optimization him- or herself, when he or she decided to use PLIMOVE. He or she may well expect that the compiler generates the best available machine instruction for this HLL instruction. You hit the nail right on the head! But I do remember that there was a APAR that explains why the MVCL was removed again. I can't point you to it as the link to the PL/I APARs has gone 404. Finally a note to those following this thread, due to the closure of the gateway between 'bit.listserv.ibm-main' and the list, it is now available in two diverging versions, one here on the list, the other one on news://comp.lang.pl1 very regrettable. Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Retiring after 43+ years with IBM
Frank, All of your SORT children will now have to grow up. I count myself among them. Sir, you spoiled us! You are, most definitely, leaving the SORT world a better place than you found it; a very fine testament to your career. Please do check back in with us from time to time. I'll smile when I see your name and remember that we had it great once! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Frank Yaeger Sent: Tuesday, May 15, 2012 9:00 PM To: IBM-MAIN@bama.ua.edu Subject: Retiring after 43+ years with IBM Just a note to let everyone know I'll be retiring at the end of this month (5/31/2012). I've been with IBM for 43+ years (plus a couple of summers in college) and I've enjoyed my career immensely. I've especially enjoyed being able to help people use the DFSORT/ICETOOL functions I developed, over many years, in new and interesting ways. Once I retire, I won't be posting solutions any more since I won't have access to a mainframe to test them, and I don't like posting untested solutions. I may lurk a bit or I may not. I'm looking forward to retirement, but I'll also miss this list. I'm happy to say that others on the DFSORT Team will continue to contribute. Thanks to everyone for giving me the chance to earn a living all these years doing something that was a lot of fun for me. Long live the mainframe, IBM, z/OS, DFSORT and ICETOOL! Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)
On 2012-05-16 07:26, Elardus Engelbrecht wrote: Robert Prins wrote: Can anyone skilled in the art tell me why a compiler that probably dates back to the late 1970'ies or early 1980'ies generates the following short and sweet code for a PL/I BY NAME assignment, while the not completely new (but still fairly recent) version of Enterprise PL/I (V3R9) generates the very, very, very long-winded code below it? I'm not skilled in this art, but is your Enterprise PL/I (v3r9) also using Language Environment or not? Yes, it is. Then again, I always thought that the fastest instructions are those ones that are never executed... Those instructions don't need to be optimized... :-) Exactly! Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)
David, On 2012-05-16 08:23, David Crayford wrote: Robert, I'm no expert but I have read that newer hardware models (Z10 and above) are essentially RISC processors that run complex instructions in millicode. In the I may be wrong, but I think the z196 is the first OOO machine and Enterprise PL/I V3R9 pre-dates it by two years. case of a MVC instruction it would have to do that in a loop which would require branching, the enemy of pipelined exeuction units. It's also possible to run simple instructions in parallel. It's plausible an MVC instruction can be executed more efficiently as a sequence of LG/STG instructions. Given that moves are the most executed instructions, at least on x86, (see, among many others www.ijpg.org/index.php/IJACSci/article/download/118/29) and I have little doubt that the same holds true for about any other architecture and that there is special x86 circuitry to optimize MOVS instructions, it would be highly surprising if IBM did not make MVC as fast as possible, millicoded or not. The OOO decode units do this for you with instruction cracking on a z196, it seems that on a z10 the optimizer is doing the same thing. Possibly, but that does not explain the 10 superfluous reloads of r1. See this document - page 21 http://www-01.ibm.com/software/htp/tpf/tpfug/tgf11/How_do_you_do_when_youre_a_z196_CPU.pdf Optimizers create arcane code. It's almost impossible to verify without understanding the secret sauce. A lot of the code the optimizers spit out is intractable, I don't know much about z/OS assembler, but at least I sort of managed to understand the code generated by the OS PL/I compiler. The code generated by Enterprise PL/I is completely unreadable, even some (or more than some) on this list might have trouble figuring out why it does what it does. and it's almost a paradox that a longer code path produces faster code. If you don't like it you can always compile at a different ARCH() level and ask IBM. Going back to ARCH(5) doesn't produce anything that seems much shorter, still the ridiculous reloading of the same register, and oodles and oodles instructions which would run and take time on a definitely not-OOO CPU: 003A58 E300 8238 0014 003119 | LGF r0,LINE_PTR(,r8,568) 003A5E 4110 E00C003119 | LAr1,_shadow21(,r14,12) 003A62 B914 00E0003119 | LGFR r14,r0 003A66 D278 B38E 6D33 003118 | MVC LINE(121,r11,910),REPT_INIT(r6,3379) 003A6C E3B0 DC20 0004 003119 | LGr11,#SPILL17(,r13,3104) 003A72 50B0 D25C003119 | STr11,_temp9(,r13,604) 003A76 DE03 D25C 1000 003119 | ED_temp9(4,r13,604),_shadow21(r1,0) 003A7C 4110 E003003119 | LAr1,#AddressShadow(,r14,3) 003A80 41F0 E00A003119 | LAr15,#AddressShadow(,r14,10) 003A84 D202 1001 D25D 003119 | MVC _shadow21(3,r1,1),_temp9(r13,605) 003A8A 9240 E003003119 | MVI _shadow21(r14,3),64 003A8E 5810 8000003119 | L r1,REPT_PTR(,r8,0) 003A92 50B0 D2E4003119 | STr11,_temp8(,r13,740) 003A96 41B0 E017003119 | LAr11,#AddressShadow(,r14,23) 003A9A 4110 100E003119 | LAr1,_shadow21(,r1,14) 003A9E DE03 D2E4 1000 003119 | ED_temp8(4,r13,740),_shadow21(r1,0) 003AA4 D202 F001 D2E5 003119 | MVC _shadow21(3,r15,1),_temp8(r13,741) 003AAA 9240 E00A003119 | MVI _shadow21(r14,10),64 003AAE 5810 8000003119 | L r1,REPT_PTR(,r8,0) 003AB2 E3F0 DB98 0004 003119 | LGr15,#SPILL0(,r13,2968) 003AB8 D202 E011 1010 003119 | MVC _shadow21(3,r14,17),_shadow21(r1,16) 003ABE 5810 8000003119 | L r1,REPT_PTR(,r8,0) 003AC2 D206 D2D4 F4A4 003119 | MVC _temp19(7,r13,724),' ..'(r15,1188) 003AC8 D203 D26C 1013 003119 | MVC _temp15(4,r13,620),_shadow18(r1,19) 003ACE 4110 D26C003119 | LAr1,_temp15(,r13,620) 003AD2 D202 D24C 1001 003119 | MVC _temp11(3,r13,588),_shadow12(r1,1) 003AD8 4110 D24C003119 | LAr1,_temp11(,r13,588) 003ADC DE06 D2D4 1000 003119 | ED_temp19(7,r13,724),_temp11(r1,0) 003AE2 D205 B000 D2D5 003119 | MVC _shadow21(6,r11,0),_temp19(r13,725) 003AE8 5810 8000003119 | L r1,REPT_PTR(,r8,0) 003AEC D206 D2CC F4A4 003119 | MVC _temp21(7,r13,716),' ..'(r15,1188) 003AF2 D202 D249 101B 003119 | MVC _temp18(3,r13,585),_shadow12(r1,27) 003AF8 D202 D246 D249 003119 | MVC _temp20(3,r13,582),_temp18(r13,585) 003AFE 4110 E028003119 | LAr1,#AddressShadow(,r14,40) 003B02 E300 D246 0090 003119 | LLGC r0,a1:d582:l1(,r13,582) 003B08 E300 3114 0080 003119 | NGr0,=X' 000F' 003B0E 41B0 D246003119 | LAr11,_temp20(,r13,582) 003B12 4200 D246003119 | STC r0,a1:d582:l1(,r13,582) 003B16 DE06 D2CC B000 003119 | ED_temp21(7,r13,716),_temp20(r11,0) 003B1C D204 1000 D2CE 003119 | MVC _shadow21(5,r1,0),_temp21(r13,718) 003B22 5810 8000003119 | L
Re: Comparison of compiler generated code AD 1980(ish) v 2010(ish)
On 2012-05-16 14:59, Paul Gilmartin wrote: On Wed, 16 May 2012 07:55:48 -0600, Steve Comstock wrote: Well, I knew someone would raise that exception. No, Metal C does not use LE. Not sure if SP C (Systems Programmer C) is still around and it would be an exception too. I believe it's been discussed in these fora that C and PL/I share an optimizer/code generator. I hope this includes Metal C. It's a long leap of logic, but that might weaken the argument for LE entanglement. Is MOVE, BY NAME plausibly dependent on LE? For PL/I is is most definitely not, it's just a shortcut for lazy people and I've worked at sites that explicitly forbade its use, considering it just as bad as a SELECT * in SQL. Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Comparison of compiler generated code AD 1980(ish) v 2010(ish)
three-instruction sequence like 003FC0 E310 DF10 0158 003120 | LY r1,a1:d7952:l4(,r13,7952) 003FC6 E300 1047 0015 003120 | LGH r0,_shadow20(,r1,71) 003FCC 4000 E064003120 | STH r0,_shadow20(,r14,100) is really faster than the simple 6-byte one-instruction sequence 0026D4 D2 01 7 064 6 047 MVC REPT_LINE.DATE.MONTH(2),REPT_LIST.DATE.MONTH Then again, I always thought that the fastest instructions are those ones that are never executed... Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ### of GDG Entries
At 00:58 -0500 on 05/11/2012, Mike Schwab wrote about Re: ### of GDG Entries: We have Mobius that creates report files with the date and time as part of the file name. Huge numbers of 1 track datasets. Why not make them members of a PDS? The member name would be XDDDHHMM where X is the year number [A=2012 and advances through B-Z one letter per year], DDD is the day number, and HHMM is the time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ### of GDG Entries
At 20:12 + on 05/10/2012, Donnelly, John wrote about ### of GDG Entries: We have a business application that creates literally 100s of GDGs a day; please don't ask. Is there any way to create or pretend to create a GDG base greater than 255... Why not concatenate all of them daily and create a new GDG entry from the result (ie: Have as single master GDG dataset for each day). That way you would have the last 255 days worth of data. Is there any need to be able to separately access each of the GDGs created? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Multiple waiting tasks, one control block?
At 08:43 -0700 on 05/05/2012, Charles Mills wrote about Multiple waiting tasks, one control block?: I have a situation in which it would be a wonderful thing if I could have multiple tasks waiting for a single event, without having a separate wait control block of some sort for each task. Why? I have no control over what the tasks have in advance (system exit situation) and doing a GETMAIN or the like so that each task could have its own ECB, and then chaining them all together, following the chain with POSTs, FREEMAINs, etc., etc., would be a real pain, a lot of overhead, and a real risk of mucking it up. I know WAIT/POST/ECB does not support multiple tasks waiting on a single ECB. I guess that EVENTS does not support this either -- but I don't see it explicitly in the documentation -- is my assumption correct? Is there any other way to do this? Some clever use of ENQ or something like that? Some other z/OS wait service besides WAIT and EVENTS? Thanks, Charles If what you want is to have a number of tasks wait until some event occurs and once it does to have all of them resume operation independent of each other then ENQ can be used for this signalling. You have the signaling task do an Exclusive ENQ. The others do Shared ENQs. Once the signaling task does the DEQ all the waiting tasks will get dispatched. Note that this requires that the signaling task have done its ENQ before the waiting tasks do theirs (and thus go into a wait state waiting on the DEQ). Another way to use WAIT/POST is to have each waiting task know the location of a single ECB. Initially it is set to show that no post has yet been done on it. Until you want the tasks to go into a wait until the POST is done, you it set to look like a WAIT has been done on it. You later you do the actual POST. The waiting tasks are in a loop. They check the status of the ECB and if not yet posted, do a STIMER WAIT and then loop back to the ECB Status Check. Once the ECB has been posted they go on and do what they were waiting to do. Note that you are not actually using WAITs but only periodically checking the state of the ECB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Multiple waiting tasks, one control block?
At 09:27 -0700 on 05/06/2012, Charles Mills wrote about Re: Multiple waiting tasks, one control block?: Robert, thanks. I am kicking the ENQ idea around. ENQ is certainly promising. There are some interlock issues with re-establishing the exclusive ENQ after relinquishing it, and what do the intended waiting tasks do in the meantime, but it has promise. You start with an EXC ENQ with the resource not yet Available. Once it is available, you DEQ. Everyone who wants the resource does a SHR ENQ (and will fire off when the DEQ is done). As to re-establishing the EXC ENQ, you just issue it after the DEQ. This will wait until all the SHR ENQs DEQ at which point you acquire a new resource and then DEQ. Any new task that ENQ SHRs after the 2nd EXC ENQ will wait for the 2nd EXC DEQ. The idea is that you EXC ENQ, get the resource and store its address/whatever, and DEQ. You then do the same operation. Any task looking for the current version of the resource will SHR ENQ and wait for the DEQ. The subsequent EXC ENQ cycle will wait for all the SHR DEQs. Any SHR ENQ done AFTER the waiting EXC ENQ will wait for the next EXC DEQ. There does need to be some flag to tell the EXC ENQ task not to do another EXC ENQ UNLESS there was at least one SHR ENQ waiting (to prevent useless looping). Otherwise use a STIMER loop (see below) to wait for at least once SHR ENQ. The flag that a SHR ENQ had been done can be a CS that is done by each SHR task when they come out of their wait. The STIMER approach does not even really need an ECB -- you're just using it as a flag. In the STIMER loop, you just have a field that is tested and if not set you STIMER again. The test is via TM not WAIT but using PORT to set it is simplest (you can also CS or some other locking instruction). At this moment I am still holding off. I don't have to solve this -- I can instead simply not implement the feature I am thinking of that would require this. At this moment none of the solutions are good enough to make the feature viable, IMHO. Thanks again, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
At 17:56 -0400 on 05/05/2012, Peter Relson wrote about Re: Comments on DFSMS verbose messages?: Please avoid an absurdity such as AMODE(ANY), where ANY no longer means any, but instead any except 64. Tongue in cheek: sorry for not being prescient enough in (approximately) 1977 to think that someone might ever need 64-bits worth of addressability. It seems obvious now. No, really: I agree. And that is why those options are available in other forms now which I recommend that you use -- such as '31' instead of ANY in AMODE, or in the LOC parameters of STORAGE OBTAIN. We will never remove support for ANY. We can only encourage you to use better choices. The problem is that before 64 AMODE you had 3 AMODE Choices - 24-Only, 31-Only, or BOTH 24 and 31 (ie: Any). If I code AMODE-31 I can have problems with something that needs AMODE-24. There needs to be am AMODE (such as ALL) to say that all 3 AMODES (24/31/64) are supported. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
FACILITY Class Resources for IBM's HOURGLASS product
Greetings all, (cross-posted to IBM-MAIN RACF-L) I am once again updating my presentation on the FACILITY class and its many resources. (If you are unfamiliar with my presentation, a copy is available on our website via the RACF Center webpage.) I've come across a set of FACILITY resources for the IBM product HOURGLASS (acquired from Princeton Softech) which are not documented in the product's manual. The resources are HOURGLASS_CX_ADMIN, HOURGLASS_CX_USER, and HOURGLASS_CX_REFR. Two of them are mentioned in APAR PK89016, which indicates these resources are documented in the AGGCXT1 member of the product's SAGGSAMP library. I would greatly appreciate someone assisting me with my research of these resources by providing me with a copy of this member. I want to ensure I properly describe these resources and the access permissions they require in my presentation. Please reply directly to me. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc.*** Celebrating our Twentieth Anniversary *** 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com - 2012 RACF Training - Audit for Results - Boston - OCT 30 - NOV 1 - Securing z/OS UNIX - WebEx - JUL 31 - AUG 2 - Intro Basic Admin - WebEx - OCT 15-19 - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
At 22:03 -0500 on 05/03/2012, W. Kevin Kelley wrote about Re: Comments on DFSMS verbose messages?: The concern was about the clutter that the additional message lines would cause. Also, the same explanation lines are repeated in each instance of the error message, so there would be a lot of redundancy. If the extra lines are pure boilerplate and not id and value then why not have a database where you can plug in the message number and display the added text? I have a vague memory of being able to do this. It might have just been the ability to look the message up online in the Messages and Codes Manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: The old is new again - Not IBM related, but I hope interesting
John, I didn't think anyone remembered MP/M-80, let alone what it did! Back in the 80's, I put together MP/M-80 machines and wrote application software for them. We benchmarked our 7-8 user systems and ran better than any DEC multi user system. We were even the first Iomega customer and designed a board to allow their 8 cartridge to work as a high capacity (10M) storage device. Ah, the old days. How fun was that? My, we've come a long, long way in 25 years. Robert -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Wednesday, May 02, 2012 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: The old is new again - Not IBM related, but I hope interesting http://www.phoronix.com/scan.php?page=articleitem=plugable_multiseat_kicknum=1 This is a USB device which can plug into a normal PC running Linux (Fedora 17 is mentioned). You then connect a DisplayLink monitor, USB keyboard and mouse to the device. And you have a multi-user system on a single PC. Not a server PC with other PCs connected as clients, but just one single PC. Reminds me of what could be done with MP/M-80 (the multiuser version of CP/M-80), except back then it was a serial (RS-232?) connected keyboard/display. Or, maybe, an S/360 with a 2260(?) or 3272(?). John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Java PTF Packaging Error Deletes the Java SDK With RC=0! (See APAR IV05507)
At 16:30 -0500 on 05/01/2012, Mark Zelden wrote about Re: Java PTF Packaging Error Deletes the Java SDK With RC=0: It's just extra work and space for managing a PTF that replaces the entire product / unix file system contents with each apply. I don't need SMP/E to keep track of that for me. While I can see your viewpoint, using SMP/E to handle the install, DOES document the PTF Level and insure that you have all the needed/indicated maintenance that the main PTF indicates as required. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ServerPac RACF* jobs (rant)
At 17:35 -0400 on 04/30/2012, John Eells wrote about Re: ServerPac RACF* jobs (rant): So we created two jobs, with an overall z/OS section for each job, and then subsections for other things you could order along with z/OS to be included if you ordered them. The result *was* (at the time) tested against new, empty RACF databases and any bugs found were fixed. That structure virtually guaranteed some duplication in things like SETR commands, but because of how the internals of ServerPac production worked at the time there was no good way to prevent that. That was (if I understand correctly) because no-one bothered to look at the interaction between optional components. From your description it sounds like the added subsections were of the If Component X is ordered then add these commands type with no attempt to have the added commands divided into 2 groups (Unique to this component and shared with 2 or more components). Commands in the 2nd group should only be added if a prior component has not been ordered. IOW: Component Y has 6 commands shared with other Components (such as Component X). If Component X has had its commands added, then when it is time to add Component Y's commands if 2 of these 6 are shared with X, then only the other 4 should be inserted (with the other 2 suppressed since they are already there due to X). If you then order Component Z (which as some shared commands with X and/or Y) you suppress any command that is in X or Y and only insert those that are not shared with them. This process is repeated with each component so that any command that is used by more than one component is flagged to show every component it is used by and thus can be excluded if any component that shares the commend has already been processed. IOW: Not ordering Component Y but testing in the order X/Y/Z will insert the shared Y and Z commands as part of the Z processing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: XRC (z/OS Global Mirroring)
Nine years ago, HDS supported IBM's XRC with their version of it called HRC (or was it TrueCopy). Not sure if the current Global Mirror code has broken that compatibility or not. Ron H., feel free to chime in here. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Patti McLeskey Sent: Tuesday, April 24, 2012 5:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: XRC (z/OS Global Mirroring) Undecided yet on which storage vendor will be used. Currently using vendor-specific replication which requires us to migrate the replication scripts if/when the vendor is changed. Just trying to understand if XRC/GM is portable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Jobid on SDSF PS panel ?
Miklos, Type ARRANGE and see if it has a / in front of it. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Friday, April 20, 2012 6:38 AM To: IBM-MAIN@bama.ua.edu Subject: Jobid on SDSF PS panel ? Hi Can't find the JOBID field on the SDSF PS panel (nor via REXX) . Do I lost it or I need to customize ? (z/OS 1.12 missing but I have it on 1.13) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Jobid on SDSF PS panel ?
Replying to my own post. I forgot a step. On the action bar, pull down VIEW and select 2 (Arrange). Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Friday, April 20, 2012 6:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Jobid on SDSF PS panel ? Miklos, Type ARRANGE and see if it has a / in front of it. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Friday, April 20, 2012 6:38 AM To: IBM-MAIN@bama.ua.edu Subject: Jobid on SDSF PS panel ? Hi Can't find the JOBID field on the SDSF PS panel (nor via REXX) . Do I lost it or I need to customize ? (z/OS 1.12 missing but I have it on 1.13) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Jobid on SDSF PS panel ?
Wow!! I need more coffee before I reply to anything more today. Forget both of my posts. I missed the PS part and interpreted the ARRANGE / option wrong! I apologize for wasting everyone's time. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Friday, April 20, 2012 7:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Jobid on SDSF PS panel ? Hi Thank you Bob, with ARRANGE ? I don't see it at all, but I don't see the JOBNAME either On 4/20/2012 12:59 PM, Richards, Robert B. wrote: Replying to my own post. I forgot a step. On the action bar, pull down VIEW and select 2 (Arrange). Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Friday, April 20, 2012 6:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Jobid on SDSF PS panel ? Miklos, Type ARRANGE and see if it has a / in front of it. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Friday, April 20, 2012 6:38 AM To: IBM-MAIN@bama.ua.edu Subject: Jobid on SDSF PS panel ? Hi Can't find the JOBID field on the SDSF PS panel (nor via REXX) . Do I lost it or I need to customize ? (z/OS 1.12 missing but I have it on 1.13) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enhanced HOLDDATA
John, I had thought that, but when I ran an errsysmods report against CICS for the first time and got no hits, I thought perhaps there may have been a separate HOLDDATA file. Thank you for clearing that up. I'll look elsewhere, unless someone can tell me they get the same result as below: EXCEPTION SYSMOD REPORT FOR ZONE CICT410 HOLD SYSMOD APAR ---RESOLVING SYSMOD HOLDHOLD FMID NAME NUMBERNAMESTATUS RECEIVED CLASS SYMPTOMS ***NONE Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Eells Sent: Tuesday, April 10, 2012 1:42 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Enhanced HOLDDATA Richards, Robert B. wrote: Can someone provide me with the CICS equivalent to z/OS for SMPE/FTP syntax for retrieving enhanced HOLDDATA? snip I'm not sure I understand the question. You get it for z/OS and CICS the same way. The same HOLDDATA file, from the same source, covers the entire z/OS platform's worth of SMP/E-installed products, including CICS. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enhanced HOLDDATA
John, No, it has its own Global CSI, two targets: CICS TS 4.1 (CICST410) and CICS VSAM Recovery (CVRT430), and their associated DLIB zones. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Eells Sent: Wednesday, April 11, 2012 7:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Enhanced HOLDDATA Richards, Robert B. wrote: John, I had thought that, but when I ran an errsysmods report against CICS for the first time and got no hits, I thought perhaps there may have been a separate HOLDDATA file. Thank you for clearing that up. I'll look elsewhere, unless someone can tell me they get the same result as below: EXCEPTION SYSMOD REPORT FOR ZONE CICT410 HOLD SYSMOD APAR ---RESOLVING SYSMOD HOLDHOLD FMID NAME NUMBERNAMESTATUS RECEIVED CLASS SYMPTOMS ***NONE H...is CICS in the same Global zone as z/OS? -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enhanced HOLDDATA
Ding, ding, dingwe have a winner (and a doh expression on my face). It certainly helps if one actually loads the HOLDDATA into the zone before trying to report on it! Thank you, Kurt, for figuring out my stupidity. Humbly yours, Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kurt Quackenbush Sent: Wednesday, April 11, 2012 8:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Enhanced HOLDDATA Did any HOLDDATA get received into that global zone? Check out the RECEIVE ++HOLD/++RELEASE SUMMARY Report (maybe written to SMPHRPT in case you can't find it). Or, is it possible you have no unresolved HOLDs in the CICT410 target zone? Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Enhanced HOLDDATA
Can someone provide me with the CICS equivalent to z/OS for SMPE/FTP syntax for retrieving enhanced HOLDDATA? Bob - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.govmailto:robert.richa...@opm.gov - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A deep question about VSAM SHR(4) - can you help?
At 07:16 -0700 on 04/05/2012, Mike Kovach wrote about A deep question about VSAM SHR(4) - can you help?: I have a VSAM KSDS CLUSTER which is written to by ONLY ONE PROGRAM in ONLY ONE CICS REGION. Currently, this file is defined in CICS with STRNO(1). The file is defined with SHR(4,3) because while being written ONLY in CICS, it is being read by a non-reentrent ASSEMBLER program running in BATCH. SHR 4 forces VSAM to harden each I/O (yeah, I know!) so the BATCH gets the current information. Please spare me all the comments about how poor this solution is as it stands. It has been in place for decades and due to a myriad of reasons, the philosophy CANNOT change. My specific question is this: I want to introduce multi tasking so that 5 copies of the program can update the file concurrently. If we change STRNO(1) to STRNO(5) on the CICS FCT Definition, will VSAM be smart enough to manage the writes to the file so we don't break it and the BATCH still gets the current information? So long as you are still using one CICS Region, I do not think you will run into problems. The STRNO(5) will allow you to have 5 CIs being updated at a time (one CI per copy of the program). If more than one copy attempts to access records from the same CI, it should cause the subsequent requesters to wait for the owning copy to finish its update and release/write the CI (just make sure that all your VSAM is being done by SubTasks which I think CICS does automatically). You should increase the number of buffers so there are enough for all the copies. I am interested in any discussion you might share, but I am most interested in a specific reference to a reliable document. Please help. Thanks Mike Kovach -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A deep question about VSAM SHR(4) - can you help?
At 18:16 -0500 on 04/05/2012, Walt Farrell wrote about Re: A deep question about VSAM SHR(4) - can you help?: This option requires that the user's program use ENQ/DEQ to maintain data integrity while sharing the data set, including the OPEN and CLOSE processing. User programs that ignore the write integrity guidelines can cause VSAM program checks, lost or inaccessible records, uncorrectable data set failures, and other unpredictable results. This option places responsibility on each user sharing the data set. /quote So unless there's something in CICS issuing appropriate ENQ/DEQ macros, I think you'll need to make some program changes. You are misreading the restrictions. This has to do with sharing the VSAM Cluster between multiple programs NOT sharing the Cluster between multiple tasks of the same program (as would be the case with CICS). You are using ONE ACB so there is no interlock issue. I am not sure what QNAME/RNAME is supposed to be used for the interlock. VSAM itself does the ENQ/DEQ (I think) via using the CI number (it can not be the key of the record because while that would prevent multiple updates to that record, you can mess up the CI if there are two records in the CI being updated) as part of the RNAME (it has been a while). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VSAM help wanted for random reads
At 16:33 -0700 on 04/03/2012, Frank Swarbrick wrote about Re: VSAM help wanted for random reads: The idea of putting the record type at the end rather than the beginning is an interesting idea.Ý Unless there's some way of doing that without having to change any programs I don't think we'd want to take the time.Ý However I am interested enough to try it with this one program and see what effect it has. Create an AIX pointing at the file with the AIX key being the account number followed by the record type. Change the update program's logic to access and update the AIX not the BASE File. All other programs access the BASE file as at present. Note that this requires you to look for ACCOUNT-NUMBER suffixed by 4 and look for equal-to or greater (ie: Accept the type 5 if it gets returned due to no type 4). Also you need to check the returned account number in case there is no 4 or 5 for the account number. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless solution (IBM or Sun) Enterprise class
Tommy, It is NOT true. Different shops have different requirements. We are also migrating from a B20 to a 7740 Grid solution in support of high availability, continuous operation and disaster recovery needs. One size, or in this case, one solution, does not fit all. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, March 28, 2012 7:16 AM To: IBM-MAIN@bama.ua.edu Subject: Tapeless solution (IBM or Sun) Enterprise class Hi ALL, Our shop currently using VTS B20, and planning to either migrate the 7740 (no migration need) or migrate to tapeless 7720 or Sun storageTek VSM tapeless solution. Any shop using 7740 or 7720 or storageTek tapeless solution. In market, I think all customer will use tapeless soultion instead of IBM 7740. Is it TRUE? Any comment will be appreciated. Many thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/os every two years
September 2013, but not officially announced. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Wednesday, March 28, 2012 7:35 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/os every two years Does anyone know when zOS 1.12 will go out of support? I was planning to go to zOS 1.14 from 1.12, but seeing this new release schedule might make me reassess my plan. Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless solution (IBM or Sun) Enterprise class
Add Tivoli Tape Optimizer to your list of migration utilities. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, March 28, 2012 7:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Tapeless solution (IBM or Sun) Enterprise class What I concerns are: 1. Tape still have life time, if 1TB tape damage then we need more time to re-built or re-create it, except you implement dual copy or PPRC VTS and it cost you more. 2. Tape migration is my concern, I think disk to disk migration is more faster solution. I can't find any migration approach for B20 to TS7740 or TS7740 to another new model, except using COPYCAT or TAPECOPY utility, read all tapes to cache and copy back to other tape subsystem 3. IBM Tape drives cannot read each other, TS1120, TS1130, TS1140...If a new model comes and we need to preform another migrationcopy again and again from tape to another tape system because of new drives.TRUE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leaving IBM
Walt, Best wishes for a healthy and enjoyable retirement! Have fun for me, as retirement is still a pipe dream for me. Your daily contributions to all sorts of discussions will be sorely missed by all! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Walt Farrell Sent: Monday, March 26, 2012 9:53 AM To: IBM-MAIN@bama.ua.edu Subject: Leaving IBM I mentioned this over on RACF-L the other day, so for some of you this will be old news. I've been an IBMer for 28 years and have had a lot of fun with RACF and MVS, and I've had a lot of fun interacting with you folks on RACF-L and IBM-MAIN. But the time has come for me to retire and have fun with other things. I've enjoyed the discussions here, and working with many of you to plan enhancements or resolve problems. I'm sure I'll still read both lists for awhile, and probably even participate from a personal email address. But after Wednesday morning I will no longer be an active IBM employee and I'll speak about z/OS and RACF even less officially than than I do now. It's been a great 28 years, but my family and other activities are calling to me more and more strongly, and it's time to spend more time with them. Best wishes to you all, Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Friday fun: Halon dumps and POK Resets
All: * It is possible to disconnect the vacuum duct to a 3420 tape drive. * It is also possible to connect a condom on the supply-side duct. * It is also possible to press LOAD. * It is also possible to put the Lead Operator on the floor convulsed in laughter. -- Robert W. Shimizu Partner ColeSoft Marketing, Inc bshim...@colesoft.com www.colesoft.com (800) 932-5150 (928) 771-2005 Fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: UNABLE TO DELETE DUPLICTE DSN
At 06:24 -0700 on 03/22/2012, John Dawes wrote about UNABLE TO DELETE DUPLICTE DSN: G'Day I am trying to delete a duplicate dsn via TSO. Since the cataloged version which resides on volume MPR003 is in use, I thought that I could rename the duplicate dsn which resides on MPR027. However when I try to rename the dsn (via TSO) it gave me the message Duplicate data set name followed by Data set is cataloged on a volume other than MPR027. Both volumes are managed by SMS. Is there some other tactic I could employ? Thanks. Since the problem is that the DSN Name is enqueued upon (which is pointing at another dataset with the same name) you need to rename the dataset you want to delete (so it is not a duplicate of a dataset with a current ENQ). One way to do this is to use SUPERZAP to edit the VTOC entry to alter the dataset name. Once this is done you can then do the delete. This may leave a orphan record in the VTOCIX which may cause errors in the future if you try to allocate the dataset name on that volume in the future (I do not know). There may be some RACF issues to be allowed to run the SUPERZAP which might need to be looked into. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SMPE Internet Service Retrieval
We are finally being allowed to use Internet Service Retrieval for downloading our software and service, and I have a general question to those who have been using it. I have done several downloads of Shopz orders using RECEIVE FROMNETWORK, and I notice that it is very slow. An order of about 770 MB in size took two hours to download. If I had downloaded it to my laptop using Download Director, it would have taken less than 10 minutes, and the upload to the mainframe would have been just as quick. I can't get the network group to look at it, and I don't know what routers, firewalls, etc are involved in this. My question is: is Internet Service Retrieval this slow for everybody? Thanks -- Bob Heffner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Endevor(Change Management Software)
Our firm used to offer CA-Endevor consulting services, and the former lead of our CA-Endevor practice implemented change control over system libraries at a her former employer, an insurance firm as I recall. There was the expected initial resistance by the systems staff, but once they got used to it, I understand they grew to like the ability to report on the details of changes and easily back them out. Contact me off-list if you'd like me to try to put you in touch with this person. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -Original Message- Date:Wed, 14 Mar 2012 12:29:05 -0500 From:gsg gsg_...@yahoo.com Subject: Endevor(Change Management Software) Is anyone out there using CA-Endevor? Do you manage your system changes using Endevor? If so, how are you doing this and was it hard to setup? We are looking into this, but there are so many system libraries that could be changed, it needs a lot of thought to get it right. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
Another item worth mentioning, when z/OS changes the time based on an STP change, the message IEA392I is issued. If you have an automation package, you could rite automation that would catch this message and reset the time in CICS. IEA392I description: One or more of the time offset values has changed. These include leap seconds, local time, and daylight savings time offsets. Along these lines, I heard that some Omegamon tasks wanted a time reset command also. The tasks appear to be mostly Omegamon II. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Norgauer Sent: Monday, March 12, 2012 6:50 PM To: IBM-MAIN@bama.ua.edu Subject: Server time Protocol and CICS This weekend we had our mainframe time automatically adjusted to Day Light Time using S.T.P.. However, CICS did not get the time changed automatically. Is CICS still unable to do this(have the time changed automatically)? John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
At 14:41 -0500 on 03/13/2012, John Gilmore wrote about Leap seconds and the Server Timer Protocol: This is the title of a new this month IBM Techdocs White Paper, WP101091, by Gregory Hutchison, a PDF of which can be downloaded from the IBM Techdocs website. What is the URL of the site? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VTAMLST - Who needs to read it
Chris, When IBM suggests UACC(NONE) for a system dataset, this is usually an indicator the dataset contains security control information that should be kept secret. In this particular case, it may have to do with options such as the ability to specify clear text passwords with PRTCT= on VTAM APPL definitions. Whereas the RACF team at IBM may not always provide detailed information about why they made a particular suggestion, I have always found them to be very thoughtful and never arbitrary. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com - 2012 RACF Training - Audit for Results - Boston - APR 24-26 - Intro Basic Admin - Boston - MAY 8-10 - -Original Message- Date:Fri, 9 Mar 2012 12:03:03 -0600 From:Chris Mason chrisma...@belgacom.net Subject: Re: VTAMLST - Who needs to read it Juan IBM suggests UACC(NONE) for them (RACF Security Administrator Guide, apendix D- Security for system datasets). Why should the RACF developers be the arbiters of what is the correct access policy for VTAMLST? I would say that they were as likely to get such a proposal correct as any other development shop commenting on the products of another development shop. In other words, they are very, very likely to get it quite wrong - a phenomenon I have observed time and again! Indeed, I have sometimes been very pleasantly surprised when a manual written by one development shop happened to come up with a clear explanation of how to use products from another development shop. Actually the only case I can remember over many years is GDDM talking about the 3270 data stream. (RACF Security Administrator Guide, apendix D- Security for system datasets) Please - and this applies to all posters - provide an URL when referring to something state in a manual. I suggest you post this query on the RACF-L list and challenge the gurus I notice there are not backward in coming forward and see if any of them can provide a reasoned argument why the following recommendation - which I dug out! - is present: quote D.0 Appendix D. Security for system data sets Table 48. UACC values for system data sets Data set/UACC/Comments ... SYS1.VTAMLST/NONE/ ... /quote http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza7c0/D.0 Note that the people responsible for this table couldn't even imagine any justifying comment to add. I suspect they had wet fingers in the air! If the RACF-L gurus cannot provide a reasoned argument, I suggest you treat this recommendation with the pinch of salt which in my opinion it deserves. Remember There is no substitute for understanding what you are doing., a maxim that isn't necessarily ingrained on the conscience of IBM developers! - Anyhow the users who need to access VTAMLST are obviously the user of the VTAM/NET address space and any system programmer's TSO address space where the system programmer is responsible for maintaining the VTAMLST partitioned data set. I cannot see any reason why a user of the VTAM API would require access to VTAMLST for the reason that he/she was using the VTAM API. - Incidentally, while you are challenging the RACF-L gurus over access to VTAMLST, you might care equally to challenge them over the recommendation to specify universal access of READ for the VTAMLIB partitioned data set where, again, the comment field is completely absent in the now famous table. Again, I suspect a wet finger! - Moreover, take a look at the comments where the authors bothered to add comments and note whether there appear to have been any guidance other than common sense and - it must be said - note the considerable equivocation! - Chris Mason On Fri, 9 Mar 2012 09:00:34 -0800, Juan Mautalen jgmauta...@yahoo.com.ar wrote: Hi: We currently have our VTAMLST libraries protected with UACC(READ). IBM suggests UACC(NONE) for them (RACF Security Administrator Guide, apendix D- Security for system datasets) . I want to make the change, but of course i know i must be extremely carefull with this change. I need to detect all users needing read access to VTAMLST. Human users are not my problem, my worry is about non-human ones (users of system tasks, started tasks, etc.). What users need read access of VTAMLST? Does any userid associated with a VTAM application need to read VTAMLST? Thanks in advance for your help, Juan Mautalen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu
Re: Return code = X'14' from ATTACH JSTCB=YES
At 21:10 -0500 on 03/05/2012, Shmuel Metz (Seymour J.) wrote about Re: Return code = X'14' from ATTACH JSTCB=YES: In 00cc01ccfa4e$3293ec90$97bbc5b0$@net, on 03/04/2012 at 04:31 PM, Micheal Butz michealb...@optonline.net said: Does this mean that only the initiator can issue a ATTACH JSTCB=YES No. It means that only a JS task with no subtasks can issue a ATTACH JSTCB=YES. Are you sure? I thought it was just being a JS task that allows use of ATTACH JSTCB=YES not the lack of that task having Subtasks. While a subtask can not use this parm, that should not preclude the original JS task (or one that it attached with the parm) from attaching additional JS tasks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Customer Service, the good and the bad...
Hi, I hope this doesn't offend anyone, but here's a short story about customer service... Once, in a very grey past, I bought a copy of OS/2, and with it came a card that entitled me to two years worth of free updates. I duly send it back to IBM and it was met with silence. Eventually, just a few short months before the end of the two-year period, I called IBM. First IBM UK, who turned out to be clueless, and then IBM in the US. I was handed from one clueless person to the next, until, after about half a dozen not very cheap calls across the pond I had enough. I wrote a letter, and I wrote it directly to the big boss, Sam Palmisano. Just a few days(!) later I got a call from an executive assistant of the CEO of IBM UK, asking me to explain what had happened. I did do so, I think I even send her a scanned copy of my Proof of entitlement. She told me that she would (try to) sort things out. Another few days passed, and then I got a call from someone in the US. I told him the same story, he apologized and told me that he would do his best to help me and lo and behold, about three weeks later the postman knocked on the door and handed me a (huge for the contents) box with all updates for OS/2 that had been made available over those last two years. Another example of IBM listening to its customers? Take a look at page 381 (PDF: 466) of the PL/I V4R2 Programming guide, http://publibfp.boulder.ibm.com/epubs/pdf/i1191451.pdf One of the paragraphs on that page reads: quote If you do have code that uses BASED structures with REFER and which the compiler flags with this message, you may be able to get better performance by passing the structure to a subroutine that declares a corresponding structure with * extents. This will cause the structure to be mapped once at the CALL statement, but there will no further remappings when it is accessed in the called subroutine. /quote I still have the email to Peter Elderon in which I suggested he might want to add the above, as using this trick can save enormous amounts of CPU time. (It's now slightly less required due to the generation, provided some restrictions are met, of in-line of code to access such structures) In fact since 2006 sent reports of many bugs in PL/I directly to Peter Elderon and he not only acknowledged them, but also fixed them, despite the fact that I never followed official rules for the submission of APARs... Bravo, IBM! Now, I've had similar experiences with Virgin Mobile - called their customer service about a billing problem and for weeks I was shifted around endlessly between clueless idiots. In this case the problem was solved within days by writing a letter to Sir Richard Branson. Bravo, Virgin! I can give more examples of great customer service, but how about a company that really doesn't seem to care? In February 2004 I bought an HP Pavilion PC. It wasn't cheap, but it was one of the first from a mainline manufacturer to come with an Athlon 64. About 15 months later, out of warranty, it suddenly died. I wrote to HP UK, but Sorry you will have to pay to get it repaired. Fortunately, just about a week later someone offered an equivalent motherboard on eBay (by that time a local PC guy had determined that the problem could only be the motherboard), for about one fifth of the HP repair cost. Bought it, and the PC worked again, for just over a year or so. Then some capacitors popped their tops. Got another mobo from eBay, and the same thing happened again, twice. Re-capped the last mobo, only to see more capacitors pop, the last time in October last year. Fed up, and without being able to get a replacement from eBay, I wrote a letter to HP's new CEO, Meg Whitman. Result: Zilch, noppes, rien du tout. I've never had a reply. Some Googling about popped capacitors turned out hundreds of hits, and there seemed to be a genuine problem with industrial espionage gone awry in the early 2000's, according to one website DELL spent around USD 300 million to recall and replace motherboards. Needlessly to say, when I bought a new PC for myself at the beginning of this year, and a new notebook for my wife, I stayed away as far as possible from HP. I don't know if my experience was an exception, but even if it was, that is no way to treat your customers! HP, you suck, and if anyone connected to HP reads this, please tell your big boss to have a look at this, http://www.joelonsoftware.com/articles/customerservice.html and maybe start treating your customers like they should be treated! -- Robert AH Prins robert.ah.pr...@gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: User datasets wrongly catalogued under Master Catalogue
At 13:24 +0530 on 02/29/2012, Jake anderson wrote about Re: Fwd: User datasets wrongly catalogued under Master Cata: Robert, I am unable to find any Information on MIGRATECAT on google search.. Is there someone who can point me to some Fine manuals relating to MIGRATCAT? Jake OOPS - As Dave Gibney responded the command I was thinking of is MERGECAT. I mistyped/misremembered the command name but had the right idea. I did however add the or something like that caveat to cover the wrong name case. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: User datasets wrongly catalogued under Master Catalogue
At 09:11 +0530 on 02/29/2012, Jake anderson wrote about User datasets wrongly catalogued under Master Catalogue: Hi, Recently We have installed a new system Z/OS 1.13. During migration the Users datasets were restored and unfortunately all the user datasets are catalogued under Master catalogue. I agree that this happens when a userid is defined with alias relating to user catalog. I am just trying to understand if it is possible to move all the users dataset catalogued under master catalogue to a user catalogue since the Number of datasets are in big number. Jake I seem to have an impression that there is a command called MIGRATECAT (or something like that) which will move the catalog entries from one catalog to another. If you follow that by a define of the alias you should get your desired result). Assuming that I am correct the only Gotcha is if the command will accept a From Here On wild card (ie: HLQ.* means ALL Datasets and Clusters under HLQ no matter how many levels). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JES2 OFFLOAD - requesting help, ideas, etc.
At 15:55 -0500 on 02/23/2012, Tony Harminc wrote about Re: JES2 OFFLOAD - requesting help, ideas, etc.: The latter is what would result from using my catalogued tape dataset suggestion, if it works at all. There would be multiple, unrelated offload datasets that just happen to be on the same physical volume. Presumably you would have to invent a naming scheme so that you would unload to (and potentially reload from) the right places. I also gather that JES2 supports a max of only 8 offload devices, but it looks as though you can dynamically change the dsname, so perhaps you could stick with one device and update the name for each day. Make the dataset name a GDG and make use it on one of the devices (the one you will use to read the tape back in) - Code as DSN(0). Output to another tape/file with DSN OFFLOAD(+!) and then do a copy of the DSN(0) concatenated with OFFLOAD(0) (or OFFLOAD.GV00 where is a parm which you enter based on the last version that JES created if it does not do the catalog for you upon CLOSE) to create DSN(+1). Since you are creating a new File each day by merging you do not run the risk of destroying the old dataset by doing a DISP=MOD Append. Of JES does not update the catalog correctly then you can always just do the merge from 2 NON-GDG datasets and if you need to read back in copy the current GDG from input into JES. As has been stated the max number is 999,999 so you will not run out of numbers for a while and can trim them off the tape while doing the dupe/copy. Something I'm not clear on is whether you routinely reload this data, or of it's just for backup. Any scheme that involves appending to tape has higher risk and to more data than one that writes to a unique tape for each day (or other unit of work). Since the offload does PURGE this has to be an archive with no actual printing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic allocation in JCL (Was: Physical record size qu: The gotcha used to be that if you grossly over-requested space, got space dispersed over umpteen volumes, only used a little of the space, that RLSE would then only release the unused space on the last volume actually written and leave all the unneeded, unused space on subsequent volumes allocated until the data set was deleted. This could be fixed by defining a RLSEALL parm (which would not only release the unused space on the last used volume but also release all the extra volumes). This could be in the JCL or better SMS (since SMS is doing the allocation in the first place). I regard this failure as a Design Flaw AKA Bug. Query - If I have a multi-volume existent dataset that I allocate as DISP=OLD and open as output (thus rewriting from the start) which has SPACE coded as RLSE does it release the space on volumes past the one that was used or also just the unused extents on the last written volume? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
At 14:07 -0500 on 02/17/2012, Shmuel Metz (Seymour J.) wrote about Re: Archaic allocation in JCL (Was: Physical record size qu: In CAPD5F5rThXaYbF32YgQMXK0bWTtXELh3X+XMOaUnKwPv=tt...@mail.gmail.com, on 02/17/2012 at 12:50 PM, John Gilmore johnwgilmore0...@gmail.com said: is not really wrongheaded. It is an unfortunate oversimplification for real DASD. Not if you were only discussing conversion of the SPACE parameter. I agree that carrying over BLKSIZE from generation to generation is ghastly, albeit far too common. I agree. OTOH: There are programs that were converted from DOS to MVS (or were written by ex-DOS programmers) which have hard coded Blocksizes instead of letting the dataset define them. Thus they stay constant no matter what device you use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
At 13:12 -0500 on 02/16/2012, Shmuel Metz (Seymour J.) wrote about Re: 5 Byte Device Addresses?: In 77142d37c0c3c34da0d7b1da7d7ca346c...@nwt-s-mbx1.rocketsoftware.com, on 02/16/2012 at 02:14 PM, Bill Fairchild bfairch...@rocketsoftware.com said: But that's ok, since I still call z/OS by the name MVS. Is that not the official name of the BCP in z/OS? At least I don't still call it OS/VS2 Release 2. Well, it isn't. Program product versions of MVS haven't installed on top of the free base for decades, and before then the release number had climbed to 3.8. No Bill is right. OS/VS2 Release 2 WAS MVS like OS/VS2 Release 1 was SVS. SVS was OS/360 MVT with Virtual Addresses (SVS was a single 16MB Address Space with which was divided into smaller areas for the programs to use, just like MVT). MVS made the program's area into duplicate address ranges which sat between and shared the low and high address ranges which belonged to the Operating System. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
On this DISPLAY of IPLINFO, the first position is the channel set, the last four the device address. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Tuesday, February 14, 2012 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 5 Byte Device Addresses? W dniu 2012-02-14 14:06, Dan D pisze: I'm wondering when 5 byte UCBs came into service and where this data comes from. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? D IPLINFO IEE254I 18.36.23 IPLINFO DISPLAY SYSTEM IPLED AT 17.34.39 ON 01/10/2012 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD00 IN SYS1.IPLPARM ON 02020 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 00 IEASYS LIST = (00,01) (OP) IODF DEVICE: ORIGINAL(02020) CURRENT(02020) IPL DEVICE: ORIGINAL(03100) CURRENT(03100) VOLUME(SCARS1) I've looked at the IEE254I message in the doc but it just says... The device number of the volume where the I/O configuration ... The D U command still only shows 4 bytes. Any ideas? 1. 5-byte device address can be misunderstood. There is no simple support for 5-byte addresses, the fifth byte have to be zero for most devices. Also, in many places you can use only 4-byte (or 0) addresses. 2. Subchannel Set 1 was introduced in z9 (2094) and AFAIR z/OS 1.7. 3. Support for 5-byte adresses is growing up constantly, for example at the time of z9 and z/OS 1.7 there was no possibility to IPL from 1 devices, there was no SS2, the only supported devices in SS1 were aliases. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend S0C4 in an internal sort
At 22:25 -0500 on 02/13/2012, Shmuel Metz (Seymour J.) wrote about Re: Abend S0C4 in an internal sort: Does the sort expect a non-standard plist? Should the 4rh word be A(=F'-1')+X'8000'? That +X'8000' is not needed (and can cause problems) since F'-1' has set the high bit already - F'-1 = X''. I think that it has been determined that if you want RMODE ANY, the exit addresses need to have the +X'8000' added (or go with RMODE 24). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
At 21:34 -0500 on 01/31/2012, Scott Ford wrote about Re: Intrdr: Liz, There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Try this: 1) Submit the Job 2) ENQ EXC TYPE=TEST on the dataset name. The RC will tell you if the job started yet. 3) Once you know it is running, do an ENQ SHR which will put you into a WAIT until the job ends. 4) SVC 99 allocate the dataset and run. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
At 20:47 -0500 on 01/31/2012, Lizette Koehler wrote about Re: Intrdr: Or you could add a last step to the job that sends a TSO SEND command to notify you. Or put NOTIFY= on the JOB CARD. Note: The Last Step method requires a COND=EVEN on its EXEC statement to insure that it runs even if a prior step ABENDs (and causes the rest of the steps to flush). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: different tape media for ML2 copies in HSM
At 07:39 -0600 on 01/27/2012, Staller, Allan wrote about Re: different tape media for ML2 copies in HSM: Look up the TAPECOPY command in the dfSMS/hsm Storage Admin Guide.. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S680/2.40 ?SHELF=DGT2BK90DT=20090610113354 HTH, snip Currently we are creating duplex tape copies for ML2 in HSM. We are using logical tape (VTS), and we used to use Export to get the second copies offsite. However, 2 years ago we stopped all Export/Import functions, and now have the two copies always in the library(which is bad). My job now, is to find a way to be able to send the second copy offsite by using native 3590 tape. I was researching, and I am 99% sure that I cannot use different media - logical tape for onsite and native 3590 for offsite - for the ML2 tapes. I was told to turn the 99% into 100%. So here is my question: Is there any way to use different media for the two ML2 tapes? A patch maybe? Logically thinking, since the 3590 is larger we would never have issues with filling up the second tape, but then have partial filled 3590 tapes offsite. I wonder if parameters like the TAPEUTILIZATION and the RECYCLEPERCENT are the reason why we can't mix the media. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Just to play Devil's Advocate here - What the OP asked for was a way to create two ML2 tapes on different media at the time of the creation of the ML2 tapes/files. No one has addressed this requirement and said it is not possible. All the responses/solutions are offering two step means of getting the same result. First create the ML2 files/tapes and THEN copy one to physical 3590 volumes. IOW: None of the solutions create the ML2 tape but only copy one that has already been created to make a physical duplicate for transfer offsite. I know that the ultimate result is the same (so long as there is some way of telling HSM about the volumes) but I just wanted to point out the omission in the responses (ie: Jumping directly to another solution without noting that the original requested method is not possible). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Set Clock Command
At 15:49 -0500 on 11/21/2011, Blaicher, Christopher Y. wrote about Re: Set Clock Command: It depends on your applications and how they are written. If they use the TIME macro, or the various language equivalents, you may have a problem at switch times. See the ZONE parameter of the TIME macro. During the transition in the Spring, you can have a few transactions that look like they ran an hour longer than they did. In the Fall you can have transactions that look like they end before they begin. This is only because the programs use local time as opposed to UTC/GMT. With a program using GMT there is no issue. If you want to use Local time, just add EST/EDT (or your local time zone) to the printouts. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Looking for Decompiler
Folks: It's rare that I have anything to offer this august assemblage, but I do happen to know about the Source Recovery Company. They can do what you ask, and they do it well. http://www.source-recovery.com/ Cheers, Bob Shimizu ColeSoft Marketing, Inc. On 1/18/12 8:42 PM, jagadishan perumal wrote: Hello All, I am looking for a decompiler, reverse compiler, dissasembler of cobol LOAD modules into cobol SOURCE modules for lost programs. Could any please direct me to some Site or Freebies or specific Products which Can perform the reverse compilation. Jags -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Robert W. Shimizu Partner ColeSoft Marketing, Inc bshim...@colesoft.com www.colesoft.com (800) 932-5150 (928) 771-2005 Fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ITIL Mainframe Terminology
I, too, got certified (or, according to some, certifiable) at the foundation level. The mainframe could be a configuration item (CI) and should probably just be classified as a server. CI specification varies from company to company. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jonathan Goossen Sent: Wednesday, January 11, 2012 2:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ITIL Mainframe Terminology Peter, You are correct in what ITIL stands for. The British started it. It migrated to the US when companies wanted to cut costs. Several years ago I was required to go through training and passed my certification for the first level. ITIL is a collection of best practices for running a company's IT. It deals with processes and is equipment independent. ITIL doesn't have terminology for mainframes. Thank you and have a Terrific day! Jonathan Goossen, ACG, CL Tape Specialist ACT Mainframe Storage Group Personal: 651-361-4541 Department Support Line: 651-361- For help with communication and leadership skills checkout Woodwinds Toastmasters -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
GRSRNL00 question
Silly question where I know I can get a fast answer here: If I code: RNLDEF RNL(CON) TYPE(PATTERN) QNAME(*) Does that mean that I should delete all other RNL(CON) statements from the member? The Ministry of Silly Questions thanks you in advance for your replies! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GRSRNL00 question
Thank you Matthew and Bobbie! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Matthew Stitt Sent: Thursday, January 12, 2012 11:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GRSRNL00 question That's what I did. No ill effects, and it got rid of the Health Check nag. Silly question where I know I can get a fast answer here: If I code: RNLDEF RNL(CON) TYPE(PATTERN) QNAME(*) Does that mean that I should delete all other RNL(CON) statements from the member? The Ministry of Silly Questions thanks you in advance for your replies! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Peculiar issue related to TSO logons
Mark, Thanks for the clue about scripted logons. I'll check with my SAS Connect folks. Two more showed up after the cleanup. I'll also test the other suggestions. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mark Zelden Sent: Tuesday, January 10, 2012 5:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Peculiar issue related to TSO logons On Tue, 10 Jan 2012 15:30:45 -0600, Tom Marchant m42tom-ibmm...@yahoo.com wrote: Why was it so important to get rid of these? It took me a while to remember, but I'm pretty sure the last time I saw this was due to a problem with SAS connect or a SAS connect application, which basically is a scripted logon to TSO. I hope I'm remembering this right, but if not, it was the same concept - a scripted logon. At the time, it was important to get rid of them because enough of them were failing and preventing other users from getting on that needed to due to MAXUSERs getting hit or VTAM APPLs that were defined. Of course those things could be changed dynamically, but whatever it was creating them at the time was doing so quickly. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Peculiar issue related to TSO logons
Tom, You and Tony are right about the one I had to force. It could have stayed out there. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Marchant Sent: Tuesday, January 10, 2012 4:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Peculiar issue related to TSO logons On Tue, 10 Jan 2012 16:03:30 -0500, Tony Harminc wrote: On 10 January 2012 10:33, Richards, Robert B. robert.richa...@opm.gov wrote: Rex, Thank you. I got rid of all but one using your suggestion. That last one was a FORCE U=*LOGON*,a=?? I would think the risks of issuing a FORCE to be much higher than those of leaving the STARTING TSU sitting there... Right. The address space is created when LOGON is issued. At that time, there is no user ID, so it shows as STARTING. Why was it so important to get rid of these? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Peculiar issue related to TSO logons
Hal, I am able to reproduce the STARTING status as you described using HOD and PCOMM. But as soon as I closed the emulators, those sessions went away too. The plot thickens... Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hal Merritt Sent: Tuesday, January 10, 2012 2:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Peculiar issue related to TSO logons I've heard rumors of some multi session emulators hanging a LOGON but never responding to the prompt. I've also seen this with old VTAM terminals (issue a LOGON command, but then just walk away). To reproduce: open any TN3270 emulator, and issue a LOGON command. Don't respond, just shrink the window and then ignore it. HTH and good luck. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Peculiar issue related to TSO logons
Has anyone ever seen this before on a SDSF DA display? STARTING TSU LO FF 99 0.00 0.00 75 004B 13 0.00 DWSYSB STARTING TSU LO FF 92 0.00 0.00 87 0057 11 0.00 DWSYSC STARTING TSU LO FF 92 0.00 0.00 92 005C 18 0.00 DWSYSC STARTING TSU LO FF 93 0.00 0.00 88 0058 12 0.00 DWSYSA They do not go away on their own and they are a bear to get rid of. I did not get any hits on IBMLINK. 25 of these suckers and climbing. D A,L shows them as *LOGON*, but I haven't found the right syntax to cancel or force them yet. - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.govmailto:robert.richa...@opm.gov - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Peculiar issue related to TSO logons
Rex, Thank you. I got rid of all but one using your suggestion. That last one was a FORCE U=*LOGON*,a=?? Bob Shannon, nothing of unusual significance showed up on D GRS,C. Your latter comment is under consideration though. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Tuesday, January 10, 2012 10:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Peculiar issue related to TSO logons You got a logon proc issue where people aren't getting logged on - or an enqueue on a critical dataset preventing logon completions? To get rid of them use c u=*logon*,a=?? where ?? is their asid HTH Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Tuesday, January 10, 2012 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Peculiar issue related to TSO logons Has anyone ever seen this before on a SDSF DA display? STARTING TSU LO FF 99 0.00 0.00 75 004B 13 0.00 DWSYSB STARTING TSU LO FF 92 0.00 0.00 87 0057 11 0.00 DWSYSC STARTING TSU LO FF 92 0.00 0.00 92 005C 18 0.00 DWSYSC STARTING TSU LO FF 93 0.00 0.00 88 0058 12 0.00 DWSYSA They do not go away on their own and they are a bear to get rid of. I did not get any hits on IBMLINK. 25 of these suckers and climbing. D A,L shows them as *LOGON*, but I haven't found the right syntax to cancel or force them yet. - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.govmailto:robert.richa...@opm.gov - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Peculiar issue related to TSO logons
John, CANCEL STARTING did not work. Tried that first. Rex's suggestion of C U=*LOGON*,A=00?? *did work in all cases but one and I did a FORCE U=*LOGON*,A=00?? For that one. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Tuesday, January 10, 2012 10:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Peculiar issue related to TSO logons -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Tuesday, January 10, 2012 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Peculiar issue related to TSO logons Has anyone ever seen this before on a SDSF DA display? STARTING TSU LO FF 99 0.00 0.00 75 004B 13 0.00 DWSYSB STARTING TSU LO FF 92 0.00 0.00 87 0057 11 0.00 DWSYSC STARTING TSU LO FF 92 0.00 0.00 92 005C 18 0.00 DWSYSC STARTING TSU LO FF 93 0.00 0.00 88 0058 12 0.00 DWSYSA They do not go away on their own and they are a bear to get rid of. I did not get any hits on IBMLINK. 25 of these suckers and climbing. D A,L shows them as *LOGON*, but I haven't found the right syntax to cancel or force them yet. C STARTING,A=asid (C STARTING,A=004B is one example) should cancel them. You can get these if somebody tried to logon to TSO, but never entered a TSO userid. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IDC3309I ** RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH INVALID during DFHSM BCDS REPRO
At 13:19 -0600 on 01/09/2012, Mark Zelden wrote about Re: IDC3309I **
RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH IN:
On Mon, 9 Jan 2012 15:44:57 +, af dc acbi...@gmail.com wrote:
Hello,
during a repro from BCDS to seq file I got the following errors:
IDC3309I ** RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH INVALID
IDC3309I ** RECORD X'C5E7D7F2F1' NOT WRITTEN. LENGTH INVALID
jcl repro:
//BCDS#RI EXEC PGM=IDCAMS,COND=(0,NE)
//SYSPRINT DD SYSOUT=*
//BCDSIN DD DSN=HSM.BCDS,DISP=OLD,
// AMP=('BUFND=60','BUFNI=5')
//BCDSOUT DD DSN=HSM.BCDS.BKP.SWV1(+1),
// DISP=(NEW,CATLG,CATLG),
// DCB=(BLKSIZE=26176,BUFNO=60,LRECL=6544,RECFM=VB),
// SPACE=(CYL,(200,200),RLSE)
//SYSINDD *
REPRO INFILE(BCDSIN) OUTFILE(BCDSOUT)
bcds itself has:
ATTRIBUTES
KEYLEN44 AVGLRECL6544
RKP0 MAXLRECL6544
SHROPTNS(3,3) RECOVERY UNIQUE NOERASE
How can I correct these 2 records ??
If MAXLRECL = AVGLRECL, why RECFM=VB in your JCL output DD?
And if VB, you need to add 4 to LRECL.
Just because MAXLRECL = AVGLRECL does not mean ALL the records are
6544 long. In fact since there were only 2 errors, all the other
records were 6540 or shorter. You have the correct fix by making the
LRECL=6548 since you need to allow for the record length header on
the variable length records (IOW: LRECL needs to be
MAXLRECL+4 or larger).
You can change to BLKSIZE=0, but that is not the problem.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 11:53 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP: On Mon, 9 Jan 2012 11:54:45 -0500, Veilleux, Jon L wrote: I think that you answered your own question. aside from not recovering the victim(s) of a ++DELETE command? I could never understand why that is the case. RESTORE should restore everything. Yup. There's another one that's about as bad. When link edit JCLIN adds an INCLUDE statement, the load module is not necessarily relinked to add the MOD element mentioned. I know; this behavior is documented fully, even tediously. That doesn't alter the fact that the design is wrong. The resource spent on adding emphasis to the description of a deficiency would better have been used to repair it. -- gil RESTORE itself is BAD (Broken As Designed) since it removes SYSMODs that are not the SYSMOD being designated as being RESTORED. Instead of using ONLY the elements that are in the SYSMOD being RESTOREd (by using the copies that this SYSMOD replaced) it can remove additional SYSMODs (requiring a follow-up APPLY of the erroneously removed SYSMODs). After a RESTORE, I should be in the same state as I would be if I had not APPLY'ed the SYSMOD in the first place. Instead I can end up with other SYSMODs removed since the elements that were replaced by the SYSMOD were in another SYSMOD along with other elements NOT in the SYSMOD being RESTOREd. A RESTORE should be an APPLY of ONLY the elements that are in that SYSMOD even though there were other elements in the SYSMOD you are getting them from. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IDC3309I ** RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH INVALID during DFHSM BCDS REPRO
At 17:10 -0600 on 01/09/2012, Mark Zelden wrote about Re: IDC3309I ** RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH IN: On Mon, 9 Jan 2012 16:32:49 -0500, Robert A. Rosenberg hal9...@panix.com wrote: Just because MAXLRECL = AVGLRECL does not mean ALL the records are 6544 long. In fact since there were only 2 errors, all the other records were 6540 or shorter. You have the correct fix by making the LRECL=6548 since you need to allow for the record length header on the variable length records (IOW: LRECL needs to be MAXLRECL+4 or larger). That is correct, it doesn't have to be. But that's usually what it means. So I made a bad assumption. I didn't look at the HSM manual and didn't know off hand that it was VB.If it is VB, then normally AVGLRECL is something less than MAXLRECL. Since it is VB, then yes, add 4 to the LRECL. Blksize can be anything = LRECL+4. Even if all the VSAM records are all the same length (ie: The equivalent of FB), since they are being copied to a VB QSAM file, the LRECL has to be MAXLRECL+4. I just looked at a couple of my systems and one has the same attributes (AVG/MAX = 6544). On another, MAX = 2040 and AVG = 435. So OP: Change LRECL to 6548. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 18:26 -0600 on 01/09/2012, Paul Gilmartin wrote about Re: Error apply ZAP: RESTORE itself is BAD (Broken As Designed) since it removes SYSMODs that are not the SYSMOD being designated as being RESTORED. Instead of using ONLY the elements that are in the SYSMOD being RESTOREd (by using the copies that this SYSMOD replaced) it can remove additional SYSMODs (requiring a follow-up APPLY of the erroneously removed SYSMODs). After a RESTORE, I should be in the same state as I would be if I had not APPLY'ed the SYSMOD in the first place. Instead I can end up with other SYSMODs removed since the elements that were replaced by the SYSMOD were in another SYSMOD along with other elements NOT in the SYSMOD being RESTOREd. A RESTORE should be an APPLY of ONLY the elements that are in that SYSMOD even though there were other elements in the SYSMOD you are getting them from. And here, I half strongly disagree with SMP/E; half agree. If the PTF being RESTOREd is a PRErequisite of subsequent APPLYed PTFs, it's a logical necessity that those should be RESTOREd also. (I don't know that this is automated.) In your case you have PTF1 with Elements A and B and PTF2 that PREs PTF1 which replaces PTF1's Element A. If you RESTORE PTF1 you must also have SMPE RESTORE PTF2 since you need to all back to the version of Element A that PTF1 replaced. I do not remember if this addition of a PTF that PRE'ed the PTF being RESTORE'd will be automatic or not My issue is with the reverse case where you are RESTORE'ing PTF2. Right now this will ALSO restore PTF1 (and thus back out Element B from PTF1) and possibly other PTFs that PTF1 PREs. To back out PTF2 ALL that is needed is to select Element A from PTF1 and ignore PTF1's Element B (since B is at PTF1 level even after PTF2 is APPLY'ed and thus there is no need to remove it to remove the PTF2 level of Element A). The way it works currently, RESTORE'ing PTF2, RESTOREs PTF1 which triggers getting A and B from whoever PTF1 PRE'ed (who owned A and B before PTF1 was APPLY'ed). If that PTF contained any element other than A and B, IT gets added to the list of PTFs that will get RESTORE'ed. This backtracking continues until you find a set of PTFs in the PRE/SUP chain that contains all the Elements (and only them) that is being backed out - These copies of the elements are what are used. EVEN WORSE -The only elements that are eligible to be used are from ACCEPT'ed PTFs not these that are only in APPLY status. RESTORE thus removes good PTFs in APPLY status since it removes all PTFs that replaced the ACCEPT'ed levels of the elements being backed out. Thus if PTF1 SUP'ed PTF0 (which only contained A and B), PTF0 would be added to the list to be restored unless it was already in ACCEPT status. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IDC3309I ** RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH INVALID during DFHSM BCDS REPRO
At 15:40 -0600 on 01/09/2012, Jonathan Goossen wrote about Re: IDC3309I ** RECORD X'2BC5E7D7F2' NOT WRITTEN. LENGTH IN: Shouldn't the block size be 26176. The current block size is 4*LRECL instead of 4*(LRECL+4) as VB requires. That is not important. So long as the block size is LRECL+4 or greater there is no problem. The block will be filled until the next record you try to add is longer than the remaining free space. If the LRECL is 6544 (and all the records are 6540 + the 4 byte length field) to fit 4 records into a block the block size needs to be 26180 (ie: (4*LRECL)+4). LRECL includes the record length field. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 13:31 -0600 on 01/07/2012, Ed Gould wrote about Re: Error apply ZAP: Robert: I used to have a vendor that would send out zaps almost weekly and IDR space was at a premium on the vendors modules. We dropped the vendor so I don't know how they did resolve the constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. As I noted, and someone here confirmed, doing a relink adds extra IDR room (if the current IDR Record is full). IOW: The AMA120I message by suggesting the relink would add another IDR record with room for another 19 IDENTIFY commands. The IDR record is on a per-loadmodule basis and thus is shared by all the CSECTs in the Load Module. In the case of your vendor, so long as the ZAPs came with IDENTIFY commands and you did not supply the PARM override, every 19 ZAPs (~5 months) a relink would be needed to add another IDR record to be used. Ed On Jan 6, 2012, at 11:54 PM, Robert A. Rosenberg wrote: At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Error apply ZAP
At 14:29 -0600 on 01/06/2012, Staller, Allan wrote about Re: Error apply ZAP: First the IDR (forget what the acronym stands for) is an optional list of zaps applied to this module (load module?). Due to the structure of the directory, IIRC, you are limited to 19 IDR entries per module (load module?). The IDR data is set by an AMASPZAP control statement. IDENTIFY. The message AMA120I message below may be safely ignored. It is indicated that there is no space left to record additional IDR information. The only impact of this is that it will make it difficult to determine which zaps have already been applied. If you relink as the AMA120I suggests/instructs the Binder adds another (empty) IDR record so you can use the IDENTIFY statement (think this is automatic although it may be triggered by supplying a Binder command to add more IDR Space). As you note, this allows you to track what ZAPs have been installed. If I remember IDR is ID Record. There are IDR records for each CSECT in the Load Module (they come from the Assembler) so you can see what the assembly date of the CSECT is (there is only one for the last linkedit). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: cpu / machine identification
At 20:42 -0600 on 12/29/2011, Brian Westerman wrote about Re: cpu / machine identification: We have DR support in our software, but I was under the impression that most of the DR sites were running the OS under VM and they simulated the serial anyway. I suppose their are sites that do not run the DR under VM, but don't the sites who don't run under VM know the serial number ahead of time, and wouldn't it be already built into the software, or they have a already setup job to enter the new serial(s)? I know I would have it set up if it were me. Knowing the Serial Number of the machine you are going to run DR on and having it already built into the software is being too optimistic. Not only can you have multiple DR Sites to go to and choosing one based on who can service you when you need DR Services but even if it was only one site, I am sure that they have multiple machines and you would not want to list all of them. Until you get there, you would not know which machine that is going to be assigned to you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: cpu / machine identification
At 20:10 -0600 on 12/28/2011, Brian Westerman wrote about Re: cpu / machine identification: That's a good point, our code does put out the message at startup about the site it's licensed to. But if someone was going to run it purposely and not pay, zapping the one instance of the name is not as hard as changing every page of a 300 page book. That (Zapping the Registered Licensee Field) is not that hard to work check for. You do a check sum on the field and spot when it has been done. The routine to do this does not need to be hard coded but can be built on the fly as the the program executes. The same built on the fly code can also issue the ID message if the original field has been hacked. The use of built on the fly code and placing the result in a STORAGE acquired area makes it harder to find an circumvent (the actual build code is hidden by being interleaved in normal code that needs to run not as a simple block of code that can be bypassed by a zapped in branch). I have seen this type of code in commercial products that I was responsible for developing and maintaining so I know it can and has been done. It is simple Just In Time type compilation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Looking DB2 for z/OS discussion list
The listserv has moved to a new ISP. And as such, if you want to post any questions etc, you must first register on the website, when that is complete you will then be able to post to your heart's content (as long as you follow the 'rules). Email commands are not longer accepted www.idug.org Robert Galambos CIPP/C CIPP/IT (DB2-l admin) Compuware Senior Technical Specialist IBM Certified Solutions Expert - DB2 UDB for OS/390 Database Administration Certified Information Privacy Professional/Canada Certified Information Privacy Professional/Information Technology robert.galam...@compuware.com Tel: +1 905 886 7000 Toll Free: +1 800 263 7189 Fax: +1 905 886 7023 Quebec: +1 877-281-1888 Compuware Canada Service is our best product The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, December 26, 2011 10:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Looking DB2 for z/OS discussion list In caodpegqwhcqjqu0ajmj646xpqgijnhmerxdpf415fj72b8b...@mail.gmail.com, on 12/26/2011 at 11:54 AM, Itschak Mugzach imugz...@gmail.com said: This is the posting addr: IDUG DB2-L db...@idugdb2-l.org. As seen, the list server managed by IDUG Does it accept normal listserv requests at lists...@idugdb2-l.org? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support:
At 10:21 -0800 on 12/26/2011, Edward Jaffe wrote about Re: Eight-character TSO Userid Support:: Application environments are responsible for supporting whatever the current architected userid length is. It has been asserted that TSO is the only z/OS application environment in 2011 (soon 2012) that can't handle that fundamental requirement. I'm trying to discover if that's a true statement. None of the responses I've received thus-far have offered anything to disprove that assertion. If true, fixing TSO will provide *complete* eight-character userid support for z/OS. The problem with allowing TSO to use 8 Character USERIDs is that it makes some TSO commands fail. Jobnames are 8 characters max. Submit (at least ISPF Automatic Submit) adds a one character suffix to the UserID and thus breaks if the UserID is 8 Characters (since that would result in an invalid length 9 character JOBNAME). Also OUTPUT (used by ISPF 3.8) validates that the JOBNAME is UserID+1_Character and thus would not be able to handle 8 character UserIDs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
At 12:15 -0600 on 12/26/2011, Paul Gilmartin wrote about Re: Eight-character TSO Userid Support: Likewise, in days of yore, but no longer, one DSN was not allowed to be a prefix of another, such as: GUBBINS.WOMBATversus GUBBINS.WOMBAT.FUBAR This was due to CVOL Support. Each level was a set of chained records and WOMBAT as a File name conflicted with it being a record containing a pointer to another level. If you had GUBBINS.WOMBAT.FUBAR and GUBBINS.WOMBAT.WOMBAT.FUBAR that was allowed. The GUBBINS Index record would point to chained records which were the 2nd level of indexes (one of which was WOMBAT). That WOMBAT Index record would point to a 3rd level of indexes (all chained from GUBBINS.WOMBAT). One FUBAR File record would be pointed to by the WOMBAT File record that was pointed to by GUBBINS.WOMBAT while another would be pointed to by GUBBINS.WOMBAT. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Eight-character TSO Userid Support
At 19:20 -0600 on 12/24/2011, Paul Gilmartin wrote about Re: Eight-character TSO Userid Support: Hmmm. How many upper-case alphanumeric characters would be needed to provide unique identifiers for all the files an enterprise would ever need? By that metric, 44(8) is more than sufficient. A dataset name is up to 44 characters long but that is based on a set of 36 characters (26 letters and 10 numbers) CURRENTLY broken up into 1-8 character blocks separated by periods. The 8 character blocks are composed, if I remember correctly of 1 Alpha (A-Z) followed by 0-7 Alpha (A-Z) and Numeric (0-9) characters. There may also be some special characters in addition to the 36 (I forget). For GDG Datasets, the limit is 39(8) since the last 9 are required for the .GVyy suffix to the GDG File Base Name. What do you mean by 44(8) anyway? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
At 02:56 -0500 on 12/21/2011, Shmuel Metz (Seymour J.) wrote about Re: Imagine dealing with THIS in production: In p06240803cb16cda5395b@[192.168.1.11], on 12/20/2011 at 06:47 PM, Robert A. Rosenberg hal9...@panix.com said: (unless Gilbert goofed and counted the non-existent February 29, 1900). A minor gaff if he did, since an error of 4 years would hot have affected Frederick's plight. A more serious gaff is that forced marriages were no longer legal, although the songs are compelling enough that I don't worry about it while listening to the music. The plight would not be affected by if 1900 was a leap year or not. The point was his comment about having to wait until 1940 to be free of his indentures. If you check out the story I mentioned (which appears in one of the Black Widower anthologies) the question of when the story takes place is addressed (and thus if he was born in 1856 or 1852 - 84 or 88 years prior to the 21st Birthday year of 1940). There is an analysis of the rest of the dialog/lyrics to see evidence for when the action was occurring. As was normal for Dr. Asimov he does a good job on the analysis of the evidence before delivering his result. I will leave it up to anyone who is interested to read the story and agree or disagree with his view. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine having to deal with THIS in production
At 21:46 -0500 on 12/20/2011, John Gilmore wrote about Re: Imagine having to deal with THIS in production: Robert A. Rosenberg writes: begin snippet . . . There is also the issue that in some calenders the date of New Year's Day (ie: When the new year starts) is not a fixed number of days from the start of the year but needs to be decided at the last moment by an official who issues his ruling. /end snippet and I am not sure that I fully understand this formulation. Lunar and, to some slight degree, lunisolar calendars may have an observational component. The putative date of a new moon and thus also a new month is always known with some precision; but until that new moon is in fact observed at a specific location the corresponding event does not occur there; its celebration is deferred. These observations are made by clerics, who may be important figures but who are not really 'officials'; and only in very special circumstances do these clerics have much discretion about whether a new moon has been observed in the night sky. Others are observing this sky too, and no cleric wishes to be made a figure of fun by denying what is obvious to many others. John Gilmore Yes I was referring to clerics and deciding when a new year starts based on viewing the night sky. I may be remembering wrong but it was something on the order of needing to see some set number of stars in the sky within some time of sunset. Failure of the observation extends the year until it be done. A sand storm g (or other event) that prevents the needed observation from occurring would thus affect the synchronization of the Common Calendar with the Religious one. I may be confusing the new year with some other religious event. I only remember in the context of a problem in making up printed calendars in advance due to the need for the event to occur before the linking of the two sets of dates can be done. If true, this would have some effect on computer calendar conversion routines since they would need to be adjusted once a year instead of being accurate for years into the future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
At 20:38 -0600 on 12/16/2011, Chris Mason wrote about Re: Imagine dealing with THIS in production: Mike Just think about all the people born on Feb 29th. They would have their 15th birthdate when they are 60 years old. Paradoxically a 29th February birthday can have happy consequences - at least in the fertile imagination of a writer of libretti for comic opera such as William Schwenck Gilbert: quote You are the victim of this clumsy arrangement, having been born in leap-year, on the twenty-ninth of February; And so, by a simple arithmetical process, you¹ll easily discover, That though you¹ve lived twenty-one years, yet, if we go by birthdays, you¹re only five and a little bit over! /quote http://math.boisestate.edu/gas/pirates/web_op/pirates18.html Chris Mason But when was he born? While the 21st birthday is supposed to occur in 1940, will he be 84 or 88 then? The year 1900 was NOT a leap year so he would need to wait from 1896 until 1904 for his next birthday (unless Gilbert goofed and counted the non-existent February 29, 1900). See Isaac Asimov's Black Widower Year of the Action for details. On Fri, 16 Dec 2011 16:09:21 -0600, Mike Schwab mike.a.sch...@gmail.com wrote: They would have their 15th birthdate when they are 60 years old. On Fri, Dec 16, 2011 at 3:49 PM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 16 Dec 2011 14:57:14 -0600, Mike Schwab wrote: At least they only loose 1 birthday a lifetime. Just think about all the people born on Feb 29th. The 60th day of the year? What's the big deal with that? -- Tom Marchant -- Mike A Schwab, Springfield IL USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine having to deal with THIS in production
At 23:02 -0600 on 12/19/2011, Joel C. Ewing wrote about Re: Imagine having to deal with THIS in production: There are of course other strong arguments against universal usage of JD for dates any time in our lifetime. As long as we remain an Earth-centric and not a space-centric culture, that makes it unlikely most people would favor an ordinal-based standard date format like Star Date or Julian Day which has no obvious relationship to Earth's annual seasons, when awareness of those seasons is so important to our physical comfort and survival. There is also the issue that in some calenders the date of New Year's Day (ie: When the new year starts) is not a fixed number of days from the start of the year but needs to be decided at the last moment by an official who issues his ruling. Note that while the Hebrew Calender has various length years (with an added month in some years and months with added or missing days), the start of the new year is known in advance at all times no matter how far in the future you want to go and this need to get an official pronouncement of Happy New Year at year end from an official does not exist. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
At 22:44 -0600 on 12/18/2011, David Mierowsky wrote about Re: Imagine dealing with THIS in production: At least they didn't have to deal with this! Thankfully this was sorted out long before computers were around! The Changes of 1752 In accordance with a 1750 act of Parliament, England and its colonies changed calendars in 1752. By that time, the discrepancy between a solar year and the Julian Calendar had grown by an additional day, so that the calendar used in England and its colonies was 11 days out-of-sync with the Gregorian Calendar in use in most other parts of Europe. England's calendar change included three major components. The Julian Calendar was replaced by the Gregorian Calendar, changing the formula for calculating leap years. The beginning of the legal new year was moved from March 25 to January 1. Finally, 11 days were dropped from the month of September 1752. The changeover involved a series of steps: December 31, 1750 was followed by January 1, 1750 (under the Old Style calendar, December was the 10th month and January the 11th) March 24, 1750 was followed by March 25, 1751 (March 25 was the first day of the Old Style year) December 31, 1751 was followed by January 1, 1752 (the switch from March 25 to January 1 as the first day of the year) September 2, 1752 was followed by September 14, 1752 (drop of 11 days to conform to the Gregorian calendar) You forgot step 4 which were the riots when the landlords charged a full 3 month rent for the July-September 1752 quarter instead of giving a rebate for the non-existent 11 days in the quarter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WAIT ECB WITH 00 First Byte
At 01:24 -0500 on 12/18/2011, Jim Mulder wrote about Re: WAIT ECB WITH 00 First Byte: Quoting from the MVS/XA SP2.1.0 version of IEAVEPST (5 years before it became OCO in MVS/ESA SP3.1.0, so some of you probably have this on microfiche that you have squirreled away somewhere): * WHEN THE WAIT COUNT BECOMES ZERO, THIS CHECKS IF THERE WAS A LIST * OF ECB'S BEING WAITED ON BIGGER THAN THE WAIT COUNT. IF SO, THE * LIST ADDRESS IS FOUND (GETTING REG 1 FROM WHERE THE RB'S REGISTERS * WERE SAVED). ALL OF THE ECB'S WAIT FLAGS (EXCEPT FOR THE ECB BEING * POSTED) ARE RESET TO ZERO. SPACE 1 */* D (NO,TCBREADY,YES,) RB SEARCH BIT IS ON*/ TMRBSTAB2,RBECBWTECB'S SEARCH FLAG SET BZTCBREADY NO, BRANCH */*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/ L R10ECBP,TCBGRS1ASSUME REGS IN TCB CLR5RB,TCBRBPECB'S RB TOP OF QUEUE BERESETWTYES, BRANCH L R3WORK,TCBRBP GET ADDRESS OF TOP RB * NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP LOOP3L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1 ICM R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR * (HIGH BYTE ALREADY CLEARED) CLR R3WORK,R5RBFOUND WAITING RB BNE LOOP3 NO, BRANCH I could not find anything in the manuals which says this, but it has worked this way for at least 30 years. Does this apply not only to a WAIT call using ECBLIST but also to the EVENTS call? It has been a while since I coded but I have the impression that once issued the interface would handle each ECB as a separate event and that there was no need to issue the call more than once (and that in fact if not all the ECBs were handled, it was needed to issue a EVENTS call to cancel the wait on any non-yet-posted ECBs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: case from DR in France.
Shai, Ignore him. Most of us already do. Some do not complain about him anymore because he is already in their email kill file. Better yet, invite him to come visit you and see your work environment. Most of us applaud the grace with which you conduct yourself in spite of daily threat of rocket attacks. Shalom, Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of shai hess Sent: Wednesday, December 14, 2011 3:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: case from DR in France. I wish I knew why this man so angry at me whenever I breathe. On Wed, Dec 14, 2011 at 8:42 AM, Ed Gould edgould1...@comcast.net wrote: snipped...not worth repeating -- 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: Fwd: case from DR in France.
Really? Mark Zelden Jim Marshall John Kalinich Rick Fochtman just to name a few that came to mind in 60 seconds Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould Sent: Tuesday, December 13, 2011 1:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Fwd: case from DR in France. Has anyone noticed that we never hear from any of the contributors from the CBT ? 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 -- 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: SV: JCL sheesh! for today
At 06:50 -0800 on 12/08/2011, Charles Mills wrote about Re: SV: JCL sheesh! for today: The inconvenient fact is that is the effective way to prevent deadlocks. Is not another technically plausible approach for this theoretical new JCL and initiator thing to always make the requests in alphabetical order? (Okay, ascending collating sequence?) That way all jobs that require both resources A and B would always ask for A first and prevent the dead- or livelock that you describe? Charles Not going to fly since that requires that the programs ONLY issue 1 ENQ (listing all the needed datasets). So long as you allow dynamic allocation and its associated ENQ you have no way of insuring that you can not have the deadly embrace type of situation. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, December 08, 2011 6:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SV: JCL sheesh! for today On Thu, 8 Dec 2011 15:13:04 +0100, Thomas Berg wrote: the dynamic allocations can lead to more deadlocks between jobs. The initiator avoids them by ENQing all the data sets defined in the JCL before the job starts. Yes, but this also often causes unneeded queuing as I see it. If You e g does the allocations in a rexx You could check for ENQ's before allocation and/or retry the allocation repeatedly (per Your choice) with waits between the retries. And also in this situation select the needed Than merely substitutes a livelock for a deadlock. If Job 1 holds resource A and repeatedly attempts to obtain resource B while Job 2 holds resource B and repeatedly attempts to obtain resource A, the process never terminates, and both resources remain inaccessible to other jobs for the duration. allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. -- 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: SV: JCL sheesh! for today
At 08:34 -0600 on 12/08/2011, Paul Gilmartin wrote about Re: SV: JCL sheesh! for today: allocation dependencies without the all or nothing approach that the initiator takes. The inconvenient fact is that is the effective way to prevent deadlocks. One technically plausible mitigation would be to provide for downgrading an ENQ from EXC to SHR. This would be VERY easy to provide (so long as you can find a bit in the ENQ parms to ask for the EXC-SHR switch). There might need to be a tolerance PTF issued for older releases to insure that they will see the bit and wait for the DEQ as at present. All that is needed in the ENQ code itself is to switch the state in the record from EXC to SHR and then drive the routine in DEQ that runs the chain when you DEQ an EXC hold. This chain running would either release all the waiting SHRs (until chain end or running into another EXC) or leave the chain alone (depending on if the 2nd entry is an EXC, or there is no 2nd entry). -- 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: JCL sheesh! for today
At 10:19 -0600 on 12/08/2011, McKown, John wrote about Re: JCL sheesh! for today: Ack!!! I meant SYSUID not RACUID. RACUID is used in RACF profiles. SYSUID is used in JCL. Define that SYSUIDL means SYSUID lower-cased (since there is no such thing as SYSUIDL currently it becomes a new keyword that is auto set - ie: It is read-only set from the SYSUID value). End of problem - you have the capability of forcing lower case when needed. -- 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: JCL sheesh! for today
At 20:44 -0600 on 12/08/2011, Paul Gilmartin wrote about Re: JCL
sheesh! for today:
It should be expanded by Allocation, at interpretation time, so the effect
of //X DD PATH='~bozo' would be consistent with BPXWDYN(
path('~bozo/' ...)
and in turn consistent with BPXBATCH,PARM='sh ... ~bozo ...'. And
this is easiest for the Reader/Converter. All they need to do is to
leave PATH alone and report no syntax errors whatever on it.
You better hope that you run the interpretation on the same machine
that the job stream will execute on (or is interpretation the first
step of execution? If so, ignore this message) in a JES2/JES3 MAS
environment or you run the risk of the mapping being different on the
different MAS images.
--
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: z/OS's basis for TCP/IP
LOL! OS/390 TWO dot FIVE (OS/390 2.5 was around 1996 IIRC) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bob Shannon Sent: Tuesday, December 06, 2011 8:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP Actually, it was OS/390 1.5, not z/OS 1.5. Too long ago. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, December 06, 2011 7:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z/OS's basis for TCP/IP Bob Would you care to supply some evidence for your contention? I find no trace of such an upheaval in the z/OS V1R5 Communications Server IP Migration and Exploitation manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B130/ On the other hand, while there are still components of the system which require the functions associated with Step 3, Configure VMCF and TNF, of the configuration tasks. related to the dreaded Pascal API, you know you are still in the grip of the original ivory tower authors! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3B0/1.2.21.5 Chris Mason On Tue, 6 Dec 2011 12:07:22 +, Bob Shannon bshan...@rocketsoftware.com wrote: I believe that the TCP/IP for VM product which was ported to become the TCP/IP for MVS product which became incorporated into the Communications Server product as the IP component follows what is described as the Berkeley Software Distribution (BSD flavour of an implementation of the Internet Protocol and related protocols such as TCP and UDP and so on. However, TCP/IP was re-written for z/OS 1.5. I don't know how much of the original port remains. Bob Shannon Rocket Software -- 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 -- 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: Version Query for Installed Product
SoftAudit (or whatever IBM calls it...TLCM?) may be able to identify products. But if you could afford that product, you could probably increase your MSU capacitya better alternative. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Monday, December 05, 2011 12:03 AM To: IBM-MAIN@bama.ua.edu Subject: Version Query for Installed Product Hi, There are some Product in our system where the version Indication is not visible via Datasets(SMPE datasets) or thru SMP/E panel. Our systems MSU capacity is too low due to which we are unable to make the installed product to run which might cause the products to consume more process or CPU. Are there any sample JCLs which will pull out the version of the offline products. I was able to get the version of some product through SMP/E panel(query facility). There are some products for which I am unable to extract. Any Hints or suggestion would really help me in extracting the details. Jakes -- 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: What SMF record types and formats does ACF2 write?
At 17:43 -0800 on 12/05/2011, Ed Gould wrote about Re: What SMF record types and formats does ACF2 write?: Scott, Well IBM does this in their freely available SMF records layout manual. The very idea that a record layout should not be public information is in my mind close minded. Ed There are also DSECT mapping Macros for the SMF record (although the macro might only be supplied if you have RACF installed). -- 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: Terminology
At 17:06 -0500 on 11/22/2011, Shmuel Metz (Seymour J.) wrote about Re: Terminology: Correct transmission of anything but ASCII require three header fields, e.g., Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit The Charset can also be ISO-8859-1 (which is the usual ISO-8859-*). It differs from -15 by not having a few French letters missing from -1 and having the fraction characters (1/4, 1/2, 3/4) that were removed in -15 to make room for the French Characters. -15 also officially contains the Euro Symbol [¤] which is not in -1. Even better since it will show ALL Glyphs just use UTF-8. -- 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: Fixing a sysplex definition problem for the first system in a sysplex - was: Re: CFRM Policy Number
I hope the above didn't completely confuse everybody! Quite the contrary, your comments about NOCATALOG were excellent! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Thursday, December 01, 2011 12:54 AM To: IBM-MAIN@bama.ua.edu Subject: Fixing a sysplex definition problem for the first system in a sysplex - was: Re: CFRM Policy Number The danger is that if *anything* goes wrong before your first system comes up, you cannot log on to fix even the most trivial problem. One way to be able to fix a sysplex problem that occurs for the first system is the following and requires planning in advance: 1. Use the default of NOCATALOG when defining the CDS. Yes, that is *still* the default. Make sure the CDS is NOT SMS-managed. (This enables you to define a new one from another sysplex or system that is up and running. All you need is access to the DASD volume the CDS will reside on.) 2. Have the sysplex. or any other qualifier that uniquely identifies *this* sysplex in the CDS name. If you don't (or have the CDS names identical on all sysplexes), the ENQ from XCFAS (that is just there to prevent you from shooting yourself in the foot when deleting CDSs) will interfere with the definition of a CDS on a different volume but with the same name. Despite NOCATALOG being the default, apparently it was never tested to define a CDS on a new volume with that ENQ present, so there is no way around it, not even via the STGADMIN RACF definition. XCF just cannot distinguish between the same name on a different volser because the ENQ cannot. Ask me how I know. Once the name is different, XCF has no problem defining the dataset, which in my opinion is adding more complexity than necessary. 3. Make sure that you specify the volser each CDS resides on in couplexx. Also, since you use NOCATLOG, the volser must get specified on every setxcf command. 4. Make sure that SYS1.SYSPLEX.CNTL (or whatever your name is as long as it is not sms-managed) is on a DASD accessible to the system that the DASD for the CDSs is accessible to. We put ours on the volume containing the primary sysplex CDS. I believe that's it. I have implemented this here, and it came in handy when we had to combine two previously independent sysplexes into one and all the two subplexes ever shared were the CDSs. It was also very handy when we had the latest round of problems with a GRS wait state because of an XCF definition, and the GRS wait state didn't even tell us the reason. BTW 'SYS1.SYSPLEX.CNTL' was our choice of a PDS to hold all couple data set and policy definitions. I highly recommend creating a single repository for all sysplex definition job streams even in a small shop. I completely agree with this advise, *especially* for the LOGR CDS, since updating that policy is done on a logstream-by-logstream basis with i.e. CICS defining new log streams as they please (if you let them). If you ever loose the LOGR CDS, you will need a repository of everything that was defined to speed up restart. And more advise: Keep the joblogs of all your latest definition jobs in sys1.sysplex.joblog, also residing on the same volume as sys1.sysplex.cntl. That helps tremendously when you actually have to check why the upcoming first system of a sysplex insists on wait stating because it cannot find ISGLOCK. We had it happen that we *thought* (checked by six eyes) we had done the right definition, but we had not. In addition, once you change the definitions from another sysplex, the joblogs won't be accessible from the sysplex they were done for. It requires discipline, though, to always save the joblogs. I hope the above didn't completely confuse everybody! Barbara Nitz -- 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
IKTLOGR ERROR 026
IKJ608I TSOLOGON TERMINATED. IKTLOGR ERROR 026,USER xx,PROC x Anyone know what might cause these to show up all of the sudden? We are at z/OS 1.12 and have been for months. - Robert B. Richards(Bob) US Office of Personnel Management 1900 E Street NW Room: BH04L Washington, D.C. 20415 Phone: (202) 606-1195 Email: robert.richa...@opm.govmailto:robert.richa...@opm.gov - -- 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: IKTLOGR ERROR 026
Walt, Thank you, but I was not asking what it was... I was asking what would cause it to show up all of the sudden (about a dozen times recently for different users on different systems in one sysplex). I am suspecting a bug, but thought I'd canvass the list for their experience with this (or lack thereof). Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Walt Farrell Sent: Thursday, December 01, 2011 12:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IKTLOGR ERROR 026 On Thu, 1 Dec 2011 12:33:27 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: IKJ608I TSOLOGON TERMINATED. IKTLOGR ERROR 026,USER xx,PROC x Anyone know what might cause these to show up all of the sudden? We are at z/OS 1.12 and have been for months. It's explained in the Messages book if you lookup that message. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2M9C0/SPTM012768 quote When the program is IKTLOGR and the return code is 26, it means reconnect failed because a previous reconnect attempt was already in progress. /quote -- Walt Farrell IBM STSM, z/OS Security Design -- 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: CFRM Policy Number
D XCF,COUPLE and D XCF,POLICY should be very informative. Unless, of course, you mean the actual dataset containing your policy source. That dataset can be *any* name. If I didn't already know ours and had to find it without asking someone, it would have taken me a few hours (or potentially days) to scour lots of datasets with a Find String utility looking for the program called IXCMIAPU. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of saurabh khandelwal Sent: Wednesday, November 30, 2011 1:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: CFRM Policy Number Hello, Thanks for reply. I dont see any dataset having CFRM policy detail. Is there any sysplex command, which can give me idea about policy residing dataset. Regards Saurabh On Wed, Nov 30, 2011 at 10:39 AM, Skip Robinson jo.skip.robin...@sce.comwrote: Yes, you can create a new CFRM couple data set with a larger capacity to hold more policies. I don't know of a technical maximum limit, but practically speaking, how many do you want to keep 'at the ready' at any one time? You can dynamically switch among defined policies via the SETXCF command. How likely is it that you would be inspired to switch from the current active policy back to one that was last used three years ago? Or one year ago? The practical key to managing CFRM policies centers on the policy source, not on the compiled policy itself. Our SOP is to maintain only THREE complied policies at all times. We manage them like this: -- Each policy is named POLICY1, POLICY2, or POLICY3. -- The active policy rotates among those names, 1 -- 2 -- 3 -- 1 and so on. -- To create a new policy, backup the next in rotation and then overlay the old source with the new one. -- Edit the new policy source. -- Compile the new source and activate it. Example: CFRM policy data set contains three compiled policies: POLICY1 POLICY2 POLICY3 . POLICY3 happens to be the current active policy as shown by D XCF,POL,TYPE=CFRM . -- Go the policy source library. -- 3 rotates around to 1, so first backup the source for POLICY1. We use a naming convention where the 'old' version of POLICY1 is POLICY1@. -- Copy member POLICY3 over POLICY1. -- Edit the POLICY1 source to replace every occurrence of 'POLICY3' with 'POLICY1'. -- Edit all desired changes into the new POLICY1. -- Compile the new POLICY1 into the CFRM policy data set. -- Activate the new POLICY1 via SETXCF. -- If a serious problem shows up immediately, reactivate POLICY3. -- If a minor problem shows up, re-edit the source for POLICY1 and try again. There's no point in enshrining a bad policy. -- Down the road when you need another change, move on to POLICY2, then to POLICY3, then to POLICY1 ad infinitum. We have run this way since 1995. Policies are maintained as described by z/OS folks, by CICS folks, and by DB2 folks. All source lives in SYS1.SYSPLEX.CNTL, so everyone stays on sync at all times. NO ONE EVER keeps a private copy of any sysplex source or JCL. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: saurabh khandelwal sourabhkhandelwal...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 11/29/2011 08:22 PM Subject:CFRM Policy Nmuber Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hello, We have a requirement to add new policy and structure in current CFRM couple dataset. I have extracted the current CFRM report from administrative utility. Which says, /* XCF Format Utility Control Cards: */ DATA TYPE(CFRM) * ITEM NAME(POLICY) NUMBER(3)* ITEM NAME(STR) NUMBER(150) ITEM NAME(CF) NUMBER(2) ITEM NAME(CONNECT) NUMBER(32) ITEM NAME(SMREBLD) NUMBER(1) ITEM NAME(SMDUPLEX) NUMBER(1) ITEM NAME(MSGBASED) NUMBER(1) I can have maximum 3 policy defined under this CFRM couple dataset. But When I check my policy detail, I have already three policy defined under this. Now to add new policy I just found the way to delete the oldest policy and create new policy and structure as required. But I know to know that, If I dont choose the option to delete oldest policy and I want to add new policy under this CFRM... Is it really possible. It means is it possible to change defination of CFRM couple dataset and increase the PLOICY ITEM number. Currently it set to 3, as below . I marked it in bold letter. /* XCF Format Utility Control Cards: */ DATA TYPE(CFRM) * ITEM NAME(POLICY) NUMBER(3)* ITEM NAME(STR) NUMBER(150) ITEM NAME(CF) NUMBER(2) ITEM NAME(CONNECT) NUMBER(32) ITEM NAME(SMREBLD) NUMBER(1) ITEM NAME(SMDUPLEX) NUMBER(1) ITEM NAME(MSGBASED) NUMBER(1) I tried checking in google and SYSPLEX manual, but It didnt help me . I want to
