Re: Obtaining System Information from a COBOL program
Shmuel, thanks for the validation. In our fairly large shop's early days, there was more communication between software and applications folks. Coding like this would not have moved forward at all. But now we find out about these little gems, way too late in the application development cycle. A few industrious programmers come up with this stuff, simply trying to address their function requirements, but obviously need guidance. For every such gem, there's another 10 lurking out there. We're trying to scope this out, contain it as best we can. And yes, while RDJFCB might be the only way to get specific data, Walt's comment is bang on. On the security side, we'll have to engage our DBAs. But on issues like getting the jobid of the caller, I don't suppose somebody knows of a list/index of system calls to provide access to stuff like that ? If we can tighten the process and steer people to use APIs, then I would feel like the appl code is significantly more insulated from software changes. Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: June 24, 2011 10:37 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net, on 06/24/2011 at 08:50 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said: The COBOL program has a static mapping of TCB and TIOT in the LINKAGE section. It gets the TIOT address from the TCB, then scans the TIOT, looking for a specific DDNAME. It then calls an assembler program to do the RDJFCB for that DDNAME. I have the same question as Walt: why not just do the RDJFCB? LA4,36(4) INC PTR TO EXIT LIST AREA Why? That just makes the code harder to read. SAVEXIT EQU * L 4,DCBADDR LA9,EXLIST LIST ADDRESS IN R9 IN DCBEXLST STCM 9,7,37(4) The instruction LA 4,36(4) concerns me (hard-coded offset). Indeed. The DCBD macro has been available for lo these many decades. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
I came across this website from IBM that describes how to obtain the System Symbols from inside a COBOL Program. This approach is very simple! Here is the link: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012192 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On 6/27/2011 7:07 AM, Daniel Rose wrote: I came across this website from IBM that describes how to obtain the System Symbols from inside a COBOL Program. This approach is very simple! Here is the link: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012192 Excellent! Nicely done. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
This works great! Now, is there a way to get a list of all the symbols available from within the program, or some other way? *don* On Mon, Jun 27, 2011 at 9:07 AM, Daniel Rose dan.r...@parker.com wrote: I came across this website from IBM that describes how to obtain the System Symbols from inside a COBOL Program. This approach is very simple! Here is the link: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012192 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
Is it the same list of variables available through ISPF; Test ;Variable panel? On Mon, Jun 27, 2011 at 9:44 AM, Donald Johnson dej@gmail.com wrote: This works great! Now, is there a way to get a list of all the symbols available from within the program, or some other way? *don* On Mon, Jun 27, 2011 at 9:07 AM, Daniel Rose dan.r...@parker.com wrote: I came across this website from IBM that describes how to obtain the System Symbols from inside a COBOL Program. This approach is very simple! Here is the link: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012192 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net, on 06/27/2011 at 07:29 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said: And yes, while RDJFCB might be the only way to get specific data, It's not, but the IBM documentation says to use RDJFCB rather than SWAREQ; I don't know what the reason is. But on issues like getting the jobid of the caller, I don't suppose somebody knows of a list/index of system calls to provide access to stuff like that ? It's easy[1] to get the jobid via an assembler subroutine. Similarly, it's easy to get the values of system symbols. Beyond that, I'd have to know what specific data you're looking for. You might be able to get the same data from pure COBOL but it would be a bear to maintain and might break when you installed z/OS service. [1] Supported interface, no security requirements. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
In listserv%201106270807479338.0...@bama.ua.edu, on 06/27/2011 at 08:07 AM, Daniel Rose dan.r...@parker.com said: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012192 That uses the documented entry point and parameter list, so it should be stable across releases. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
MVS Initialization and Tuning Reference (watch the line wrap on the link) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2a1/2.2?SHELF=EZ2ZBK0IDT=20100121143930 Site specific symbols will be defined in SYS1.PARMLIB(IEASYMxx) -- Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.gov Life's pretty tough . . . you're lucky if you live through it. -- Woody Guthrie -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Johnson Sent: Monday, 27 June 2011 08:45 To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program This works great! Now, is there a way to get a list of all the symbols available from within the program, or some other way? *don* On Mon, Jun 27, 2011 at 9:07 AM, Daniel Rose dan.r...@parker.com wrote: I came across this website from IBM that describes how to obtain the System Symbols from inside a COBOL Program. This approach is very simple! Here is the link: http://www-01.ibm.com/support/docview.wss?uid=isg3T1012192 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
In banlktinmnr4dy6a_-ae-ugvhcx5qdpo...@mail.gmail.com, on 06/27/2011 at 02:44 PM, Mike Schwab mike.a.sch...@gmail.com said: Is it the same list of variables available through ISPF; Test ;Variable panel? No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
And I agree that there is a TSS way to provide this security. That requirement will be addressed. The issue is with creative appl programmers who think that navigating control blocks the old-fashion way sans API will always work. So to try framing this issue a bit: Appl programmers, rightfully or not, require access to values such as LPAR name, jobid, etc, for some reason (business logic, stats, logging, etc). While we can't argue with their requirement, what we want to do is ensure that whatever information they need is obtained in a consistent manner, immune from subtle software changes, i.e. an API of some sort. Which to me reads as ASSEMBLER code, something our business programming brethren is not comfortable with. Definitely NOT COBOL! GETDSAB looks promising. Gotta dig some more. And curious about this LE/COBOL'ish method! It's all about knowing which APIs can deliver what is required. Just started browsing the LE Programming Reference. Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Doug Sent: June 23, 2011 10:41 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program On 6/22/2011 13:36, Daniel Rose wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Yes there is a LE/COBOL'ish method, will hunt up an example when I get back to the office. Regards, Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net, on 06/23/2011 at 09:09 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said: Interestingly, this is something being discussed in our shop right now. We have an application with code that extracts a DSN by searching through the TIOT, The DSN isn't in the TIOT, it's in the JFCB. There's no need to search the TIOT to locate the SVA of the JFCB; RDJFCB will do it for you, even if IBM remaps the TIOT. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
In 4e033faf.3000...@ozemail.com.au, on 06/23/2011 at 11:29 PM, Clement Clarke clementcla...@ozemail.com.au said: Most control blocks haven't changed in 40 years. Sure, new ones get added every decade or so, however, I think you'll be pretty safe! Well, in this particular case there's the XTIOT. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
You're right, Shmuel. The TIOT is where the search begins. The COBOL program has a static mapping of TCB and TIOT in the LINKAGE section. It gets the TIOT address from the TCB, then scans the TIOT, looking for a specific DDNAME. It then calls an assembler program to do the RDJFCB for that DDNAME. SAVEXIT EQU * L 4,DCBADDR LA4,36(4) INC PTR TO EXIT LIST AREA IC6,0(4) PICK DCB RECFM, INSERT EXIT LA9,EXLIST LIST ADDRESS IN R9 IN DCBEXLST ST9,0(4) STC 6,0(4) RESTORE DCB RECFM L 4,DCBADDR The instruction LA 4,36(4) concerns me (hard-coded offset). The kind of thing that works for years (decades, even), but that's not good programming. Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: June 23, 2011 7:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net, on 06/23/2011 at 09:09 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said: Interestingly, this is something being discussed in our shop right now. We have an application with code that extracts a DSN by searching through the TIOT, The DSN isn't in the TIOT, it's in the JFCB. There's no need to search the TIOT to locate the SVA of the JFCB; RDJFCB will do it for you, even if IBM remaps the TIOT. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Fri, 24 Jun 2011 08:50:56 -0400, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: You're right, Shmuel. The TIOT is where the search begins. The COBOL program has a static mapping of TCB and TIOT in the LINKAGE section. It gets the TIOT address from the TCB, then scans the TIOT, looking for a specific DDNAME. It then calls an assembler program to do the RDJFCB for that DDNAME. That seems a bit complicated. Why bother having the COBOL program look for a specific DDNAME? Just call the assembler program to do the RDJFCB. If the DDNAME was not present the assembler routine can provide an appropriate return code to the COBOL program. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
Walt Farrell wrote: The system will do the checks for you at OPEN time, and any check your application makes may get the wrong answer in some set of circumstances. In my opinion it's usually poor application design to make a dsname check. You really should let the system do it for you, as it's going to anyway. Once upon a time I used to rely on the DCB abend exit to trap the S913 so that the program did not just abend without deallocating the data set. However, when I worked at an ACF2 site (years ago) the DCB abend exit did not receive control and the allocation was left dangling (because the program abended). So I added code like RACROUTE REQUEST=AUTH, ENTITY=$DSNAME, VOLSER=$VOLSER, ATTR=READ, DSTYPE=N, WORKA=$WKA, MF=(E,$RRL) and if that indicated a lack of READ access then I avoided the attempt at OPEN. Now this was non-VSAM so not exactly what was being discussed, but at the time it was a valid reason to do a check before OPEN did. BTW, does anyone know if this is still the case with ACF2? That is, does the DCB abend exit now get control if ACF2 denies access at OPEN time? Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Fri, 24 Jun 2011 23:22:09 +1000, Greg Price greg.pr...@optushome.com.au wrote: Once upon a time I used to rely on the DCB abend exit to trap the S913 so that the program did not just abend without deallocating the data set. However, when I worked at an ACF2 site (years ago) the DCB abend exit did not receive control and the allocation was left dangling (because the program abended). Why not just use an ESTAE? So I added code like RACROUTE REQUEST=AUTH, ENTITY=$DSNAME, VOLSER=$VOLSER, ATTR=READ, DSTYPE=N, WORKA=$WKA, MF=(E,$RRL) and if that indicated a lack of READ access then I avoided the attempt at OPEN. Now this was non-VSAM so not exactly what was being discussed, but at the time it was a valid reason to do a check before OPEN did. That's is exactly what we were discussing before we got diverted a bit by the VSAM discussion. You failed to OBTAIN the DSCB and examine the RACF indicator flag. If you do not specify RACFIND=, and specify it correctly, there are cases where you can get a different answer than OPEN would get, and you might get either a failure (where OPEN would work) or a success (where OPEN would fail). At least with RACF. I can't comment on ACF2, but RACF sets the rules for how you're supposed to write the program, and it would be best to write it according to the rules so you have a better chance of it working if run with a different security product. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net, on 06/24/2011 at 08:50 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said: The COBOL program has a static mapping of TCB and TIOT in the LINKAGE section. It gets the TIOT address from the TCB, then scans the TIOT, looking for a specific DDNAME. It then calls an assembler program to do the RDJFCB for that DDNAME. I have the same question as Walt: why not just do the RDJFCB? LA4,36(4) INC PTR TO EXIT LIST AREA Why? That just makes the code harder to read. SAVEXIT EQU * L 4,DCBADDR LA9,EXLIST LIST ADDRESS IN R9 IN DCBEXLST STCM 9,7,37(4) The instruction LA 4,36(4) concerns me (hard-coded offset). Indeed. The DCBD macro has been available for lo these many decades. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
business applications. Why not use a tool designed to obtain this kind of information? Because you *CAN* get this information just with a few lines of code (even in COBOL)... And if it is that simple, *WHY* someone should not do it? Bye, MK -- Yours sincerely Michael Knigge Development S.E.T. Software GmbH Lister Straße 15 30163 Hannover Phone: +49 511 / 397 80 - 0 Fax: +49 511 / 397 80 - 66 michael.kni...@set-software.de Commercial Registry: HRB52778 Local Court Hannover Chief Executive Officer: Till Dammermann, Dr. Bernd Huber -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Wed, 22 Jun 2011 12:36:13 -0500, Daniel Rose dan.r...@parker.com wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. AFAIK, there is no LE run-time service for this. However, we use code similar to the quoted below to interrogate system control blocks and extract what we need. The code addresses control blocks by manipulating POINTER data items, and by reference modifier in parentheses. The Inspect command translates x'FA' to the character A, x'FB' to B,...x'FF' to F. CBL QUOTE,OPT,DUMP,RENT,DATA(31) ID Division. Program-ID. SYSWALK. Environment Division. Input-Output Section. Data Division. Working-Storage Section. 01 F-B. 05 PT4 Pointer. 05 PL4 Redefines PT4 PIC 9(7) COMP-3. 05 XL4 Redefines PT4 PIC X(4). 05 ZL5 PIC 9(5). 05 CL4 Redefines ZL5 PIC X(4). 01 Huge-Area. 05 filler PIC X(1024) Occurs 16383. Linkage Section. 01 CB. 05 PTR Pointer Occurs 512. Procedure Division. * Address PSA (zero address) Set Address Of CB To NULL * Address CVT by picking 5th word of PSA (x'10') Set Address Of CB To PTR(5) * Pick CVTDATE from CVT + x'38' (0cyydddF) Move CB(57:4)To XL4 * Convert 0cyydddF to dddF Add 190 To PL4 Display Date (ddd): PL4 * Address SMCA by picking 50th word of CVT (x'C4') Set Address Of CB To PTR(50) * Pick system name from SMCA + x'10' Display System name: CB(17:4) * Address PSA (zero address) again Set Address Of CB To NULL * Address CVT by picking 5th word of PSA (x'10') Set Address Of CB To PTR(5) * Address System Residence UCB Set Address Of CB To PTR(13) * Pick VOLSER at UCB + x'1C' Display SYSRES:CB(29:6) * Pick Unit Address at UCB + x'4' Move ZeroTo PL4 Move CB(5:2) To XL4(2:2) Move PL4 To ZL5 Inspect CL4 Replacing All ³ By A All #63637; By B All #63638; By C All #8206; By D All #8207; By E All . By F Display SYSRES Address: CL4 * Address PSA (zero address) again Set Address Of CB To NULL * Address CVT by picking 5th word of PSA (x'10') Set Address Of CB To PTR(5) * Address ECVT (Extended CVT) at CVT + x'8C' Set Address Of CB To PTR(36) * Pick sysplex-name at ECVT + x'8' Display SYSPLEX: CB(9:8) * Pick hardware-name at ECVT + x'150' Display HWNAME:CB(337:8) * Pick LPAR-name at ECVT + x'158' Display LPAR: CB(345:8) * Pick VM-name at ECVT + x'160' Display VM:CB(353:8) * Pick system VRM at ECVT + x'200' Display z/OS (vvrrmm):CB(513:6) * Pick IPL parameter at ECVT + x'A8' Display LOAD parameter (llpn):CB(169:8) Goback. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
Interestingly, this is something being discussed in our shop right now. We have an application with code that extracts a DSN by searching through the TIOT, in order to perform some security check. We (z/OS support division) fear that this user code is vulnerable to changes in z/OS control block layout, with the possibility of having one of your LOB (Line Of Business) apps down. The app people even asked if IBM would warn them of such cblock changes: Has IBM ever remapped the MVS Control blocks that a batch application program accesses? Will IBM ever remap the MVS Control blocks that a batch application program will access? How safe would it be for COBOL application code to access these MVS Control Blocks? We know IBM doesn't provide COBOL code mapping the TIOT, so we believe it's possible for an application to be unexpectedly crippled by a subtle z/OS control block change, with management asking for delays (and/or back out) of the latest z/OS rollout. Shouldn't every effort be made to insulate appl code from the OS ? I fear the day wil come when we'll have to forward the SMP APPLY CHECK listing to all application programmers. Do your shop(s) have a policy of sorts when it comes to accessing such data (outside of any LE service) ? Stan Canada Revenue Agency mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Giliad Wilf Sent: June 23, 2011 8:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program On Wed, 22 Jun 2011 12:36:13 -0500, Daniel Rose dan.r...@parker.com wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. AFAIK, there is no LE run-time service for this. However, we use code similar to the quoted below to interrogate system control blocks and extract what we need. The code addresses control blocks by manipulating POINTER data items, and by reference modifier in parentheses. The Inspect command translates x'FA' to the character A, x'FB' to B,...x'FF' to F. CBL QUOTE,OPT,DUMP,RENT,DATA(31) ID Division. Program-ID. SYSWALK. Environment Division. Input-Output Section. Data Division. Working-Storage Section. 01 F-B. 05 PT4 Pointer. 05 PL4 Redefines PT4 PIC 9(7) COMP-3. 05 XL4 Redefines PT4 PIC X(4). 05 ZL5 PIC 9(5). 05 CL4 Redefines ZL5 PIC X(4). 01 Huge-Area. 05 filler PIC X(1024) Occurs 16383. Linkage Section. 01 CB. 05 PTR Pointer Occurs 512. Procedure Division. * Address PSA (zero address) Set Address Of CB To NULL * Address CVT by picking 5th word of PSA (x'10') Set Address Of CB To PTR(5) * Pick CVTDATE from CVT + x'38' (0cyydddF) Move CB(57:4)To XL4 * Convert 0cyydddF to dddF Add 190 To PL4 Display Date (ddd): PL4 * Address SMCA by picking 50th word of CVT (x'C4') Set Address Of CB To PTR(50) * Pick system name from SMCA + x'10' Display System name: CB(17:4) * Address PSA (zero address) again Set Address Of CB To NULL * Address CVT by picking 5th word of PSA (x'10') Set Address Of CB To PTR(5) * Address System Residence UCB Set Address Of CB To PTR(13) * Pick VOLSER at UCB + x'1C' Display SYSRES:CB(29:6) * Pick Unit Address at UCB + x'4' Move ZeroTo PL4 Move CB(5:2) To XL4(2:2) Move PL4 To ZL5 Inspect CL4 Replacing All ³ By A All #63637; By B All #63638; By C All #8206; By D All #8207; By E All . By F Display SYSRES Address: CL4 * Address PSA (zero address) again Set Address Of CB To NULL * Address CVT by picking 5th word of PSA (x'10') Set Address Of CB To PTR(5) * Address ECVT (Extended CVT
Re: Obtaining System Information from a COBOL program
Take a look at the GETDSAB function in the Auth Assembler Reference. It's a documented interface to get the info you need, and highly doubtful it will go away or break no matter how the underlying control blocks change. It means you will have to write an assembler sub-routine, but not much of one. --Dave Day - Original Message - From: Haynes, Stan stan.hay...@cra-arc.gc.ca Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Thursday, June 23, 2011 8:09 AM Subject: Re: Obtaining System Information from a COBOL program Interestingly, this is something being discussed in our shop right now. We have an application with code that extracts a DSN by searching through the TIOT, in order to perform some security check. We (z/OS support division) fear that this user code is vulnerable to changes in z/OS control block layout, with the possibility of having one of your LOB (Line Of Business) apps down. The app people even asked if IBM would warn them of such cblock changes: Has IBM ever remapped the MVS Control blocks that a batch application program accesses? Will IBM ever remap the MVS Control blocks that a batch application program will access? How safe would it be for COBOL application code to access these MVS Control Blocks? We know IBM doesn't provide COBOL code mapping the TIOT, so we believe it's possible for an application to be unexpectedly crippled by a subtle z/OS control block change, with management asking for delays (and/or back out) of the latest z/OS rollout. Shouldn't every effort be made to insulate appl code from the OS ? I fear the day wil come when we'll have to forward the SMP APPLY CHECK listing to all application programmers. Do your shop(s) have a policy of sorts when it comes to accessing such data (outside of any LE service) ? Stan Canada Revenue Agency mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
Most control blocks haven't changed in 40 years. Sure, new ones get added every decade or so, however, I think you'll be pretty safe! Can you imagine all the code that IBM would have to change if they moved or changed the odd control block? Clem Clarke Author, Jol - the easy alternative to JCL Haynes, Stan wrote: Interestingly, this is something being discussed in our shop right now. We have an application with code that extracts a DSN by searching through the TIOT, in order to perform some security check. We (z/OS support division) fear that this user code is vulnerable to changes in z/OS control block layout, with the possibility of having one of your LOB (Line Of Business) apps down. The app people even asked if IBM would warn them of such cblock changes: Has IBM ever remapped the MVS Control blocks that a batch application program accesses? Will IBM ever remap the MVS Control blocks that a batch application program will access? How safe would it be for COBOL application code to access these MVS Control Blocks? We know IBM doesn't provide COBOL code mapping the TIOT, so we believe it's possible for an application to be unexpectedly crippled by a subtle z/OS control block change, with management asking for delays (and/or back out) of the latest z/OS rollout. Shouldn't every effort be made to insulate appl code from the OS ? I fear the day wil come when we'll have to forward the SMP APPLY CHECK listing to all application programmers. Do your shop(s) have a policy of sorts when it comes to accessing such data (outside of any LE service) ? Stan Canada Revenue Agency mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Giliad Wilf Sent: June 23, 2011 8:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program On Wed, 22 Jun 2011 12:36:13 -0500, Daniel Rosedan.r...@parker.com wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Thu, 23 Jun 2011 09:09:55 -0400, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: Interestingly, this is something being discussed in our shop right now. We have an application with code that extracts a DSN by searching through the TIOT, in order to perform some security check. We (z/OS support division) fear that this user code is vulnerable to changes in z/OS control block layout, with the possibility of having one of your LOB (Line Of Business) apps down. The app people even asked if IBM would warn them of such cblock changes: Specifically for the question about using the TIOT to find the dsname, doing it the proper way via the TIOT should be safe, but finding it in an improper way could easily break. And we had a discussion in an internal IBM discussion just recently where someone had done it the wrong way and his code broke. So we really can't answer that specific question without knowing exactly what you've done. Some changes IBM warns customers about, and some we warn only vendors about. And some we may not warn anyone about. And some changes (like the one I mention above) are old changes that don't bite you unless you choose some particular system option (such as requesting SWA above the line, in this case). So it's better not to go poking around in control blocks if you don't need to, and if you need to you should only use blocks and fields we've identified as intended programming interfaces. If those blocks or fields change incompatibly we do generally warn everyone, and we try not to change them incompatibly in the first place. By the way, putting my security hat on for a moment, I'd like to know more about why your application (or its developers) need to do a security check based on a data set name. The system will do the checks for you at OPEN time, and any check your application makes may get the wrong answer in some set of circumstances. In my opinion it's usually poor application design to make a dsname check. You really should let the system do it for you, as it's going to anyway. (But again, I'd like to understand your scenario and why you think the application needs to make the check.) -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
By the way, putting my security hat on for a moment, I'd like to know more about why your application (or its developers) need to do a security check based on a data set name. The system will do the checks for you at OPEN time, and any check your application makes may get the wrong answer in some set of circumstances. In my opinion it's usually poor application design to make a dsname check. You really should let the system do it for you, as it's going to anyway. (But again, I'd like to understand your scenario and why you think the application needs to make the check.) -- Walt Farrell IBM STSM, z/OS Security Design I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410-09: quote 1.5.1.1 RACF Protection for VSAM Data Sets A catalog that contains a VSAM data set does not have to be RACF protected for its data sets to be RACF protected. If a user-security-verification routine (USVR) exists, it is not invoked for RACF-defined data sets. Deleting any type of RACF-protected entry from an RACF-protected catalog requires alter-level authorization for the catalog or the entry being deleted. Alter authority for the catalog itself is not sufficient for this operation. Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. I apologize in advance if I am out of line here. Andy Coburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410-09: quote ...snipped (by Walt)... Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. I apologize in advance if I am out of line here. You're not out of line at all, Andy, and that's one point I sometimes forget about. Thanks. But as you note, it should affect very few applications (not just COBOL, but I expect that few programs using VSAM are running in supervisor state or key 0. I also wish VSAM processing would provide a way of doing that check for you. I considered it a major breakthrough a number of years ago just getting them to document that point so people would know about it. Note that it's difficult for you to do the check correctly, as: (a) You need to know that you have to use the cluster name, not the data or index component name (b) You need to know the volser of the catalog (not of the component you're opening) so you can specify it on the RACROUTE REQUEST=AUTH. Of course, this means you need to find out the name of the catalog so you can then find its volser. (c) You need to know whether the RACF indicator in the cluster's sphere record is on or off, so you can properly specify RACFIND on the RACROUTE REQUEST=AUTH. So you need to retrieve that information from the catalog, too. Luckily, now that they've provided and documented the catalog search interface you can get all that info. In the good old days you had to use undocumented SVC 26 features before you had any hope of doing the authorization check correctly yourself. But still, they should at least provide an option (an ACB flag, or something) to allow you to ask OPEN to do the check for you. However (getting back to the original question I responded to) what I usually see when someone thinks their application should do the check is an attempt to avoid adding recovery for a possible S913 ABEND that they'll get if they just do an OPEN when the user isn't authorized. But unfortunately there are a number of ways that can go wrong, depending on how the administrators have decided to protect the data set, and on how well the application programmer implemented the check. And I've seen it go wrong both ways, with the application either incorrectly deciding the user would have access, or incorrectly deciding the user would not have access. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
I have to question why you would be doing file stuff while in key zero. It seems to me that you would not only run into the security issues that Walt noted, but also run a higher risk to the system should something go wrong in your program. I'm not questioning your need to be in key zero for your business mission, but I would wonder why you wouldn't want to stay out of key zero until you actually need to be there. You switch, do the sacred function, then switch back. I once worked with an application that needed to be in key zero for something and just stayed there the whole time. I seem to recall this ended up being a PITA. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Andy Coburn Sent: Thursday, June 23, 2011 10:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program ..snip Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. I apologize in advance if I am out of line here. Andy Coburn NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410-09: quote ...snipped (by Walt)... Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. http://bama.ua.edu/archives/ibm-main.html You can be fairly certain that *no* COBOL programs run in sup state and/or key zero because LE does not officially support it and not at all without performing unnatural acts. That's not to say you can't conspire to get that to happen, but it would be most unwise to try. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
I feel like I should expand on my query. We use CA-TSS as our security server. All datasets are protected. In this case, the appl owners *need* to do a sec check to control the type of access. In their own words: an application makes a call to our business team (app). We then grant access via their HLQ, server packet name and access level - allowing us some degree of control over the calling config design ... Some of our servers are amalgamated, others are more specific. And there's also interest in logging the jobid of the caller of this program (STCnumber if CICS, otherwise the batch jobid). Sysprogs here believe this security check can be removed in favor of more traditional security permissions but that would require our DBAs to do things differently. Right now the appl is calling a 24-bit assembler program for the TIOT/DSN lookup, and one look at the code revealed they're not using DSECT definitions enough. The appl folks are COBOL people, and as such want to ditch the assembler program in favor of a COBOL routine they found on the net. While the odds of seeing the TIOT (and other system-management control blocks) change are slim, they're not nil either. An application program that uses static mapping of control blocks (in COBOL to boot!) could find itself in a broken state because of new z/OS maint introducing a control block change, and then our ability to deploy and maintain z/OS can be undermined. If the appl is broken, what's the fix ? Appl programming change or software rollback ? Sysprogs don't want to be held hostage by the appl programmers. So I'm hearing assembler code using established APIs like GETDSAB. Comments, anyone ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Craddock Sent: June 23, 2011 11:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410-09: quote ...snipped (by Walt)... Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. http://bama.ua.edu/archives/ibm-main.html You can be fairly certain that *no* COBOL programs run in sup state and/or key zero because LE does not officially support it and not at all without performing unnatural acts. That's not to say you can't conspire to get that to happen, but it would be most unwise to try. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
IMNSHO, The appl owners don't 'need' to do the security. Indeed, many auditors will insist that they don't. The appropriate way is to explain to the security administrator what they want and be the requestors/approvers. Separation of duties not to mention a gaping hole for 'funny' code (granting inappropriate access, a 'back door', or just plain bugs.) This isn't technical. This is political. Now, this is not to say that some security measures are appropriate for embedding in the application. And some programmers can make a pretty convincing argument that the system be modified to suit their perceived needs. But the answer has to be 'no'. No Cobol in APF libraries. Period. Very bad practice. The app folks can very easily solve the business problem in other ways. Lastly, the proposed solution in effect delegates system security to one application group. Not a good idea. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Thursday, June 23, 2011 11:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program I feel like I should expand on my query. We use CA-TSS as our security server. All datasets are protected. In this case, the appl owners *need* to do a sec check to control the type of access. In their own words: an application makes a call to our business team (app). We then grant access via their HLQ, server packet name and access level - allowing us some degree of control over the calling config design ... Some of our servers are amalgamated, others are more specific. And there's also interest in logging the jobid of the caller of this program (STCnumber if CICS, otherwise the batch jobid). Sysprogs here believe this security check can be removed in favor of more traditional security permissions but that would require our DBAs to do things differently. Right now the appl is calling a 24-bit assembler program for the TIOT/DSN lookup, and one look at the code revealed they're not using DSECT definitions enough. The appl folks are COBOL people, and as such want to ditch the assembler program in favor of a COBOL routine they found on the net. While the odds of seeing the TIOT (and other system-management control blocks) change are slim, they're not nil either. An application program that uses static mapping of control blocks (in COBOL to boot!) could find itself in a broken state because of new z/OS maint introducing a control block change, and then our ability to deploy and maintain z/OS can be undermined. If the appl is broken, what's the fix ? Appl programming change or software rollback ? Sysprogs don't want to be held hostage by the appl programmers. So I'm hearing assembler code using established APIs like GETDSAB. Comments, anyone ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Craddock Sent: June 23, 2011 11:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410-09: quote ...snipped (by Walt)... Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. http://bama.ua.edu/archives/ibm-main.html You can be fairly certain that *no* COBOL programs run in sup state and/or key zero because LE does not officially support it and not at all without performing unnatural acts. That's not to say you can't conspire to get that to happen, but it would be most unwise to try. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail
Re: Obtaining System Information from a COBOL program
I would have thought this is exactly what the (RACF) Facility class is intended for. I assume that TSS has an equivalent feature, where you can code esoteric resources to be checked by a SAF call. Move the call to the facility class and you won't have to worry about changes in the underlying OS Jerry Whitteridge Design Engineer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Haynes, Stan Sent: Thursday, June 23, 2011 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program I feel like I should expand on my query. We use CA-TSS as our security server. All datasets are protected. In this case, the appl owners *need* to do a sec check to control the type of access. In their own words: an application makes a call to our business team (app). We then grant access via their HLQ, server packet name and access level - allowing us some degree of control over the calling config design ... Some of our servers are amalgamated, others are more specific. And there's also interest in logging the jobid of the caller of this program (STCnumber if CICS, otherwise the batch jobid). Sysprogs here believe this security check can be removed in favor of more traditional security permissions but that would require our DBAs to do things differently. Right now the appl is calling a 24-bit assembler program for the TIOT/DSN lookup, and one look at the code revealed they're not using DSECT definitions enough. The appl folks are COBOL people, and as such want to ditch the assembler program in favor of a COBOL routine they found on the net. While the odds of seeing the TIOT (and other system-management control blocks) change are slim, they're not nil either. An application program that uses static mapping of control blocks (in COBOL to boot!) could find itself in a broken state because of new z/OS maint introducing a control block change, and then our ability to deploy and maintain z/OS can be undermined. If the appl is broken, what's the fix ? Appl programming change or software rollback ? Sysprogs don't want to be held hostage by the appl programmers. So I'm hearing assembler code using established APIs like GETDSAB. Comments, anyone ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Craddock Sent: June 23, 2011 11:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Obtaining System Information from a COBOL program On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410- 09: quote ...snipped (by Walt)... Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. http://bama.ua.edu/archives/ibm-main.html You can be fairly certain that *no* COBOL programs run in sup state and/or key zero because LE does not officially support it and not at all without performing unnatural acts. That's not to say you can't conspire to get that to happen, but it would be most unwise to try. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader
Re: Obtaining System Information from a COBOL program
Just to jump in, a COBOL program can invoke a REXX program, which can access SYSVARs and MVSVARs. -- John McKown Maranatha! Sent from my Vibrant Android phone. On Jun 23, 2011 11:40 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca wrote: I feel like I should expand on my query. We use CA-TSS as our security server. All datasets are protected. In this case, the appl owners *need* to do a sec check to control the type of access. In their own words: an application makes a call to our business team (app). We then grant access via their HLQ, server packet name and access level - allowing us some degree of control over the calling config design ... Some of our servers are amalgamated, others are more specific. And there's also interest in logging the jobid of the caller of this program (STCnumber if CICS, otherwise the batch jobid). Sysprogs here believe this security check can be removed in favor of more traditional security permissions but that would require our DBAs to do things differently. Right now the appl is calling a 24-bit assembler program for the TIOT/DSN lookup, and one look at the code revealed they're not using DSECT definitions enough. The appl folks are COBOL people, and as such want to ditch the assembler program in favor of a COBOL routine they found on the net. While the odds of seeing the TIOT (and other system-management control blocks) change are slim, they're not nil either. An application program that uses static mapping of control blocks (in COBOL to boot!) could find itself in a broken state because of new z/OS maint introducing a control block change, and then our ability to deploy and maintain z/OS can be undermined. If the appl is broken, what's the fix ? Appl programming change or software rollback ? Sysprogs don't want to be held hostage by the appl programmers. So I'm hearing assembler code using established APIs like GETDSAB. Comments, anyone ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Beha... On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On 6/23/2011 3:33 PM, John McKown wrote: Just to jump in, a COBOL program can invoke a REXX program, which can access SYSVARs and MVSVARs. Yes, but the OP wanted the LPAR name, which isn't available through those, as far as I can tell, although I'm not sure what he really wanted or if that was just tossed out there. -- John McKown Maranatha! Sent from my Vibrant Android phone. On Jun 23, 2011 11:40 AM, Haynes, Stanstan.hay...@cra-arc.gc.ca wrote: I feel like I should expand on my query. We use CA-TSS as our security server. All datasets are protected. In this case, the appl owners *need* to do a sec check to control the type of access. In their own words: an application makes a call to our business team (app). We then grant access via their HLQ, server packet name and access level - allowing us some degree of control over the calling config design ... Some of our servers are amalgamated, others are more specific. And there's also interest in logging the jobid of the caller of this program (STCnumber if CICS, otherwise the batch jobid). Sysprogs here believe this security check can be removed in favor of more traditional security permissions but that would require our DBAs to do things differently. Right now the appl is calling a 24-bit assembler program for the TIOT/DSN lookup, and one look at the code revealed they're not using DSECT definitions enough. The appl folks are COBOL people, and as such want to ditch the assembler program in favor of a COBOL routine they found on the net. While the odds of seeing the TIOT (and other system-management control blocks) change are slim, they're not nil either. An application program that uses static mapping of control blocks (in COBOL to boot!) could find itself in a broken state because of new z/OS maint introducing a control block change, and then our ability to deploy and maintain z/OS can be undermined. If the appl is broken, what's the fix ? Appl programming change or software rollback ? Sysprogs don't want to be held hostage by the appl programmers. So I'm hearing assembler code using established APIs like GETDSAB. Comments, anyone ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Beha... On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburna...@andycoburn.com wrote: I question Walt's... -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
My mistake. We always set LPARname==SYSNAME. On Thu, 2011-06-23 at 16:22 -0600, Steve Comstock wrote: On 6/23/2011 3:33 PM, John McKown wrote: Just to jump in, a COBOL program can invoke a REXX program, which can access SYSVARs and MVSVARs. Yes, but the OP wanted the LPAR name, which isn't available through those, as far as I can tell, although I'm not sure what he really wanted or if that was just tossed out there. -- John McKown Maranatha! Sent from my Vibrant Android phone. On Jun 23, 2011 11:40 AM, Haynes, Stanstan.hay...@cra-arc.gc.ca wrote: I feel like I should expand on my query. We use CA-TSS as our security server. All datasets are protected. In this case, the appl owners *need* to do a sec check to control the type of access. In their own words: an application makes a call to our business team (app). We then grant access via their HLQ, server packet name and access level - allowing us some degree of control over the calling config design ... Some of our servers are amalgamated, others are more specific. And there's also interest in logging the jobid of the caller of this program (STCnumber if CICS, otherwise the batch jobid). Sysprogs here believe this security check can be removed in favor of more traditional security permissions but that would require our DBAs to do things differently. Right now the appl is calling a 24-bit assembler program for the TIOT/DSN lookup, and one look at the code revealed they're not using DSECT definitions enough. The appl folks are COBOL people, and as such want to ditch the assembler program in favor of a COBOL routine they found on the net. While the odds of seeing the TIOT (and other system-management control blocks) change are slim, they're not nil either. An application program that uses static mapping of control blocks (in COBOL to boot!) could find itself in a broken state because of new z/OS maint introducing a control block change, and then our ability to deploy and maintain z/OS can be undermined. If the appl is broken, what's the fix ? Appl programming change or software rollback ? Sysprogs don't want to be held hostage by the appl programmers. So I'm hearing assembler code using established APIs like GETDSAB. Comments, anyone ? Stan mailto:stan.hay...@cra-arc.gc.ca (613) 941-8091 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Beha... On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburna...@andycoburn.com wrote: I question Walt's... -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On 6/22/2011 13:36, Daniel Rose wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Yes there is a LE/COBOL'ish method, will hunt up an example when I get back to the office. Regards, Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Obtaining System Information from a COBOL program
I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
Hi Daniel (Dan?) I have a program that gets some of that info from control blocks, courtesy of Gil Saint-Flour. Here is the info block at the beginning, along with a website to get you started: *THE NAME OF THE CONTROL-BLOCK IS INDICATED IN POS 1-6 OF* *THE PROCEDURE DIVISION LINES. * *THE LAYOUT OF THE MVS CONTROL BLOCKS IS DESCRIBED IN THE* *MVS DATA AREAS MANUALS, WHICH CAN BE FOUND ON ANY MVS OR* *OS/390 CD COLLECTION OR VIEWED ON-LINE BY GOING TO: * * HTTP://WWW.S390.IBM.COM/BOOKMGR-CGI/BOOKMGR.CMD/LIBRARYhttp://www.s390.ibm.com/BOOKMGR-CGI/BOOKMGR.CMD/LIBRARY* *AND SEARCHING FOR: * *MVS DATA AREAS * ** *ORIGIN = HTTP://GSF-SOFT.COM/FREEWARE/ http://gsf-soft.com/FREEWARE/ * Unfortunately, my program does not return the LPAR info, but I assume it could easily be tracked down. Best of luck to you ! *don* On Wed, Jun 22, 2011 at 1:36 PM, Daniel Rose dan.r...@parker.com wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On 6/22/2011 11:36 AM, Daniel Rose wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. I got to wondering about this. Your programmer does know that COBOL stands for COmmon Business Oriented Language, right? It just doesn't seem that obtaining an LPAR name or SMFSID is in the same ballpark as doing accounting or inventory or other business applications. Why not use a tool designed to obtain this kind of information? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Wed, Jun 22, 2011 at 12:55 PM, Steve Comstock st...@trainersfriend.comwrote: On 6/22/2011 11:36 AM, Daniel Rose wrote: I had a COBOL programmer ask me how they could get the LPAR name, SYSNAME, or SMFSID from a COBOL program. I could not find a LE Function that would do that. So, a co-worker located a sample program that chases controls to get that information. Does anybody know of any LE Functions or a cleaner way to do this. BTW, the programmer does not want to add a SORT step before the COBOL program nor do they want to change the execution JCL. Hence the restriction of only obtaining this from inside the COBOL program. I got to wondering about this. Your programmer does know that COBOL stands for COmmon Business Oriented Language, right? It just doesn't seem that obtaining an LPAR name or SMFSID is in the same ballpark as doing accounting or inventory or other business applications. Why not use a tool designed to obtain this kind of information? How is that information going to be used? Can't they use a JCL parm and let the scheduler populate it? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/**ROI/roi.htmlhttp://www.trainersfriend.com/ROI/roi.html --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/**ibm-main.htmlhttp://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining system information from a COBOL program
PL/I has long supported such constructs as declare CVTPP pointer static initial(16); declare p pointer, cvtp pointer based(CVTPP) ; p = cvtp ; which sets p to point to the CVT, after which . . . Identical constructs---I forbear to illustrate them lest they corrupt the young and innocent---are now available in COBOL; they are already much used; and objection to their use on the ground that they are inappropriate to 'business applications' puts me in mind of Gibbon's assurance that the English-language content of his History of the Decline and Fall of the Roman Empire was entirely suitable for a maiden's eyes, all salacious content having been relegated to the decent obscurity of a learned language. John Gilmore -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
As someone asked before, justify it with a business case. You can always jump in and write an assembler program that can be called. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
