Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
There is a restaurant near me here, just west of Boston in the United States, that serves 'fusion cuisine', its dishes are a mixture of the ingredients and techniques of Greek, Indochinese, and French cuisine. Some of these dishes are successful, but too many are not: their menu descriptions read well, but they do not really work. Analogously, combining attractive features from UNIX and [different] attractive features from z/OS may sometimes yield a viable, powerful new facility. Often, however, it will not; and Shmuel is right to be concerned about and suspicious of the semantics of such 'unholy combinations'. Ze'ev appears to me to want to graft what are essentially interactive, conversational facilities onto JCL, which is a batch facility. This may well be possible, but doing it will require careful thought and much experimentation/evolutionary operation. Meanwhile, psittacism featuring the numbers 8 and 44 will not be helpful. They are not really the problem. 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: Un-authorized caller calling authorized services.
Jim My advice would be to have a resource owning server that the batch caller would be a client of. The client invokes a PC owned by the server that performs some sort of SAF check before using IEAMSCHD to run the SRB in the client. Personally I would use a PC-ss and a task level RESMGR routine to protect your caller. MVCSK and MVCDK are your friends to read from and write to caller storage when the server key does not match the client caller. Rob Scott Rocket Software On 1 Dec 2013, at 02:25, Jim Thomas j...@thethomasresidence.us wrote: 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 -- 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
Ze'ev appears to me to want to graft what are essentially interactive, conversational facilities onto JCL, which is a batch facility. This may well be possible, but doing it will require careful thought and much experimentation/evolutionary operation. I already concluded that the z/OS side may be hopeless because the limitations of file name are too entrenched in the OS. The Unix side (especially Linux that is open source) is a better candidate. No, I do not envision batch oriented only features. Once the file is committed in the traditional way (conversational or batch), its location would be known, so when you say in the shell (AND THIS IS ONLY ONE EXAMPLE): cp filename ~/myfolder/myappfolder filename will be found regardless of where it is. If filename is common among few files, the system may guess, using some algorithm (that indeed, needs much experimentation/evolutionary operation in its development) which one you need. Otherwise, you might be required to say (AND THIS IS ONLY ONE EXAMPLE): cp --ppath myapp1 --date 01/01/2013-02/15/2013 filename ~/myfolder/myappfolder If one bothers to give unique names and if the algorithm for dis-ambiguity would be good, the first example would prevail most of the time. Please forgive the yelling (AND THIS IS ONLY ONE EXAMPLE). While obviously we need people to question all possible details so they would be answered and thought about in the aforementioned algorithm. I do not want people to shoot the idea down just because I referred to only one example. I begin to have fun in toying this ides! ZA -- 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
TSO appends a prefix of your userid to your data set name unless you specify quotes. Other operating systems assume the http://en.wikipedia.org/wiki/Home_directory , Working in a shell or script, you can the current directory then you work within that directory. Windows shortcuts can specify which directory is the default directory when you run that program. Pick an appropriate method and live with it, or specify the full directory path. On Sun, Dec 1, 2013 at 12:20 AM, Ze'ev Atlas zatl...@yahoo.com wrote: 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 -- 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
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
TSO appends a prefix of your userid to your data set name unless you specify quotes. Don't forget PROFILE NOPREFIX - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- 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/1/2013 9:27 AM, Mike Schwab wrote: TSO appends a prefix of your userid to your data set name unless you specify quotes. Sometimes. The value that is prepended is the user id only by default, as the user may set a prefix of 1-7 characters. 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Ahhh. So you want the system to find the file filename *anywhere that it exists* when you say *verb* filename? Hmm. Do I want that? Do I want what worked fine yesterday to stop working today because a download or unzip created a new filename? Even disambiguation via prompts would be extremely irritating. I might be interested in a proposal to make the path more pervasive -- so it would pick up the first filename in the path *on any command*, sort of like globbing. Haven't really thought that through, but it would at least be predictable (modulo the same problem of Yesterday, it picked up one version of 'filename', in the third directory in my path, and today it picks up another, in the second directory in my path, but that's at least easy to figure out). Let me back it up a level: what's the problem you're trying to solve? Are you trying to make things more user-friendly? I submit that the unpredictability this introduces would have the opposite effect. On Sun, Dec 1, 2013 at 9:21 AM, Ze'ev Atlas zatl...@yahoo.com wrote: Ze'ev appears to me to want to graft what are essentially interactive, conversational facilities onto JCL, which is a batch facility. This may well be possible, but doing it will require careful thought and much experimentation/evolutionary operation. I already concluded that the z/OS side may be hopeless because the limitations of file name are too entrenched in the OS. The Unix side (especially Linux that is open source) is a better candidate. No, I do not envision batch oriented only features. Once the file is committed in the traditional way (conversational or batch), its location would be known, so when you say in the shell (AND THIS IS ONLY ONE EXAMPLE): cp filename ~/myfolder/myappfolder filename will be found regardless of where it is. If filename is common among few files, the system may guess, using some algorithm (that indeed, needs much experimentation/evolutionary operation in its development) which one you need. Otherwise, you might be required to say (AND THIS IS ONLY ONE EXAMPLE): cp --ppath myapp1 --date 01/01/2013-02/15/2013 filename ~/myfolder/myappfolder If one bothers to give unique names and if the algorithm for dis-ambiguity would be good, the first example would prevail most of the time. Please forgive the yelling (AND THIS IS ONLY ONE EXAMPLE). While obviously we need people to question all possible details so they would be answered and thought about in the aforementioned algorithm. I do not want people to shoot the idea down just because I referred to only one example. I begin to have fun in toying this ides! ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- 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.
TPROT TPROT can tell you it is not OK. It almost never can tell you fully it is OK because of time-of-check to time-of-use exposures. In a nutshell, I'm trying to find out what the best way is for an un-authorized called to call / invoke a SRB. Not only is there no best way there is no way. You cannot call or invoke an SRB. You can only schedule an SRB. And scheduling an SRB is limited to authorized programs. Thus an unauthorized program would have to get authorized (such sa via SVC or PC) in order to schedule an SRB. It is also the case that, if you do allow an unauthorized program to invoke an SVC/PC to schedule an SRB, you might need to provide some throttle to prevent a malicious unauthorized program from doing this too often. 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
On Sun, Dec 1, 2013 at 9:30 AM, zMan zedgarhoo...@gmail.com wrote: Ahhh. So you want the system to find the file filename *anywhere that it exists* when you say *verb* filename? Hmm. Do I want that? Do I want what worked fine yesterday to stop working today because a download or unzip created a new filename? Even disambiguation via prompts would be extremely irritating. I still like using the Linux locate command for this. It does a data base lookup, which is maintained non-real-time via updatedb, and presents a list of entire path names which match the given input. I may need to look at getting the source and seeing if I can port it to z/OS UNIX. I might be interested in a proposal to make the path more pervasive -- so it would pick up the first filename in the path *on any command*, sort of like globbing. Haven't really thought that through, but it would at least be predictable (modulo the same problem of Yesterday, it picked up one version of 'filename', in the third directory in my path, and today it picks up another, in the second directory in my path, but that's at least easy to figure out). Let me back it up a level: what's the problem you're trying to solve? Are you trying to make things more user-friendly? I submit that the unpredictability this introduces would have the opposite effect. -- 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.
It might be helpful to have the OP tell us _exactly_ what authorized function he needs to be done on behalf of his unauthorized user program. Perhaps there is another way to get 'er done. -- 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 20:25:36 -0600, Jim Thomas j...@thethomasresidence.us wrote: My service is a SRB and given, SRBPARM, will be executing some code that I am given. That sounds extremely unsafe, from a system integrity perspective. In general you cannot depend on an unauthorized caller to give you code that is safe to run in an authorized state. It can be safe for an unauthorized caller to request you to do a particular function, if you check the parameters fully and if all the actual code that you will run is contained within (built into) your authorized function. But if the unauthorized caller is providing the code that will run then you will need to provide a lot more information about exactly what the unauthorized caller is before we can give any advice on how you can do that safely. And it is quite likely that there is no safe way for you to do it. So, more details, please. -- Walt -- 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
Let me back it up a level: what's the problem you're trying to solve? Are you trying to make things more user-friendly? I submit that the unpredictability this introduces would have the opposite effect. This is the kind of reaction that I am waiting for, pointing to things that need to be answered rather than sticking with the existing model(s). I admit of not thinking the dis-ambiguity model through all the way yet (this conversation is my first attempt of expressing the issue). And unpredictability is for sure a show stopper. I will think about it and I ask anybody who may view this ideas as positive to think about it as well. Thanks ZA -- 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
I still like using the Linux locate command for this. It does a data base lookup, which is maintained non-real-time via updatedb, and presents a list of entire path names which match the given input. I may need to look at getting the source and seeing if I can port it to z/OS UNIX. Locate/updatedb is probably the closest to what I want and we could base that functionality on it, but why can't we improve it to be yes-real-time? ZA -- 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 16:55:58 -0600, Anthony Babonas wrote: Don't forget the hyphen and x'C0'. Hyphen is strange. JCL allows hyphen in data set names in some contexts; reports it as a syntax error elsewhere. I believe this is documented. ISPF LM services allows hyphen in member names in some contexts; reports it as a syntax error elsewhere. Is there any rationale for this erratic behavior? Conway's Law? I understand that x'C0' was a mistake. A coder wrote some sequence of CVD and UNPK, forgetting to repair the sign nybble (perhaps in SVC numbers?) It was immediately recognized as too deeply embedded to repair, and institutionalized. I'm not an assembler programmer. Mentally, I can't envision the exact instruction sequence or should have been. With a brief exposure to MVS, I started to learn CMS. I was shocked (briefly) to learn that file names might begin with numeric digits; in fact be entirely numeric. Why not in OS/360 data set names? In an era of severe storage and CPU cycle constraints, the lexical analyzer would have been simpler for not needing to treat the first character specially. Would allowing numeric data set names have introduced a syntactic ambiguity in JCL or elsewhere? Member names couldn't unambiguously be numeric because of GDG levels. Earlier in this thread, someone did some arithmetic showing that the current data set name conventions allow more data sets than could be stored on any current or reasonably envisioned volume. Therefore there's no rationale for enlarging the name space. Beware such arguments based on name space cardinality -- I suspect that there would be enough available data set names if only letters in the first third of the alphabet were permitted, so why allow any more? Becayse some programmers like the flexibility. I would like the flexibility of lower case alphabetics. -- gil -- 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
unfortunately DESERV FUNC=GET needs a real DCB address as opposed to the zero used invoking BLDL You need to supply a DCB address that represents a concatenation in which the member for which you are seeking the directory entry exists. BLDL happens to support 0 as asking to search tasklib(s) steplib/joblib lnklst DESERV does not. TCBJLB of the jobstep program task is either joblib or steplib. TCBJLB of subtasks of that task, when different, is a tasklib. So where is the member? If it's in the lnklst, then use the DCB pointed to by CVTLINK. If you don't know where it is, then you may need to do what the system does to locate a module: search every tasklib up to/through the ASCBXTCB TCB using its DCB search the LNKLST using its DCB And if that's not where your member is, then you need to search where it is. In some situations, for example, ISPLLIB is used not as a tasklib. Of course it was not even stated why BLDL was being used. In some scenarios, it is necessary first to eliminate the possibility that the module is in LPA and not the LNKLST (perhaps by CSVQUERY). 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: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
PROF NOPRE? In a message dated 12/1/2013 9:09:20 A.M. Central Standard Time, gerh...@valley.net writes: Sometimes. The value that is prepended is the user id only by default, as the user may set a prefix of 1-7 characters. -- 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
Thanks for your help Two questions Does BLDL or DESERV have anyway of differentiating between TASKLIB/STEPLIB/JOBLIB I think not. TCBJLIB represents the first library looked at be it TASK STEP or JOB Second is there anyway of getting the associated DSN name Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, December 01, 2013 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DESERV function get DCB address unfortunately DESERV FUNC=GET needs a real DCB address as opposed to the zero used invoking BLDL You need to supply a DCB address that represents a concatenation in which the member for which you are seeking the directory entry exists. BLDL happens to support 0 as asking to search tasklib(s) steplib/joblib lnklst DESERV does not. TCBJLB of the jobstep program task is either joblib or steplib. TCBJLB of subtasks of that task, when different, is a tasklib. So where is the member? If it's in the lnklst, then use the DCB pointed to by CVTLINK. If you don't know where it is, then you may need to do what the system does to locate a module: search every tasklib up to/through the ASCBXTCB TCB using its DCB search the LNKLST using its DCB And if that's not where your member is, then you need to search where it is. In some situations, for example, ISPLLIB is used not as a tasklib. Of course it was not even stated why BLDL was being used. In some scenarios, it is necessary first to eliminate the possibility that the module is in LPA and not the LNKLST (perhaps by CSVQUERY). 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 -- 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
Confusion seems rampant. Please post the hexadecimal display of the first 48 (decimal 48, or hex '30') bytes of the TCB in question. Then post the same number of bytes at the beginning of the DCB in question. Bill Fairchild Franklin, TN - Original Message - From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, November 29, 2013 3:55:40 PM Subject: Re: TCBJLB doesn't point to a DCB In 5737414652770988.wa.woodagozemail.com...@listserv.ua.edu, on 11/29/2013 at 11:25 AM, Andy Wood woo...@ozemail.com.au said: Why would you expect a TCB to match the DCB DSECT? Clearly, at that point he is talking about TCB+X'28, not DCB+X'28'. Whoops! That would be a 24-bit address, not a 31-bit address, and bits 0-7 should be zeroed. Which still leaves the question of whether DESERVE will make a special case of the linklist DCB. -- 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
I was confused by the documentation DCB= is the address where the DCB resides so Instead of coding MVC WSDCB,TCBJLB DCB= is a parm on the DESERV DCB=WSDCB, I coded L RX,TCBJLB DCB=(RX), That worked When the TASK/STEP/JOB is specified I get X'05' for both BLDL Or DESERV for the library is found in When its in the LINKLIST I get a X'01' correctly so indicating linklist For both BLDL/DESERV -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Sunday, December 01, 2013 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TCBJLB doesn't point to a DCB Confusion seems rampant. Please post the hexadecimal display of the first 48 (decimal 48, or hex '30') bytes of the TCB in question. Then post the same number of bytes at the beginning of the DCB in question. Bill Fairchild Franklin, TN - Original Message - From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, November 29, 2013 3:55:40 PM Subject: Re: TCBJLB doesn't point to a DCB In 5737414652770988.wa.woodagozemail.com...@listserv.ua.edu, on 11/29/2013 at 11:25 AM, Andy Wood woo...@ozemail.com.au said: Why would you expect a TCB to match the DCB DSECT? Clearly, at that point he is talking about TCB+X'28, not DCB+X'28'. Whoops! That would be a 24-bit address, not a 31-bit address, and bits 0-7 should be zeroed. Which still leaves the question of whether DESERVE will make a special case of the linklist DCB. -- 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: Un-authorized caller calling authorized services.
Peter ... my apologies .. I used the wrong terminology. May I please contact you offline on this ??. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, December 01, 2013 9:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. TPROT TPROT can tell you it is not OK. It almost never can tell you fully it is OK because of time-of-check to time-of-use exposures. In a nutshell, I'm trying to find out what the best way is for an un-authorized called to call / invoke a SRB. Not only is there no best way there is no way. You cannot call or invoke an SRB. You can only schedule an SRB. And scheduling an SRB is limited to authorized programs. Thus an unauthorized program would have to get authorized (such sa via SVC or PC) in order to schedule an SRB. It is also the case that, if you do allow an unauthorized program to invoke an SVC/PC to schedule an SRB, you might need to provide some throttle to prevent a malicious unauthorized program from doing this too often. 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 -- 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.
Walt, As w/my request to Peter, may I please contact you offline ??. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Sunday, December 01, 2013 10:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. On Sat, 30 Nov 2013 20:25:36 -0600, Jim Thomas j...@thethomasresidence.us wrote: My service is a SRB and given, SRBPARM, will be executing some code that I am given. That sounds extremely unsafe, from a system integrity perspective. In general you cannot depend on an unauthorized caller to give you code that is safe to run in an authorized state. It can be safe for an unauthorized caller to request you to do a particular function, if you check the parameters fully and if all the actual code that you will run is contained within (built into) your authorized function. But if the unauthorized caller is providing the code that will run then you will need to provide a lot more information about exactly what the unauthorized caller is before we can give any advice on how you can do that safely. And it is quite likely that there is no safe way for you to do it. So, more details, please. -- Walt -- 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
Michel, Can you impart a big more information on what your trying to accomplish ? Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 1, 2013, at 2:03 PM, MichealButz michealb...@optonline.net wrote: Thanks for your help Two questions Does BLDL or DESERV have anyway of differentiating between TASKLIB/STEPLIB/JOBLIB I think not. TCBJLIB represents the first library looked at be it TASK STEP or JOB Second is there anyway of getting the associated DSN name Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, December 01, 2013 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DESERV function get DCB address unfortunately DESERV FUNC=GET needs a real DCB address as opposed to the zero used invoking BLDL You need to supply a DCB address that represents a concatenation in which the member for which you are seeking the directory entry exists. BLDL happens to support 0 as asking to search tasklib(s) steplib/joblib lnklst DESERV does not. TCBJLB of the jobstep program task is either joblib or steplib. TCBJLB of subtasks of that task, when different, is a tasklib. So where is the member? If it's in the lnklst, then use the DCB pointed to by CVTLINK. If you don't know where it is, then you may need to do what the system does to locate a module: search every tasklib up to/through the ASCBXTCB TCB using its DCB search the LNKLST using its DCB And if that's not where your member is, then you need to search where it is. In some situations, for example, ISPLLIB is used not as a tasklib. Of course it was not even stated why BLDL was being used. In some scenarios, it is necessary first to eliminate the possibility that the module is in LPA and not the LNKLST (perhaps by CSVQUERY). 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 -- 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
Sorry a 'bit' more Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 1, 2013, at 2:35 PM, Scott Ford scott_j_f...@yahoo.com wrote: Michel, Can you impart a big more information on what your trying to accomplish ? Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 1, 2013, at 2:03 PM, MichealButz michealb...@optonline.net wrote: Thanks for your help Two questions Does BLDL or DESERV have anyway of differentiating between TASKLIB/STEPLIB/JOBLIB I think not. TCBJLIB represents the first library looked at be it TASK STEP or JOB Second is there anyway of getting the associated DSN name Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, December 01, 2013 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DESERV function get DCB address unfortunately DESERV FUNC=GET needs a real DCB address as opposed to the zero used invoking BLDL You need to supply a DCB address that represents a concatenation in which the member for which you are seeking the directory entry exists. BLDL happens to support 0 as asking to search tasklib(s) steplib/joblib lnklst DESERV does not. TCBJLB of the jobstep program task is either joblib or steplib. TCBJLB of subtasks of that task, when different, is a tasklib. So where is the member? If it's in the lnklst, then use the DCB pointed to by CVTLINK. If you don't know where it is, then you may need to do what the system does to locate a module: search every tasklib up to/through the ASCBXTCB TCB using its DCB search the LNKLST using its DCB And if that's not where your member is, then you need to search where it is. In some situations, for example, ISPLLIB is used not as a tasklib. Of course it was not even stated why BLDL was being used. In some scenarios, it is necessary first to eliminate the possibility that the module is in LPA and not the LNKLST (perhaps by CSVQUERY). 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 -- 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
Two questions 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 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Sunday, December 01, 2013 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DESERV function get DCB address Sorry a 'bit' more Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 1, 2013, at 2:35 PM, Scott Ford scott_j_f...@yahoo.com wrote: Michel, Can you impart a big more information on what your trying to accomplish ? Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Dec 1, 2013, at 2:03 PM, MichealButz michealb...@optonline.net wrote: Thanks for your help Two questions Does BLDL or DESERV have anyway of differentiating between TASKLIB/STEPLIB/JOBLIB I think not. TCBJLIB represents the first library looked at be it TASK STEP or JOB Second is there anyway of getting the associated DSN name Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, December 01, 2013 1:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DESERV function get DCB address unfortunately DESERV FUNC=GET needs a real DCB address as opposed to the zero used invoking BLDL You need to supply a DCB address that represents a concatenation in which the member for which you are seeking the directory entry exists. BLDL happens to support 0 as asking to search tasklib(s) steplib/joblib lnklst DESERV does not. TCBJLB of the jobstep program task is either joblib or steplib. TCBJLB of subtasks of that task, when different, is a tasklib. So where is the member? If it's in the lnklst, then use the DCB pointed to by CVTLINK. If you don't know where it is, then you may need to do what the system does to locate a module: search every tasklib up to/through the ASCBXTCB TCB using its DCB search the LNKLST using its DCB And if that's not where your member is, then you need to search where it is. In some situations, for example, ISPLLIB is used not as a tasklib. Of course it was not even stated why BLDL was being used. In some scenarios, it is necessary first to eliminate the possibility that the module is in LPA and not the LNKLST (perhaps by CSVQUERY). 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 - - 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 -- 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
You keep telling us about an annoying limitation which is not a defect. I agree that at times, it is annoying but it has also proved to be very useful. Also as it age's the user's of the system is changing the pattern of usage. As z/OS ages, the typical end user doesn't know or care what a dataset is. (E.g. SaaS, CICS and IMS). How often do we have end users working with datasets or in TSO? As time goes on, exposure to DSN is more often programmer types who can learn these restrictions. These limitations has forced companies to form naming conventions that are specific, concise and easy to understand. Everyone is working on the same page. These limitations allow security admin to easily secure data as needed. These limitations allow dasd admins to control how storage is used. Extending DSN size would be expensive to implement. If this were truly impacting customers, someone would have built a method to allow extended DSN's. So back to the original question. What is the defect or requirement that will make z/OS far more useful so that its value will exceed it's cost and it's use will be widely adopted? Remember that customers will need to review and implement security changes. They will need to determine how they are affected by the change and QA the changes. Vendors will need to change their products. UNIX utilities will need to be implemented that manage uncontrolled files (e.g. grep and reg expressions for DSN search). DSN limitations are unlikely to change because it's impact outweighs it's advantage. Jon Perryman. From: Ze'ev Atlas zatl...@yahoo.com Ze'ev appears to me to want to graft what are essentially interactive, conversational facilities onto JCL, which is a batch facility. This may well be possible, but doing it will require careful thought and much experimentation/evolutionary operation. I already concluded that the z/OS side may be hopeless because the limitations of file name are too entrenched in the OS. The Unix side (especially Linux that is open source) is a better candidate. No, I do not envision batch oriented only features. Once the file is committed in the traditional way (conversational or batch), its location would be known, so when you say in the shell (AND THIS IS ONLY ONE EXAMPLE): -- 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
paulgboul...@aim.com (Paul Gilmartin) writes: With a brief exposure to MVS, I started to learn CMS. I was shocked (briefly) to learn that file names might begin with numeric digits; in fact be entirely numeric. Why not in OS/360 data set names? In an era of severe storage and CPU cycle constraints, the lexical analyzer would have been simpler for not needing to treat the first character specially. Would allowing numeric data set names have introduced a syntactic ambiguity in JCL or elsewhere? Member names couldn't unambiguously be numeric because of GDG levels. I periodically pontificated that the batch heritage systems were for the convenience of the systems ... while people might prepare the program ... batch characteristic was that the responsible person(s) usually wasn't around ... and it was important that many things be able to run w/o the responsible person present. this is a different paradigm from the online systems ... for instance linux traces to unix to multics to ctss ... while vm370/cms trace to cp67/cms to the same ctss ... and is much more oriented to the convenience of people ... not to the system ... with a person much more likely to be directly involved with running an application. the batch system heritage would focus much more on computer resource optimization than people resource optimization ... this was common refrain from the 60s up through much of the 80s by POK favorite son operating system people. also ms/dos http://en.wikipedia.org/wiki/MS-DOS before ms/dos there was seattle computer http://en.wikipedia.org/wiki/Seattle_Computer_Products and before seattle computer there was cp/m http://en.wikipedia.org/wiki/CP/M and before cp/m, kildall worked on cp67/cms at npg school (gone 404 but lives on at wayback machine) http://web.archive.org/web/20071011100440/http://www.khet.net/gmc/docs/museum/en_cpmName.html npg reference http://en.wikipedia.org/wiki/Naval_Postgraduate_School cp/67 reference http://en.wikipedia.org/wiki/CP/CMS -- virtualization experience starting Jan1968, online at home since Mar1970 -- 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
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. I suspect that this value of eight came from the maximum length of a PDS member name, also eight. This suspicion is heightened by the fact that the system structure holding PDS member name entries, namely a PDS directory block on DASD with key length 8 and block size 256, had the same characteristics as that of the original system structure holding cataloged data set name entries, namely a SYSCTLG data set with key length 8 and block size 256. The same channel program could be used to find a catalog block containing a given data set name or a PDS directory block with a given PDS member name. And the same code could be used to update one of such blocks (either add a new entry into a block with possible cascading effects for each subsequent block in the catalog or directory or delete an entry from one such block) once the channel program had located the proper block to be updated. Bill Fairchild Franklin, TN - Original Message - From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, November 29, 2013 4:05:19 PM Subject: Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers In cae1xxdesuckurytxfugpi7kz3fzsap2np4xcuk+1tavy93g...@mail.gmail.com, on 11/29/2013 at 02:16 PM, John Gilmore jwgli...@gmail.com said: Under OS/360 the notional, antetypical 'longest' index had the syntax level1.level2.level3.level4.level5 I can't speak for release 1, but certainly in OS/360 R14 there was no such limit. -- 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
COBOL IN SRB Mode (Was Un-authorized caller)
I initiallydid notfind this topic particularly interesting as it was basicaly responded too in the first few responses. (SVC/PC). I recently had a dispute with Management reagrding the uses of sceduling COBOL BATCH under an SRB. Thats Right a Batch COBOL Prpogram runing Under an SRB, moreover under CICS Transaction Server. A Software Vendor believes they can solve a program sharing issue by using SRBS to execute a Batch Cobol Progam. In a nut shell the user enters a basic CICS transaction code and a PC call is issued to a Server Address Spaces whose only responsibility is to SCHEDULE an SRB Back to the specific CICS Region. The SRB then executes a Batch COBOL program. I dont want to bore everyone with all the politics; such as we dont want to pay for Transactional VSAM, and we dont want to maintain 2 Versions of this program (Batch CICS). Mu collogue and I lost all the battles. I raise this issue to encourage some additional discussion. Again this is a VENDOR who has developing this facility. Paul D'ANgelo -- 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.
Rob, Yes, this was, in part, one of the options I'd been considering. I was however, trying to stay away from having to add a new address space to the product. I will take your suggestions and re-consider again. Yes, MVCS/DK is what I usually use, as much as possible. Thank you for your suggestions and advice. Kind Regards. Jim Thomas -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Sunday, December 01, 2013 8:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Un-authorized caller calling authorized services. Jim My advice would be to have a resource owning server that the batch caller would be a client of. The client invokes a PC owned by the server that performs some sort of SAF check before using IEAMSCHD to run the SRB in the client. Personally I would use a PC-ss and a task level RESMGR routine to protect your caller. MVCSK and MVCDK are your friends to read from and write to caller storage when the server key does not match the client caller. Rob Scott Rocket Software On 1 Dec 2013, at 02:25, Jim Thomas j...@thethomasresidence.us wrote: 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 -- 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)
In CAAJSdjgh6wfQ6EVWCc+8hYn5Un4yKPzr6Sj-up=b2qbjsfa...@mail.gmail.com, on 11/29/2013 at 06:57 PM, John McKown john.archie.mck...@gmail.com said: Suppose that I have a program which is heavily multitasking. There is the parent task and multiple subtasks, all direct children of the single parent. The ATTACHX macro uses the ETXR parameter, which specifies a single routine which does housekeeping of some sort. Also assume that the subtasks are being created and ending randomly. That is the main task is doing its thing, then a subtask ends and drives the ETXR code under the parent TCB (I think under an IRB). Yes. Now this can happen anywhere in the parent's main loop, so I know that I need to serialize properly between the main loop code and the ETXR code. Since the main loop is suspended while the exit is running, the synchronization requirements are different from those for asynchronous threads. You must use a technique that does not lock out the exit waiting for the main loop. if a second child terminates while the parent TCB is in the ETXR code for a child, will the ETXR code be interrupted and redriven for the newly terminating child TCB. Yes, except for privileged routines that have temporarily suppressed exits. -- 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 0905701904337885.wa.paulgboulderaim@listserv.ua.edu, on 11/30/2013 at 08:52 AM, Paul Gilmartin paulgboul...@aim.com said: Is the limit HLQ or TSO prefix? TSO limits the prefix to 7; for an explicit FQDSN it accepts an 8-character HLQ. Do catalog services enforce a limit of 7? No, nor does TSO. -- 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: Un-authorized caller calling authorized services.
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 - Don't EVER, EVER write data to a caller's address space when you are not in the caller's key. MVCK -- 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 offd075f55.0378370d-on85257c33.00748a02-85257c33.00796...@us.ibm.com, on 11/30/2013 at 05:05 PM, Peter Relson rel...@us.ibm.com said: A first guess is always that the invocation was off by a level of indirection. Or that it failed to clear bits 0-7 when required. -- 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
Helped perhaps by the fact that he knows what 'antetypical' means, Bill Fairchild has made my case better than I had made it. I did indeed have [some of] these notions in mind. The more recent development of this thread has pleased me. Vociferous, historically tin-eared objections have been very largely replaced by assertions of preference, e.g., for the usability of minuscules in some classes of names where only majuscules may now appear. It would be all but impossible to object to these wish lists for the relaxation of traditional formatting restrictions; and I do not; but neither are they, finally, very important. (What I earlier today called the psittacism involved--their too frequent, mindless repetition in tones of moral outrage--is objectionable; but that is another matter.) 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: 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. -- 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 8649425507335336.wa.zatlas1yahoo@listserv.ua.edu, on 12/01/2013 at 12:20 AM, Ze'ev Atlas zatl...@yahoo.com said: I have identified the defect pretty well, You waved your hands; you never identified a problem that a central repository would solve. you refuse to see that definition That would have been impossible; there was no there there. You, OTOH, refuse to see the similarities between MVS catalogs and Unix directories. go to circular arguments Nonsense. about semantics! You don't have the faintest idea what semantics are. 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. Except when it isn't. In Unix, you do not have those length and level limitations, but you need to be explicit in describing where the file is That's nonsense. or go through the trouble of creating symbolic links. Symbolic links provide an alias; they don't say where something is. Alias resolution is as much a factor for legacy MVS catalogs and data sets as it is for Unix paths. Both sides are awkward, require too much memorization and each one has a glaring defect as identified above. The defect that you identified is imaginary. PLEASE DO NOT GET INTO SEMANTICS The difference between having a usable backup and not having one is only semantics. -- 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 3197351753588016.wa.zatlas1yahoo@listserv.ua.edu, on 12/01/2013 at 08:21 AM, Ze'ev Atlas zatl...@yahoo.com said: I do not want people to shoot the idea down just because I referred to only one example. The problem is not that you have only one example, it is that you are shooting from the hip instead of first trying to understand how things currently work. -- 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: TCBJLB doesn't point to a DCB
At 14:23 -0500 on 12/01/2013, MichealButz wrote about Re: TCBJLB doesn't point to a DCB: I was confused by the documentation DCB= is the address where the DCB resides so Instead of coding MVC WSDCB,TCBJLB DCB= is a parm on the DESERV DCB=WSDCB, I coded L RX,TCBJLB DCB=(RX), That worked Your problem with DCB=WASDCB is that says the DCB is at WASDCB not that the address of the DCB is in WASDCB. I do not know of a way of saying Look at this Location for a pointer to the DCB which is what you were trying to do (otherwise you could have just done DCB=TCBJLB). OTOH: I think same macros can do this look here by coding something like DCB=(*,WASDCB) or that might be some other type of reference. DCB=(RX) says the DCB's address is in RX. -- 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 CAJTOO5-iHgc15A_BytT=cObawqo=6a0-i+moogprvnq5fam...@mail.gmail.com, on 12/01/2013 at 08:27 AM, Mike Schwab mike.a.sch...@gmail.com said: TSO appends a prefix of your userid to your data set name unless you specify quotes. Except when it doesn't. See 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
On 13Dec01:1758-0500, Shmuel Metz (Seymour J.) wrote: In 0905701904337885.wa.paulgboulderaim@listserv.ua.edu, on 11/30/2013 at 08:52 AM, Paul Gilmartin paulgboul...@aim.com said: Is the limit HLQ or TSO prefix? TSO limits the prefix to 7; for an explicit FQDSN it accepts an 8-character HLQ. Do catalog services enforce a limit of 7? No, nor does TSO. 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. -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe. __--from_Nightfall_by_Asimov/Silverberg_ -- 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
Dave: 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 for accounting and password size and one or two other needs) So in effect the USERID was max 7 characters that allowed up to password and accounting info, region size and my memory is iffy, some other info). the account change command was difficult to work with as you might imagine I had several choice swear words a few times trying to change some field. In summary UID was 7 characters. The eighth was reserved for UADS as either 0 thru 8 Ed On Dec 1, 2013, at 5:27 PM, David L. Craig wrote: On 13Dec01:1758-0500, Shmuel Metz (Seymour J.) wrote: In 0905701904337885.wa.paulgboulderaim@listserv.ua.edu, on 11/30/2013 at 08:52 AM, Paul Gilmartin paulgboul...@aim.com said: Is the limit HLQ or TSO prefix? TSO limits the prefix to 7; for an explicit FQDSN it accepts an 8-character HLQ. Do catalog services enforce a limit of 7? No, nor does TSO. 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. -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe. __--from_Nightfall_by_Asimov/Silverberg_ -- 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: Un-authorized caller calling authorized services.
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. -- 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: COBOL IN SRB Mode (Was Un-authorized caller)
On Sun, Dec 1, 2013 at 4:20 PM, esst...@juno.com esst...@juno.com wrote: I initiallydid notfind this topic particularly interesting as it was basicaly responded too in the first few responses. (SVC/PC). I recently had a dispute with Management reagrding the uses of sceduling COBOL BATCH under an SRB. Thats Right a Batch COBOL Prpogram runing Under an SRB, moreover under CICS Transaction Server. A Software Vendor believes they can solve a program sharing issue by using SRBS to execute a Batch Cobol Progam. In a nut shell the user enters a basic CICS transaction code and a PC call is issued to a Server Address Spaces whose only responsibility is to SCHEDULE an SRB Back to the specific CICS Region. The SRB then executes a Batch COBOL program. Oh my. I guess you can't mention the vendor. I'd like to __avoid__ them. I won't say that is impossible!. But how they can make a standard batch COBOL program, with all the LE routines, and especially the READ and WRITE verbs work in an SRB is totally beyond my comprehension. Well, I guess they might have some way to replace some of the LE routines with their own which would do something. Also, by definition, everything which runs in SRB mode is running authorized. Being the dirty rat fink that I am, I'd report this to the IT auditors as a sever security and reliability breach. As a sysprog, I would _refuse_ to acknowledge any responsibility for system integrity if this were implemented. I dont want to bore everyone with all the politics; such as we dont want to pay for Transactional VSAM, and we dont want to maintain 2 Versions of this program (Batch CICS). Mu collogue and I lost all the battles. Your management is composed of FOOLS. Ignorant, brain impaired idiots. We do this, concurrent VSAM, using the relatively inexpensive SYSB-II product from H W Computing (http://www.hwcs.com). We have had a few minor problems, but they were self inflicted. We have _no_ problems at all with the product now. I raise this issue to encourage some additional discussion. Again this is a VENDOR who has developing this facility. Paul D'ANgelo -- 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: DESERV function get DCB address
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
