HEAPCHECK and HEAPZONE difference in zOS 2.1
If someone can explain the difference between HEAPCHECK and HEAPZONE (new in z/OS 2.1) -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ralf Zantopp ist nicht erreichbar
Ich bin ab 02.12.2013 außer Haus und ab 09.12.2013 wieder im Büro. I'm out of the office from 02.12.2013 and will be back on 09.12.2013. Gerne werde ich Ihre Nachricht nach meiner Rückkehr beantworten. Mit freundlichen Grüßen Ralf Zantopp -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Removing messages from Hardcopy medium
Hi folks, I have inherited an IEFACTRT routine which writes step information to routcde=14. I want to stop these messages appearing in the syslog/operlog and I thought I knew how to do it, but the evidence suggests otherwise! RO *ALL,D C,HC shows: AL01 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 970 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 AL02 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 927 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 D C,ROUT=14 shows: AL01 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 989 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA AL02 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 929 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA However, when I run my job I still get: N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 - -TIMINGS (MINS.)-- S -PAGING COUNTS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK S SERV WORKLOAD PAGE SWAP VIO SWAPS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -S01COPY 00 0 0 .00 .00 .0 S27 BATCH 0 0 0 0 which (unless I'm going mad) is routcde=14. Can someone please enlighten me? Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-authorized caller calling authorized services
trying to stay away from having to add a new address space to the product I have seen programs do the following: - Create/Schedule an IRB to run in ASID=1 under what one might call the NIP task (there is possibly no intended interface to determine this task; it happens to be the task that ran the RIMs during IPL). - Issue the cross-memory services definitions from the IRB (thus they persist for the life of the IPL). That avoids having an extra address space for no purpose other than persistance Any PC in such a scheme would be non-space-switch (it would not be appropriate to stash your data in ASID=1 thus there would be no reason to have a space-switch PC into ASID=1). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
Two questions 1) can BLDL or DESERV differentiate between TASK STEP or JOBLIB BLDL does, if you give it a DCB address of 0, returning information in PDS2LIBF (AKA the Z byte) which indicates whether this was found in the LNKLST, joblib/steplib, or the Nth tasklib. DESERV does not support an input DCB address of 0. Neither BLDL nor DESERV cares what your input DCB represents if you give it a DCB. Could they differentiate? Sure. But so could you. There is no reason that they should. Their goal is to provide you information based on the DCB, and that does not require caring what that DCB is. The only thing that is truly important is to know if the DCB is for the LNKLST because that DCB is of special formation (such that DEBCHECK would not succeed). Only the initiator (term used loosely to represent all the code that would handle this) knows if TCBJLB of the ASCBXTCB task represents a joblib or a steplib. 2) is there any way to get DSN name given a DCB I seem to recall RDJFCB doing that but that was with EXLST pram on the DCB Since you recall, I suggest that you look at it to see. Yes, I believe that you can determine the data set name using RDJFCB, given an open DCB and the concatenation number (PDS2CNCT, AKA the K byte, from BLDL) Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
A couple of questions. What version of z/OS are you running? Have you looked at the IEFACTRT supplied in SYS1.SAMPLIB as an example? Do you want these messages in the JOBLOG only and not SYSLOG? Do you have any automation tools like OPS/MVS or Tivoli? Thanks Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: Monday, December 02, 2013 5:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Removing messages from Hardcopy medium Hi folks, I have inherited an IEFACTRT routine which writes step information to routcde=14. I want to stop these messages appearing in the syslog/operlog and I thought I knew how to do it, but the evidence suggests otherwise! RO *ALL,D C,HC shows: AL01 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 970 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 AL02 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 927 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 D C,ROUT=14 shows: AL01 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 989 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA AL02 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 929 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA However, when I run my job I still get: N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 - -TIMINGS (MINS.)-- S -PAGING COUNTS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK S SERV WORKLOAD PAGE SWAP VIO SWAPS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -S01COPY 00 0 0 .00 .00 .0 S27 BATCH 0 0 0 0 which (unless I'm going mad) is routcde=14. Can someone please enlighten me? Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEAPCHECK and HEAPZONE difference in zOS 2.1
Can you give us a little more context? z/TPF? C++? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
Running z/OS 1.12 and the exit is the version from SYS1.SAMPLIB(IEEACTRT) which writes to route-code 14. I can change this just to go to joblog (route-code=11), but in the short term (change freeze) I wanted to stop syslog retaining route-code 14 messages. Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
Perhaps you might try V SYSLOG,HARDCPY,DROUT=14 This is supposed to DeleteROUTcde 14 from the hard copy. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2g1b2/4.61.5 On Mon, Dec 2, 2013 at 7:48 AM, Lizette Koehler stars...@mindspring.comwrote: A couple of questions. What version of z/OS are you running? Have you looked at the IEFACTRT supplied in SYS1.SAMPLIB as an example? Do you want these messages in the JOBLOG only and not SYSLOG? Do you have any automation tools like OPS/MVS or Tivoli? Thanks Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: Monday, December 02, 2013 5:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Removing messages from Hardcopy medium Hi folks, I have inherited an IEFACTRT routine which writes step information to routcde=14. I want to stop these messages appearing in the syslog/operlog and I thought I knew how to do it, but the evidence suggests otherwise! RO *ALL,D C,HC shows: AL01 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 970 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 AL02 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 927 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 D C,ROUT=14 shows: AL01 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 989 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA AL02 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 929 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA However, when I run my job I still get: N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 - -TIMINGS (MINS.)-- S -PAGING COUNTS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK S SERV WORKLOAD PAGE SWAP VIO SWAPS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -S01COPY 00 0 0 .00 .00 .0 S27 BATCH0 0 0 0 which (unless I'm going mad) is routcde=14. Can someone please enlighten me? Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
Already done that! Indeed the D C,HC output shows that (supposedly) route-code 14 is not being retained by the hardcopy set. I don't really want to IPL to see if that fixes it, as it appears that I should be able to do it by command. Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
Ah! 0004000 translates to a ROUTCDE of 10! And that one _cannot_ be suppressed. On Mon, Dec 2, 2013 at 8:05 AM, John McKown john.archie.mck...@gmail.comwrote: Perhaps you might try V SYSLOG,HARDCPY,DROUT=14 This is supposed to DeleteROUTcde 14 from the hard copy. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2g1b2/4.61.5 On Mon, Dec 2, 2013 at 7:48 AM, Lizette Koehler stars...@mindspring.comwrote: A couple of questions. What version of z/OS are you running? Have you looked at the IEFACTRT supplied in SYS1.SAMPLIB as an example? Do you want these messages in the JOBLOG only and not SYSLOG? Do you have any automation tools like OPS/MVS or Tivoli? Thanks Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: Monday, December 02, 2013 5:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Removing messages from Hardcopy medium Hi folks, I have inherited an IEFACTRT routine which writes step information to routcde=14. I want to stop these messages appearing in the syslog/operlog and I thought I knew how to do it, but the evidence suggests otherwise! RO *ALL,D C,HC shows: AL01 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 970 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 AL02 RESPONSES --- CNZ4100I 14.26.58 CONSOLE DISPLAY 927 CONSOLES MATCHING COMMAND: D C,HC MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS ROUT=(1-10,12-13,15-128) LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 99 D C,ROUT=14 shows: AL01 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 989 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL01 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA AL02 RESPONSES --- CNZ4100I 14.27.50 CONSOLE DISPLAY 929 CONSOLES MATCHING COMMAND: D C,ROUT=14 MSG:CURR=0LIM= RPLY:CURR=2LIM=99SYS=AL02 PFK=00 NO CONSOLES MEET SPECIFIED CRITERIA However, when I run my job I still get: N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 - -TIMINGS (MINS.)-- S -PAGING COUNTS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -STEPNAME PROCSTEPRC EXCP CONN TCB SRB CLOCK S SERV WORKLOAD PAGE SWAP VIO SWAPS N 0004000 AL01 2013336 14:21:51.01 J0003552 0290 -S01COPY 00 0 0 .00 .00 .0 S27 BATCH0 0 0 0 which (unless I'm going mad) is routcde=14. Can someone please enlighten me? Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has anyone measured CPU savings using external SORT's vs. internal (COBOL) SORT's?
Sorry about the late reply. The last time I seriously looked, the COBOL sort verb invoked the installation sort (DFsort, SYNCSORT,). The COBOL program effectively became the E15/E35 sort exits. On that basis, I would not expect any significant difference in CPU time consumed, *AND* as someone previously noted, a possible significant increase in elapsed time. HTH, snip It has been suggested to management here that there could be potentially significant CPU savings from re-engineering application programs such that any SORT's are done in a separate step, so that a program with a single internal SORT would be broken up into a pre-SORT process followed by an external SORT of the massaged data followed by a post-process of the SORTed data. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEAPCHECK and HEAPZONE difference in zOS 2.1
Miklos, I found HEAPCHK in z/OS Language Environment Customization HEAPCHK Derivation: HEAP storage CHecKing Use HEAPCHK to run additional heap check tests. If HEAPCHK(ON) is used with STORAGE(,heap_free_value), the free areas of the heap will also be checked. If HEAPCHK(ON) is specified, this will result in a performance degradation due to the additional error checking that is performed. A U4042 abend dump will be generated when an error is detected, but no CEEDUMP will be produced. And for HEAPZONE I found in z/OS Language Environment Programming Reference Derivation: HEAP check ZONES The HEAPZONES runtime option is used to turn on overlay toleration and checking for user heaps. When activated, the runtime option affects any obtained storage that can be controlled by the HEAP or HEAP64 runtime options. HEAPZONES also affects storage obtained from a heap pool. A heap check zone is an additional piece of storage that is appended to an allocated element during a storage request. The size of the check zone depends on the size31 and size64 suboptions of HEAPZONES. The check zone can be examined for overlays when the heap element is freed. So it looks that HEAPCHK has a performance overhead and validates heaps of (I think) all HEAPS and the other a runtime option to provide overly toleration and check for USER heaps. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Monday, December 02, 2013 2:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HEAPCHECK and HEAPZONE difference in zOS 2.1 If someone can explain the difference between HEAPCHECK and HEAPZONE (new in z/OS 2.1) -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
I'm sure it's 14 as shown in the source code in SYS1.PARMLIB(IEEACTRT). 0 0 0 4 0 0 0 0 0100 Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT? Opinion article on software design being deliberately unfriendly
The most frequently heard/read user communications: 1. How do I make this [expletives deleted] do what I want? 2. Why didn't I get what I wanted when I did this, [implied you gunky]? 3. I did what I thought [you][the documentation][Fred] said and all I got was this [expletives deleted]! 4. The error message didn't tell me how to fix it, it told me to call you! The sounds of user-surly software. Vacation Notice: None currently scheduled Tom Puddicombe Mainframe Performance Capacity Planning CSC 31 Brookdale Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/27/2013 02:21 PM Subject:Re: OT? Opinion article on software design being deliberately unfriendly Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Shmuel characterizes my notion that there is an ineluctable conflict between power andease of use as a copout. I wish it were; but here the microsoft view that choices are the enemy is often correct. Users do not ordinarily know what they want to do in any constructive sense. They have global ease-of-use and performance goals, functional objectives. They seldom have even a vague notion what processing strategies are in use and what effects the parameterizations/choices available to them will have on performance or resource use. These issues can be clarified in written materials, workshops, and the like; but in my erxperience many users have little patience with the need to learn how systems work. We come down to choices that can be fudged a little but not much. A system can be easy to install, or it can he highly flexible and tunable. It cannot usually be both. Here, as elsewhere, Le bon Dieu est dans le détail; but I doubt very much that Shmuel disposes of a deux es machina that bridges this dichotomy. Things can of course be made easy, on the model of those books that used to be called Calculus made easy or the like and are now called Calculus for dummies instead, which achieve their objectives by leaving the hard parts out. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
On Mon, Dec 2, 2013 at 8:11 AM, John McKown john.archie.mck...@gmail.comwrote: Ah! 0004000 translates to a ROUTCDE of 10! And that one _cannot_ be suppressed. My mistake. I left out a 0 nybble when I was decoding. It is indeed 14. Sorry -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
So I changed the WTO to use route-code=11 and the messages were still issued to hardcopy. This caused me to look a little closer at the source and discover that the MCS flags are set on in the exit to direct the message to the hardcopy. Problem solved!! Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
On Mon, Dec 2, 2013 at 9:16 AM, Andrew Metcalfe andrew.metca...@barclays.com wrote: So I changed the WTO to use route-code=11 and the messages were still issued to hardcopy. This caused me to look a little closer at the source and discover that the MCS flags are set on in the exit to direct the message to the hardcopy. Problem solved!! Good to know. Thanks. I rarely look at the descriptor codes. Andrew -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
In !!AAAYAJXIDufoOyhGhgKtFLrs5tbCgAAAEHDnnXItsJ1KrOhmeEuKDYIBAA==@optonline.net, on 12/01/2013 at 02:03 PM, MichealButz michealb...@optonline.net said: Does BLDL or DESERV have anyway of differentiating between TASKLIB/STEPLIB/JOBLIB I think not. Yes, but it doesn't do so because there is no need. Second is there anyway of getting the associated DSN name (sic) Yes; note that there may be more than one. The TIOT offset is in the DCB; the SVA of the JFCB is in the TIOT entry. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
In !!AAAYAJXIDufoOyhGhgKtFLrs5tbCgAAAEDWoxNTvV2FJpuip65f0IWQBAA==@optonline.net, on 12/01/2013 at 02:42 PM, MichealButz michealb...@optonline.net said: Two questions 1) can BLDL or DESERV differentiate between TASK STEP or JOBLIB They could if there was a reason to. Start with the current TCB and go up the tree untill you hit the jobstep. If there are multiple tasks with the same TCBJLB, only process the DCB once. The ddname in the TIOT entry will tell you whether it is a job, step or task lib DCB. 2) is there any way to get DSN name given a DCB I seem to recall RDJFCB doing that but that was with EXLST pram on the DCB You can always build your own DCB with your own exit list. See 3.12.5 Allocation Retrieval List inz/OS DFSMS Using Data Sets. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In 1885724251.2483267.1385936064169.javamail.r...@comcast.net, on 12/01/2013 at 10:14 PM, DASDBILL2 dasdbi...@comcast.net said: I believe John Gilmore meant that the original S/360 architects thought that the system should support at least five levels in a file name and that each level could be as long as eight bytes. Whether or not that's what John meant, it's certainly a reasonable reading of the architects' intent. I suspect that this value of eight came from the maximum length of a PDS member name, It's hard to say, but certainly the CVOL data structure is similar to a PDS directory. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In 20131201232728.GA25455@dlc-dt, on 12/01/2013 at 06:27 PM, David L. Craig dlc@gmail.com said: If I remember correctly, the sole reason for limiting TSO IDs to a maximum of seven characters was to ensure running batch jobnames submitted by TSO users would never conflict with the TSO session or each other. I don't know which came first in the design, but it is certainly true that FIB relies on an appended character and that various data structures, e.g., UADS, UPT, are hardwired for 7. Neither sets a limit on an HLQ that is not a userid and is not specified in PROFILE PREFIX. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
In 6aee915e-660b-471b-837c-b2ef76d0a...@comcast.net, on 12/01/2013 at 06:15 PM, Ed Gould edgould1...@comcast.net said: I remember distinctly that UID's were limited to 7 characters. Yes, as was prefix. However, a FQDSN could have an 8-character HLQ. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Hillgang 11 Dec - Hadoop on z Going mobile
The next Hillgang user group meeting will be held in Herndon Virginia on 11 December at the CA Office. The flyer may be found at: http://download.sinenomine.net/hillgang/Hillgang%202013-12.pdf The agenda includes: - Big Data analytics through Hadoop on System z Linux - Mike Combs, VP of Marketing, Veristorm - Managing, maintaining, modernizing and optimizing your current Legacy Source Code, Alan Perkins David Korkosz, ITP-PANORAMA - CA Update, Yvonne Demeritt Mike Melillo, CA - Going Mobile with z/VM and Linux on System z Neale Ferguson, SNA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IXGBRWSE - SMF Logstream
Jose, The LOGGER provided SUBSYS DD interface (using IFASEXIT for SMF records) gives you direct access to the data in the logstream and is essentially a 'well-behaved logger' aplication that is doing the IXGCONN and IXGBRWSE (and dealing with the multiplicity of error codes) for you and giving you 'record' level access to the data via basic (old fashioned) QSAM or BSAM OPEN/GET/CLOSE level interfaces. IF you want to get close-to-real time access to the data in the logstream then you are correct that you have to build an application from the ground up using LOGGER IXG* services - the only SMF specific thing in the application is the data itself (and the format of the blocks). Which is back to your original point about the mapping of these BLOCKS. More to your actual point (I think) ... IF you want REAL time access to the data being written to SMF (DASD or LOGSTREAM) you have to use the SMF provided SMF interface exits (IEFU83/4/5) to capture and process the data AS IT is passed to SMF to be written. That answer hasn't changed since SMF was originally shipped (but it was made a whole lot simpler with the implementation of 'Dynamic Exits' back in 1992). Bill (former SMF Component owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-authorized caller calling authorized services.
On Sun, 1 Dec 2013 18:04:18 -0500 Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: :In :b6c1eb4364c30e47950e0f68ef65f467015...@proditmailbox1.us.syncsort.com, :on 11/30/2013 : at 09:53 PM, Blaicher, Christopher Y. cblaic...@syncsort.com :said: : :- Don't ever read data from a caller's address space when you are :.not in the caller's key. :MVCK MVCSK :- Don't EVER, EVER write data to a caller's address space when :you are not in the caller's key. :MVCK MVCDK -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
In 529c20f4.9020...@valley.net, on 12/02/2013 at 12:56 AM, Gerhard Postpischil gerh...@valley.net said: For a closed DCB (or any DD name) you can retrieve the JFCB via TIOT and SWAREQ lookup, as well as with RDJFCB. However, for a concatenation, you would need to know which TIOT entry to use. That was true for a long time, but these days you can use an allocation retrieval list (ARL) to get the information on the full concatenation without explicitly stepping through the TIOT entries; RDJFCB does it for you. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Fix Report Question
Here's my theory: You said you pulled down 1yr of hold data. Only the 2 year HOLDDATA file contains Fix Category HOLDs, therefore, the first report you ran didn't use the latest Fix Category HOLDs. You then pulled down and applied the missing PTFs and reran the report, being surprised to find new missing PTFs. How did you obtain the PTFs? Most likely the 2 year HOLDDATA file was delivered with those PTFs, which contains Fix Category HOLDs. When you reran the report, you were finally using the latest and greatest HOLDs, hence the additional entries in the report. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Fix Report Question
That sounds like a good guess. When I pull hold data, I use the following FTP statements, which gets everything necessary for further processing: cd /s390/holddata get full.txt 'my-mvs-data-set' (repl . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Kurt Quackenbush ku...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 12/02/2013 10:12 AM Subject:Re: Missing Fix Report Question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Here's my theory: You said you pulled down 1yr of hold data. Only the 2 year HOLDDATA file contains Fix Category HOLDs, therefore, the first report you ran didn't use the latest Fix Category HOLDs. You then pulled down and applied the missing PTFs and reran the report, being surprised to find new missing PTFs. How did you obtain the PTFs? Most likely the 2 year HOLDDATA file was delivered with those PTFs, which contains Fix Category HOLDs. When you reran the report, you were finally using the latest and greatest HOLDs, hence the additional entries in the report. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 12/1/13 7:51 AM, Dan Espen wrote: Actually, your whole description is bizarre and I think wrong. With a UNIX file, how do I NOT know where /var/log/messages is? As long as you use a full path, you know where everything is. I believe the issue some people are trying to address with a Unix catalog is the case where you DON'T know the full path. For example, suppose I have a recipe for Beef Stroganoff somewhere on my hard drive. I know it's called stroganoff.txt but I don't remember where I put it. I can certainly use the find command to locate the file, but my hard disk is large with several hundred thousand files. find may take a noticeable amount of time to locate the file. Now suppose I have some sort of index file where the key is the unqualified file name and the data is the path to that file. I can search the index for my file name and it should quickly show me all the locations where a file by that name is located. (Note that Windows has had such a facility since at least XP.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Mon, 2 Dec 2013 12:30:29 -0600, Eric Chevalier wrote: I believe the issue some people are trying to address with a Unix catalog is the case where you DON'T know the full path. ... Now suppose I have some sort of index file where the key is the unqualified file name and the data is the path to that file. I can search the index for my file name and it should quickly show me all the locations where a file by that name is located. (Note that Windows has had such a facility since at least XP.) As has OS X. Also search by substring of filename, and by content. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Sun, 1 Dec 2013 18:15:04 -0600, Ed Gould wrote: I remember distinctly that UID's were limited to 7 characters. One of the reasons was that UADS had a directory of 8 characters and the 8th character was reserved for UID's needing more space in UADS so a character was reserved (shaky here but the 8th character was either 0, 1 2 etc) to allow more space ... UID was 7 characters. The eighth was reserved for UADS as either 0 thru 8 I've heard further that while UADS is a very ordinary PDS, updates are performed in place to reduce the need for compress. As a consequence, an existing member can't be extended except by allocating an extension member. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-authorized caller calling authorized services.
When creating authorized code I use the following guidelines: - It is not good enough that the authorized code functions as designed. Authorized code has a higher standard that it must adhere to. Your code must not allow malicious or uninformed users to make it do things outside of its scope. - Pay attention to how you obtain your parameters. -Parameters should be accessed in the requesters PSW Key. -Make a copy of the parameters so that they cannot be changed after you have validated them and before you use them (time of check 2 time of use vulnerability). -Make sure sensitive data is kept in fetch protected storage. -Make sure your design does not allow the requester to control where the authorized code branches to: -By branching to a user specified address in an authorized state -By branching on a function code whose value is not verified to be in a specific range -Be careful issuing authorized services in your code AND allowing user parameters to be specified in the authorized services parameter list. - Return data to requester in their PSW Key. - Don't return control to the requester with a higher level of authority -Don't dynamically elevate their security credentials -Don't allow the requester the ability to MODESET -Don't return control in a different PSW Key or State Ray Overby Key Resources, Inc Ensuring System Integrity for z/Series (312) 574-0007 On 12/1/2013 7:47 PM, Jim Thomas wrote: Shmuel, Thank you for your responses, this and previous. I concur w/what you've said and w/what others have said. Before I go on, as Peter pointed out, I admit that I've used incorrect terminology (e.g. call / invoke a SRB) and I apologize. That said, AFAIK, there's really not much, save but for a RACROUTE REQUEST=AUTH perhaps, that I could do in terms of validation, I could do. Then again, even w/a RACROUTE/AUTH, it still does not guarantee integrity. All the above does is to make things a little harder for inappropriate users. Perhaps that is all we can do ??. I've taken everybody's suggestions and advice and think I've, decided to take a slight variation to PC / SVC's, use RACROUTE and have a separate load library that will be clearly documented as needing to be APF'd. Though I am responding to Shmuel, I thank everybody for taking the time to respond / advice. Once again, thank you everybody. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, December 01, 2013 5:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. In 021001ceee3c$9f1fe880$dd5fb980$@TheThomasResidence.us, on 11/30/2013 at 08:25 PM, Jim Thomas j...@thethomasresidence.us said: In a nutshell, I'm trying to find out what the best way is for an un-authorized called to call / invoke a SRB. It can't. The only ways for unauthorized code to invoke authorized services are PC and SVC. You need an interface service (either PC or SVC) that will accept parameters, validity check everything and schedule the SRB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Worth noting, and not at all to clear from, indeed antiothetical to, the title of this thread is that we are now addressing a deficiency of UNIX, not one of the MVS side of z/OS. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 12/2/2013 10:54 AM, Shmuel Metz (Seymour J.) wrote: It's hard to say, but certainly the CVOL data structure is similar to a PDS directory. Considering that they share code in common (e.g., directory initialization and catalog formatting), it's extremely likely. I was wondering about the five levels - office, department, group, project, name? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMSHSM TAPESECURITY(RACF)
Arye, In general, if you value the data that hsm has placed on tape, you should ensure that the data is protected. This means there has to be some RACF profile (or equivalent) protecting the volume or the data, and the system (or some other involved party) has to make the RACROUTE call to check the person opening the data set on the tape volume is authorized to do so. I would always recommend you protect hsm tapes. Depending on your security product this might be TAPEVOL profles or DATASET profiles or even a combination. The choices for protecting hsm tapes are given in the hsm books, where it even describes when hsm will automatically protect its own tapes using TAPEVOL profiles. Some tape management products, such as CA-1, have options to control if security checks are issued - If you are not using RACF TAPEDSN option, or RACF TAPEVOL class you need to look at this. z/OS also has a DEVSUPxx option TAPEAUTHDSN which is described in the z/OS Init Tuning guide. Remember that hsm runs with OPERATIONS and PRIVLEGED - so gains access to anyone elses data if it tries.. So you tape management system has to ensure complete 44 character dsname checking. I would also check if your tape management system issues RACROUTE checks for 'EDMs' and also does full 44 character dsname checking. It is not straightforward, but well worth doing and getting correct. Mike Wood - rmm expert and tape management security consultant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Removing messages from Hardcopy medium
John, This goes back to the 1970's and one of our vendors (Kommand accounting if memory serves me) did this and it took me a better part of a day to figure it out, what a PITA. I found it and kicked myself for not finding it sooner. Ed On Dec 2, 2013, at 9:19 AM, John McKown wrote: On Mon, Dec 2, 2013 at 9:16 AM, Andrew Metcalfe andrew.metca...@barclays.com wrote: So I changed the WTO to use route-code=11 and the messages were still issued to hardcopy. This caused me to look a little closer at the source and discover that the MCS flags are set on in the exit to direct the message to the hardcopy. Problem solved!! Good to know. Thanks. I rarely look at the descriptor codes. Andrew -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Using pooled data from three large shops I found for index-level usage in 28K cataloged PDSs, PDSEs, and GDGs: level, percent | histogram 1, 00 | 2, 41 | 3, 31 |xx 4, 24 |x 5, 05 | These results strongly suggest---They of course stop well short of proving---that five index levels is enough. (Sum of percents is not 100 because of rounding.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
A list of desktop search engines (which actually have little to do with desktops) - http://en.wikipedia.org/wiki/List_of_search_engines#Desktop_search_engines Something like Recoil / Xapian could probably be ported to z/OS. I would guess that the tricky part would be replacing the interface to inotify with w_ioctl / Iocc#regFileInt Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Dec 2, 2013 at 1:02 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 2 Dec 2013 12:30:29 -0600, Eric Chevalier wrote: I believe the issue some people are trying to address with a Unix catalog is the case where you DON'T know the full path. ... Now suppose I have some sort of index file where the key is the unqualified file name and the data is the path to that file. I can search the index for my file name and it should quickly show me all the locations where a file by that name is located. (Note that Windows has had such a facility since at least XP.) As has OS X. Also search by substring of filename, and by content. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Fix Report Question
I believe Kurt's theory would be closest to what actually happened. I did pull only 1yr of hold data before running the missing fix report. Then when pulling down the 1st batch of ptf's I specified the specific ptf's plus pre and corecs. Is there a way to determine when I pulled down the second set of PTF's what hold data came down with it? The hold data is in a unix file and is unreadable when browsing. Thanks Matt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Monday, December 02, 2013 10:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing Fix Report Question Here's my theory: You said you pulled down 1yr of hold data. Only the 2 year HOLDDATA file contains Fix Category HOLDs, therefore, the first report you ran didn't use the latest Fix Category HOLDs. You then pulled down and applied the missing PTFs and reran the report, being surprised to find new missing PTFs. How did you obtain the PTFs? Most likely the 2 year HOLDDATA file was delivered with those PTFs, which contains Fix Category HOLDs. When you reran the report, you were finally using the latest and greatest HOLDs, hence the additional entries in the report. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
David [Andrews]: 300K data sets all having six-level DSN values suggests that there is a standard in place that enforces their use, and you have implicitly said what it is. What this suggests to me is that four levels are enough for your purposes, leaving two available for DATE.TIME values (or, alternatively, that you use schemes that generate many otherwise identical DSNs that you then make unique using DATE.TIME values to do so). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Gil, Yes UADS was a PDS and there were some unusual items in UAD that were semi hidden. One I remember stumbling into was CPU time that the user had accumulated since the creation of the ID. Very sneaky (IIRC) . Ed On Dec 2, 2013, at 1:08 PM, Paul Gilmartin wrote: On Sun, 1 Dec 2013 18:15:04 -0600, Ed Gould wrote: I remember distinctly that UID's were limited to 7 characters. One of the reasons was that UADS had a directory of 8 characters and the 8th character was reserved for UID's needing more space in UADS so a character was reserved (shaky here but the 8th character was either 0, 1 2 etc) to allow more space ... UID was 7 characters. The eighth was reserved for UADS as either 0 thru 8 I've heard further that while UADS is a very ordinary PDS, updates are performed in place to reduce the need for compress. As a consequence, an existing member can't be extended except by allocating an extension member. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Fix Report Question
At some point in your SMPE process, HOLDDATA must reside in an ordinary MVS/DFP file in EBCDIC. I.e. the file that you input to SMPE RECEIVE must be readable. Check the contents of that file. Only full.text contains FIXCAT data. Other (smaller) files contain ++HOLD but not FIXCAT. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Dazzo, Matt mda...@pch.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 12/02/2013 12:29 PM Subject:Re: Missing Fix Report Question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I believe Kurt's theory would be closest to what actually happened. I did pull only 1yr of hold data before running the missing fix report. Then when pulling down the 1st batch of ptf's I specified the specific ptf's plus pre and corecs. Is there a way to determine when I pulled down the second set of PTF's what hold data came down with it? The hold data is in a unix file and is unreadable when browsing. Thanks Matt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Monday, December 02, 2013 10:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Missing Fix Report Question Here's my theory: You said you pulled down 1yr of hold data. Only the 2 year HOLDDATA file contains Fix Category HOLDs, therefore, the first report you ran didn't use the latest Fix Category HOLDs. You then pulled down and applied the missing PTFs and reran the report, being surprised to find new missing PTFs. How did you obtain the PTFs? Most likely the 2 year HOLDDATA file was delivered with those PTFs, which contains Fix Category HOLDs. When you reran the report, you were finally using the latest and greatest HOLDs, hence the additional entries in the report. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Fix Report Question
On Mon, 2 Dec 2013 10:21:29 -0800, Skip Robinson jo.skip.robin...@sce.com wrote: That sounds like a good guess. When I pull hold data, I use the following FTP statements, which gets everything necessary for further processing: cd /s390/holddata get full.txt 'my-mvs-data-set' (repl Which is also about 1000 times faster than RECEIVE ORDER ( CONTENT(HOLDDATA) ) not to mention more reliable than the order server. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 2 December 2013 11:01, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 20131201232728.GA25455@dlc-dt, on 12/01/2013 at 06:27 PM, David L. Craig dlc@gmail.com said: If I remember correctly, the sole reason for limiting TSO IDs to a maximum of seven characters was to ensure running batch jobnames submitted by TSO users would never conflict with the TSO session or each other. I don't know which came first in the design, but it is certainly true that FIB relies on an appended character I'm not sure in what sense it replies on it. Nothing other than perhaps a user exit or JESn/RACF settings stops a TSO SUBMIT user from submitting a job with any jobname except the userid itself. And a user exit can allow a user to use the other FIB commands on any jobname. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-authorized caller calling authorized services.
On 1 December 2013 20:47, Jim Thomas j...@thethomasresidence.us wrote: That said, AFAIK, there's really not much, save but for a RACROUTE REQUEST=AUTH perhaps, that I could do in terms of validation, I could do. Then again, even w/a RACROUTE/AUTH, it still does not guarantee integrity. All the above does is to make things a little harder for inappropriate users. Perhaps that is all we can do ??. One should be able to do better than making it a little harder; it should be very hard indeed. Part of this is carefully thinking through the authorization model. You mention RACROUTE REQUEST=AUTH, and that may well be a good start. But you need to be clear in your mind about what sort of entity you are authorizing to do what action(s). A RACF userid generally represents a real person, but it may also represent a department (e.g. operations), or various other non-person things. A hard-line view says that there should be a one-to-one mapping of people to userids, but both a principled view and common practice make that unlikely to be what you encounter everywhere. So will your RACROUTE authorize a person to run your magic code, or will it authorize the calling code to do something, or...? Is there a Trojan horse attack in there somewhere, for example can an unauthorized person convince an authorized one to run something from an inappropriate library? These are some quick thoughts; as well as good coding practices you need an authorization model (i.e. how the the good guys will be determined), and a threat model for how the notional bad guys will subvert your authorization process. The documentation surrounding IBM's original MVS statement of system integrity from the early 1970s remains to this day a remarkably current taxonomy of threats and failures, and it avoids listing what Schneier much later called movie plot threats in favour of categorizing them in a way that can be defended against. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Kirk, Absolutely, that would be a great , interesting conversion to z/OS Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 2, 2013, at 3:16 PM, Kirk Wolf k...@dovetail.com wrote: A list of desktop search engines (which actually have little to do with desktops) - http://en.wikipedia.org/wiki/List_of_search_engines#Desktop_search_engines Something like Recoil / Xapian could probably be ported to z/OS. I would guess that the tricky part would be replacing the interface to inotify with w_ioctl / Iocc#regFileInt Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Dec 2, 2013 at 1:02 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 2 Dec 2013 12:30:29 -0600, Eric Chevalier wrote: I believe the issue some people are trying to address with a Unix catalog is the case where you DON'T know the full path. ... Now suppose I have some sort of index file where the key is the unqualified file name and the data is the path to that file. I can search the index for my file name and it should quickly show me all the locations where a file by that name is located. (Note that Windows has had such a facility since at least XP.) As has OS X. Also search by substring of filename, and by content. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
The TIOT entry only says if it's a joblib Sent from my iPhone On Dec 1, 2013, at 6:46 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In !!AAAYAJXIDufoOyhGhgKtFLrs5tbCgAAAEDWoxNTvV2FJpuip65f0IWQBAA==@optonline.net, on 12/01/2013 at 02:42 PM, MichealButz michealb...@optonline.net said: Two questions 1) can BLDL or DESERV differentiate between TASK STEP or JOBLIB They could if there was a reason to. Start with the current TCB and go up the tree untill you hit the jobstep. If there are multiple tasks with the same TCBJLB, only process the DCB once. The ddname in the TIOT entry will tell you whether it is a job, step or task lib DCB. 2) is there any way to get DSN name given a DCB I seem to recall RDJFCB doing that but that was with EXLST pram on the DCB You can always build your own DCB with your own exit list. See 3.12.5 Allocation Retrieval List inz/OS DFSMS Using Data Sets. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DESERV function get DCB address
Thank you You have been very helpful Sent from my iPhone On Dec 2, 2013, at 12:56 AM, Gerhard Postpischil gerh...@valley.net wrote: On 12/1/2013 2:42 PM, MichealButz wrote: 1) can BLDL or DESERV differentiate between TASK STEP or JOBLIB 2) is there any way to get DSN name given a DCB I seem to recall RDJFCB doing that but that was with EXLST pram on the DCB For a closed DCB (or any DD name) you can retrieve the JFCB via TIOT and SWAREQ lookup, as well as with RDJFCB. However, for a concatenation, you would need to know which TIOT entry to use. For an open DCB, after a BLDL, you can examine the PDS2CNCT and PDS2LIBF to see whether the member was found in a linklib or joblib or in the concatenation (look at the IHAPDS macro and the documentation). Using the DCBTIOT offset and the concatenation number, you can get the appropriate JFCB, unless the entry came from a linklib or joblib (then it's much more difficult, and possibly indeterminate). For DESERV, if you look at the IGWDES macro under DESD, you'll find no documented field for a concatenation number; I'm not aware of a GUPI that would let you determine either the concatenation number or otherwise locate the DSN. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog system for Unix Was: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On 3/12/2013 4:16 AM, Kirk Wolf wrote: I would guess that the tricky part would be replacing the interface to inotify with w_ioctl / Iocc#regFileInt I could be wrong but it looks like Iocc#regFileInt doesn't support monitoring directories, which diminishes it's value. A port of inotify for z/OS would be a very nice to have. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
