Re: CRONTAB and SYSLOGD
SYSLOGD has parameters you can place into /etc/syslog.conf that will do automatic archiving. Look at the Comm Svr: IP Configuration Reference for these parms: BeginArchiveParms ArchiveCheckInterval ArchiveThreshold ArchiveTimeOfDay This allows you to copy the syslogd data to an MVS dataset (gdg if you like) and re-initialize a new syslogd file. Then you can use your standard MVS dataset retention to manage your syslogd archives. -- 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
Gerhard Postpischil wrote: This could be done except for TSO, due to unfortunate dependences on both the high and low portion of the data set name. The designers, in their infinite wisdom, chose to define the PSCB to contain a 7-byte user id (or user specified prefix), followed by a one byte length. Indeed. I have a re-look at my ISPF Exit 16, and found that if you change any limits on HLQ (and others too) that exit (and others which allocate datasets) will not work. It is about [somewhat clumsy] usage of PREFIX. Paul Gilmartin wrote: Under TSO, I was able to allocate a data set with both HLQ and LLQ of 8 characters; edit it (with ISPF) and browse it. I couldn't catalog it because I don't know of an 8-character HLQ to which I have access, but I believe that's an administrative limitation, not anything imposed by the OS. This is a good example of not letting the limitations of one component (TSO) impose a restriction on many others. I believe you can do that with 8 char HLQ, but I need to test it too. About raising length limits of HLQ, you will have to redesign RACF, JES2 and modules used to allocate temp dsn. I'm eagerly waiting for the support to grow. Me too. :-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curiosity: ETXR exit code (ATTACHX macro)
Gerhard Postpischil wrote: While it was a different set of exits, I was asked to diagnose an 0Cx of a commercial product on the market since the mid-seventies - two exits were invoked concurrently, and they used the same save area! Ouch, you tamed that angry beast! Wow! ;-D Just curious, how were they called in the first place? Could you say how the save area was set up and what type of call was made? Did they use the save area as passed, or did they copied it to their own GETMAINed area and then continue working? If you don't mind, please. Groete / Greetings Elardus Engelbrecht -- 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 Sat, 30 Nov 2013 08:25:50 -0600, Elardus Engelbrecht wrote: I believe you can do that with 8 char HLQ, but I need to test it too. About raising length limits of HLQ, you will have to redesign RACF, JES2 and modules used to allocate temp dsn. Is the limit HLQ or TSO prefix? On a quick glance, I don't see any catalogued data sets with an 8-character HLQ. Do catalog services enforce a limit of 7? Does the synax of a temp DSN matter much? I consider it rather an opaque object. I'm eagerly waiting for the support to grow. Me too. :-) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 28 Nov 2013 to 29 Nov 2013 (#2013-333)
On Fri, 29 Nov 2013 20:08:59 -0600, Fred Kaptein wrote: Date:Fri, 29 Nov 2013 11:37:32 -0600 From:Fred Kaptein fred.kapt...@hp.com Subject: Re: CRONTAB and SYSLOGD Hello, We are looking for the statements to insert into /etc/syslog.conf to do the following - retain the unix syslog in a file directory /xxx/ (we have not yet decided on a directly, but please let us know if there is an IBM recommended directory) - only retain 30 days of the unix syslog data (it is not important if the data is lost across IPLS) Thank you. Strangely enough the SYSLOGD configuration information is in the z/OS Communications Server: IP Configuration Reference Jim Holloway - Metropolitan Life Insurance Co The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CRONTAB and SYSLOGD
On Fri, Nov 29, 2013 at 11:37 AM, Fred Kaptein fred.kapt...@hp.com wrote: Hello, We are looking for the statements to insert into /etc/syslog.conf to do the following - retain the unix syslog in a file directory /xxx/ (we have not yet decided on a directly, but please let us know if there is an IBM recommended directory) - only retain 30 days of the unix syslog data (it is not important if the data is lost across IPLS) Thank you. SYSLOG Daemon setup chapter. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b4a0/21.0 #cat /etc/syslog.conf #z/OS UNIX syslog daemon configuration file. ArchiveInterval 60 #check UNIX free space every hour ArchiveThreshhold 70 #archive if filesytem is 70% used ArchiveTimeOfDay 00:00 #archive at midnight BeginArchiveParms DSNPrefix GDGHLQ.UNIX.SYSLOG UNIT SYSDA EndArchiveParms daemon.* /var/log/daemon.%Y-%m-%d -N DAEMON(+1) local0.* /var/log/local0.%Y-%m-%d -N LOCAL0(+1) # Repeat change for other facilities REF: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b4a0/21.5.2.1 # create crontab entry as root to do kill -HUP $(cat /etc/syslog.pid) command at midnight. # that will switch the syslog daemon files at midnight to a new file name. The %Y-%m-%d is changed # by the syslog daemon to the current 4 digit year, dash, 2 digit month, dash, 2 digit day of month when it gets # the kill command. The ArchiveParms allow you to offload the UNIX files into various z/OS GDGs or sequential data sets if you want. The example is to disk, but you could offload to a virtual tape or a tape library. I would highly suggest that if you do this, that you make the data sets SMS managed so that your ACS routines can set the storage class and management class. This will allow SMS to allocate the DSN properly and DFHSM, perhaps, to manage any disk resident data sets. -- 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Paul Gilmartin wrote: Is the limit HLQ or TSO prefix? On a quick glance, I don't see any catalogued data sets with an 8-character HLQ. Do catalog services enforce a limit of 7? No. Limit of 7 chars are for TSO ids only. Of course that limit are propagated to datasets starting with TSO ids. I could create/catalog/edit this example (all 3 qualifiers are 8 chars long): (on my sandbox, after I created temp RACF profile ZOS12ZOS.*, and no this is NOT my TSO id!) Data Set Name . . . . : ZOS12ZOS.ELARDUSE.ZOS12ZOS General Data Current Allocation Management class . . : MC Allocated cylinders : 1 Storage class . . . : SC... Allocated extents . : 1 Volume serial . . . : .. + Device type . . . . : 3390 Data class . . . . . : DC Organization . . . : PS Current Utilization Record format . . . : FB Used cylinders . . : 1 Record length . . . : 80 Used extents . . . : 1 Block size . . . . : 27920 1st extent cylinders: 1 Secondary cylinders : 1 Dates Data set name type : Creation date . . . : 2013/11/30 SMS Compressible. . : NO Referenced date . . : 2013/11/30 Expiration date . . : ***None*** Some 3th party tools are using 8 char HLQ. Now, off to delete all these on my sandbox. ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curiosity: ETXR exit code (ATTACHX macro)
On 11/30/2013 9:32 AM, Elardus Engelbrecht wrote: Just curious, how were they called in the first place? Could you say how the save area was set up and what type of call was made? Did they use the save area as passed, or did they copied it to their own GETMAINed area and then continue working? The product had a common work area that included one save area. Both exits used that common save area rather than a dynamic one (one was a system exit, the other a VTAM logon). 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: Curiosity: ETXR exit code (ATTACHX macro)
I believe that there is no deferral. Unless RTM is terminating a higher task, lower tasks can terminate in parallel and if it's time for an ETXR to run, the IRB will be scheduled. If that happens to interrupt a previous ETXR, so be it. If you want to see if one interrupts another, you could also have the first wait on an ECB that never gets posted and see if any of the others run. (Assuming you don't mind a hung mother task for a test) I have not tried this. 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: Un-authorized caller calling authorized services.
On Sat, 30 Nov 2013 14:08:39 -0600 Jim Thomas j...@thethomasresidence.us wrote: :I have an authorized service that I've written but needs to be able to allow un-authorized callers :to use. :Could anybody please provide any direction on the best way to implement this ??. I've already :looked at PC's (which might be fine) and having a server type address space (not something I :want to do). :I just want to use an acceptable API or venue of sorts. First question: your shop or commercial? If your shop, why not the old-fashioned SVC? Simple set-up. A PC is your other choice and unless you do tricky stuff will need a server address space as its owner. Under TSO, you can use the parallel TMP -- 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: Un-authorized caller calling authorized services.
Binyamin, Thank you for your reply. Commercial product and I don't want to use a SVC. I'm kinda leaning toward a PC but was hoping there was an easier way. This will (for the most part ..) be purely batch.,.. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Saturday, November 30, 2013 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. On Sat, 30 Nov 2013 14:08:39 -0600 Jim Thomas j...@thethomasresidence.us wrote: :I have an authorized service that I've written but needs to be able to allow un-authorized callers :to use. :Could anybody please provide any direction on the best way to implement this ??. I've already :looked at PC's (which might be fine) and having a server type address space (not something I :want to do). :I just want to use an acceptable API or venue of sorts. First question: your shop or commercial? If your shop, why not the old-fashioned SVC? Simple set-up. A PC is your other choice and unless you do tricky stuff will need a server address space as its owner. Under TSO, you can use the parallel TMP -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCBJLB doesn't point to a DCB
The documentation says the TCBJLB points to a DCB of the first library searched for a LOAD module for a program running under that task If it says exactly that with no qualification elsewhere, it could be clarified to say when not 0. Also, the DCB may represent a concatenation not an individual library. It is true that that will be the first library (or libraries) searched, when a usable copy is not found already-loaded. I have looked at various TCB's PSATOLD ASXBFTCB and if that address were a DCB at offset X'28' there would be a CL8 DDname various TCB's PSATOLD ASXBFTCB is not something that makes sense to me. As others have mentioned, it is untrue that DCB offset x'28' will ever have a DDNAME if it is opened. And any joblib/steplib/tasklib will be open (and better stay open). Are you aware that ASXBFTCB is not a program task? It is a system task (the RCT task). It will always have a zero TCBJLB as will some of the other early-in-address space tasks (as no joblib/steplib could yet have been defined, and no tasklib is used) such as the dump task. TCBJLB will be 0 when there is no joblib/steplib/tasklib. 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: Un-authorized caller calling authorized services.
There are a number of things you need to do to prevent an integrity exposure. At one point I saw a presentation by IBM on this, but right now I can't place my hands on it. If I do find it, I will post it. Here are the main points of it, as I remember them. - Don't ever read data from a caller's address space when you are not in the caller's key. As an SVC or PC your routine can be entered in key zero/supervisor state, I.E. you are a god and can do anything you want. - Don't EVER, EVER write data to a caller's address space when you are not in the caller's key. - You may have written the routine for your exclusive use, but don't assume/think/hope that no one else is going to find it. Someone will and then they will try to exploit it or use it for nefarious purposes. - TPROT data areas to be referenced. Let's assume the interface calls for R1 pointing to a two word parameter list. First of all, the words pointed to by R1 may be outside of his address space, so you want to verify their location is valid. Then the individual parms may or may not point to valid data in his address space. The original presentation went into about 10 different ways a nefarious user can try to get your valid routine to do something bad. Maybe Peter Relson has access to it and can post it. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Thomas Sent: Saturday, November 30, 2013 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. Forgive me, I have an authorized service that I've written but needs to be able to allow un-authorized callers to use. Could anybody please provide any direction on the best way to implement this ??. I've already looked at PC's (which might be fine) and having a server type address space (not something I want to do). I just want to use an acceptable API or venue of sorts. Lastly, a while back, I'd posted an email asking how to get a product SMP/E instable and while I never got any responses per se, I did get one offline email from someone that faced the same issues as I did. To that person, if you happen to read this, please re-contact me offline. I apologize but I lost your email but have some information for you. Kind Regards. Jim Thomas j...@thethomasresidence.us -- 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
I having been using BLDL to get program directory information I found the macro to not give correct results. May I plead that posters post more than just it does not work? The actual bad result is very important to those who are listening and trying to help. Using TCBJLB as the input DCB For DESEREV I get a return code of X'0C' reason X'421' invalid DCB If any service says that an input is invalid, it is always worth eliminating the possibility that the invocation did not result in providing valid input. If a valid DCB is used, it will not indicate invalid DCB. A first guess is always that the invocation was off by a level of indirection. Not showing the expansion can lead only to conjecture on the part of the responders, as opposed to leading more directly to something helpful. As for DESERVE, it would appear that linklist DCB's don't get special treatment Both BLDL and DESERV do special-case the LNKLST DCB, at least to some extent. BLDL also special cases a value of 0. I don't know about DESERV. 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: Un-authorized caller calling authorized services.
Chris, Thank you for your reply sir ... I concur w/your suggestions and no, I am not and will not do so. That said, w/regard to TPROT, I've had a localized routine that I wrote before the hardware got involved. Again, thank you for your suggestions. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Saturday, November 30, 2013 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. There are a number of things you need to do to prevent an integrity exposure. At one point I saw a presentation by IBM on this, but right now I can't place my hands on it. If I do find it, I will post it. Here are the main points of it, as I remember them. - Don't ever read data from a caller's address space when you are not in the caller's key. As an SVC or PC your routine can be entered in key zero/supervisor state, I.E. you are a god and can do anything you want. - Don't EVER, EVER write data to a caller's address space when you are not in the caller's key. - You may have written the routine for your exclusive use, but don't assume/think/hope that no one else is going to find it. Someone will and then they will try to exploit it or use it for nefarious purposes. - TPROT data areas to be referenced. Let's assume the interface calls for R1 pointing to a two word parameter list. First of all, the words pointed to by R1 may be outside of his address space, so you want to verify their location is valid. Then the individual parms may or may not point to valid data in his address space. The original presentation went into about 10 different ways a nefarious user can try to get your valid routine to do something bad. Maybe Peter Relson has access to it and can post it. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Thomas Sent: Saturday, November 30, 2013 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. Forgive me, I have an authorized service that I've written but needs to be able to allow un-authorized callers to use. Could anybody please provide any direction on the best way to implement this ??. I've already looked at PC's (which might be fine) and having a server type address space (not something I want to do). I just want to use an acceptable API or venue of sorts. Lastly, a while back, I'd posted an email asking how to get a product SMP/E instable and while I never got any responses per se, I did get one offline email from someone that faced the same issues as I did. To that person, if you happen to read this, please re-contact me offline. I apologize but I lost your email but have some information for you. Kind Regards. Jim Thomas j...@thethomasresidence.us -- 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: Curiosity: ETXR exit code (ATTACHX macro)
On Nov 30, 2013 3:10 PM, Peter Relson rel...@us.ibm.com wrote: I believe that there is no deferral. Unless RTM is terminating a higher task, lower tasks can terminate in parallel and if it's time for an ETXR to run, the IRB will be scheduled. If that happens to interrupt a previous ETXR, so be it. If you want to see if one interrupts another, you could also have the first wait on an ECB that never gets posted and see if any of the others run. (Assuming you don't mind a hung mother task for a test) I have not tried this. Peter Relson z/OS Core Technology Design Thanks to all. I will remember to write my exits as thread safe code, reentrant (not real sure how they differ), and non-self modifying with appropriate use of serialization for storage which is not thread local (STORAGE OBTAIN or equivalent). May be over kill (hi NSA!), but is likely to be less bother. I prefer to code consistently, which is why my HLASM code is now LE enabled whenever possible. -- 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.
You may find this useful: https://public.dhe.ibm.com/partnerworld/pub/misc/coding_for_system_integrity_in_zOS_for_isvs.pdf#! --Art Celestini At 05:11 PM 11/30/2013, Jim Thomas wrote: Chris, Thank you for your reply sir ... I concur w/your suggestions and no, I am not and will not do so. That said, w/regard to TPROT, I've had a localized routine that I wrote before the hardware got involved. Again, thank you for your suggestions. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Saturday, November 30, 2013 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. There are a number of things you need to do to prevent an integrity exposure. At one point I saw a presentation by IBM on this, but right now I can't place my hands on it. If I do find it, I will post it. Here are the main points of it, as I remember them. - Don't ever read data from a caller's address space when you are not in the caller's key. As an SVC or PC your routine can be entered in key zero/supervisor state, I.E. you are a god and can do anything you want. - Don't EVER, EVER write data to a caller's address space when you are not in the caller's key. - You may have written the routine for your exclusive use, but don't assume/think/hope that no one else is going to find it. Someone will and then they will try to exploit it or use it for nefarious purposes. - TPROT data areas to be referenced. Let's assume the interface calls for R1 pointing to a two word parameter list. First of all, the words pointed to by R1 may be outside of his address space, so you want to verify their location is valid. Then the individual parms may or may not point to valid data in his address space. The original presentation went into about 10 different ways a nefarious user can try to get your valid routine to do something bad. Maybe Peter Relson has access to it and can post it. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Thomas Sent: Saturday, November 30, 2013 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. Forgive me, I have an authorized service that I've written but needs to be able to allow un-authorized callers to use. Could anybody please provide any direction on the best way to implement this ??. I've already looked at PC's (which might be fine) and having a server type address space (not something I want to do). I just want to use an acceptable API or venue of sorts. Lastly, a while back, I'd posted an email asking how to get a product SMP/E instable and while I never got any responses per se, I did get one offline email from someone that faced the same issues as I did. To that person, if you happen to read this, please re-contact me offline. I apologize but I lost your email but have some information for you. Kind Regards. Jim Thomas j...@thethomasresidence.us -- 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
Don't forget the hyphen and x'C0'. Tony's iPhone (with toy keyboard) is responsible for this Email. Please do not snicker. On Nov 29, 2013, at 8:37 PM, Mike Schwab mike.a.sch...@gmail.com wrote: A-Z@#$: 29 characters for the first character, plus 0-9 for up to 7 additional characters. 29 One character. 1,131 Two character. 44,109 Three character. 1,720,251 Four character. 67,089,789 Five character. 2,616,501,771 Six character. 102,043,569,069 Seven character. 3,979,699,193,691 Eight character. 4,084,428,119,840 1-8 character level. On Fri, Nov 29, 2013 at 12:49 PM, Gerhard Postpischil gerh...@valley.net wrote: On 11/29/2013 12:36 PM, Paul Gilmartin wrote: There is no limitation ... of ... 5 levels Hasn't been for a long time; perhaps never was. While I don't remember a 5-level limit, there always was (and will be?) a practical limit. Using every possible legal name, even at a single level, exhausts space available on any early DASD. 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Curiosity: ETXR exit code (ATTACHX macro)
At 16:10 -0500 on 11/30/2013, Peter Relson wrote about Re: Curiosity: ETXR exit code (ATTACHX macro): If you want to see if one interrupts another, you could also have the first wait on an ECB that never gets posted and see if any of the others run. Or just have the EXTR routine do a STIMER WAIT so other EXTRs can run if they are not single threaded. -- 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 Sat, 30 Nov 2013 21:53:06 + Blaicher, Christopher Y. cblaic...@syncsort.com wrote: :There are a number of things you need to do to prevent an integrity exposure. At one point I saw a presentation by IBM on this, but right now I can't place my hands on it. If I do find it, I will post it. Here are the main points of it, as I remember them. :- Don't ever read data from a caller's address space when you are not in the caller's key. As an SVC or PC your routine can be entered in key zero/supervisor state, I.E. you are a god and can do anything you want. :- Don't EVER, EVER write data to a caller's address space when you are not in the caller's key. :- You may have written the routine for your exclusive use, but don't assume/think/hope that no one else is going to find it. Someone will and then they will try to exploit it or use it for nefarious purposes. :- TPROT data areas to be referenced. If you do the above, the TPROT is superfluous. And if you do not, realize that unless appropriately locked, the results may no longer be valid when you try to use it. -- 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: Un-authorized caller calling authorized services.
Sir/s et'al, My service is a SRB and given, SRBPARM, will be executing some code that I am given. No, there will not be any I/O and such, I am adhering to the rules of a SRB. That said, the 'code' that I am passed will be referencing and updating storage that will ultimately be hardened after I am done and pass control back to my caller. My main issue was to find out ways on how I can be called, given that my caller would be un-authorized. Binyamin. Chris and others have stated very good points and what to watch out for. Art I thank you for the .PDF that you referenced. In a nutshell, I'm trying to find out what the best way is for an un-authorized called to call / invoke a SRB. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Saturday, November 30, 2013 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. On Sat, 30 Nov 2013 21:53:06 + Blaicher, Christopher Y. cblaic...@syncsort.com wrote: :There are a number of things you need to do to prevent an integrity exposure. At one point I saw a presentation by IBM on this, but right now I can't place my hands on it. If I do find it, I will post it. Here are the main points of it, as I remember them. :- Don't ever read data from a caller's address space when you are not in the caller's key. As an SVC or PC your routine can be entered in key zero/supervisor state, I.E. you are a god and can do anything you want. :- Don't EVER, EVER write data to a caller's address space when you are not in the caller's key. :- You may have written the routine for your exclusive use, but don't assume/think/hope that no one else is going to find it. Someone will and then they will try to exploit it or use it for nefarious purposes. :- TPROT data areas to be referenced. If you do the above, the TPROT is superfluous. And if you do not, realize that unless appropriately locked, the results may no longer be valid when you try to use it. -- 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 -- 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
That's correct and that's where I took the idea from. That concept needs improvements No doubt, but so far you haven't identified any defect that a new type of catalog would resolve. I have identified the defect pretty well, except that you refuse to see that definition and go to circular arguments about semantics! I will explain rather than define: In z/OS you are confined to 44 characters and limited to however many levels could be expressed within that limit, but you do not need to tell the system where the file resides because that information is stored in the catalog. In Unix, you do not have those length and level limitations, but you need to be explicit in describing where the file is or go through the trouble of creating symbolic links. Both sides are awkward, require too much memorization and each one has a glaring defect as identified above. With the envisioned catalog, file names are not limited in length or form, yet the system would know where do they reside. In case of two (or more) files that share the same name, a sophisticated implementation may either decide by context (e.g. a file that is owned by the requester would be preferred to file owned by somebody else - THIS IS ONLY AN EXAMPLE, PLEASE DO NOT GET INTO SEMANTICS), or ask to disambiguate (e.g. supply only one level that is different between the files - AGAIN, THIS IS ONLY AN EXAMPLE, PLEASE DO NOT GET INTO SEMANTICS) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
