BNDRY=PAGE possible CPU hit?
Hi, I recently added the BNDRY=PAGE parameter to a set of STORAGE OBTAINS which acquire storage areas of various sizes from several low private subpools. My intent was a reduction of CPU used by subsequent MVCLE instructions, as ADM would more likely be employed for MVCLE executes, since the storage areas involved were page aligned (apparently an ADM pre-req.) Unfortunately my initial testing revealed a significant increase in CPU consumption, rather than a reduction. I did a few searches of the IBM-MAIN archive and found nothing involving increased CPU overhead resulting from BNDRY=PAGE usage. Any thoughts on what might be causing the elevated CPU? Again, the only change made was adding BNDRY=PAGE. (I have since backed the change off, tested, reapplied the change and tested with the same results) Thanks much, Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC (FCTC) usage
Tony Harminc wrote: > In passing, I have no idea why JES2 would no longer support CTCs. Are > FICON CTCs completely incompatible with Bus&Tag (and 3088) and ESCON > ones? Where are the FICON ones documented? Actually, I don't know for sure where the support fails. 1) JES2 requires that the CTCA be defined as in 'basic' mode. 2) When generating an IOCP for FICON, is is possible to define it as 'basic' just as needed by JES2, but, 3) The IODEF build fails when you try to define the FICON as 'basic'. I don't know if the IOCP people intended to remove the 'basic' option, or, if the IODEF people just never considered putting in 'basic' CTCA support for FICON. When I asked IBM, I got the response: "It does not matter because NJE over TCP/IP is the future, not CTCAs." Tony Thigpen Tony Harminc wrote on 5/30/19 6:12 PM: On Wed, 29 May 2019 at 13:46, Jesse 1 Robinson wrote: Thank you, that was my point about non-CTC links. When I started here in the 90s, BSC links were still in use. First for NJE to VM/XA because our implementation did not include VTAM, and for some JES2 connections because of a perception that BSC was faster than SNA. A little testing dispelled the latter myth, and we converted all JES2 links in short order. By the time FCTC emerged, we were 100% SNA. BSC was not the line-level protocol used by JES2 over (old style) CTCs. It was *similar*, but BSC CCWs and the overall protocol are not the same as for CTCs. BSC ran on synchronous lines via a communications controller like a 37x5. It is perhaps a bit like SNA for 3270s. There are/were local (channel-attached) 3270 control units of two types - non-SNA and SNA. VTAM supported both; things like MVS consoles supported only non-SNA. There were also remote 3270 control units using BSC or using SNA. Regardless of the low level transport the 3270 data stream was used. For NJE the multileaving protocol is used regardless of the underlying transport. In passing, I have no idea why JES2 would no longer support CTCs. Are FICON CTCs completely incompatible with Bus&Tag (and 3088) and ESCON ones? Where are the FICON ones documented? Tony H. -- 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: CTC (FCTC) usage
Tony, thanks for clearing it up. I was indeed confusing the two issues. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Thursday, May 30, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CTC (FCTC) usage On Wed, 29 May 2019 at 13:46, Jesse 1 Robinson wrote: > Thank you, that was my point about non-CTC links. When I started here > in the 90s, BSC links were still in use. First for NJE to VM/XA > because our implementation did not include VTAM, and for some JES2 > connections because of a perception that BSC was faster than SNA. A > little testing dispelled the latter myth, and we converted all JES2 > links in short order. By the time FCTC emerged, we were 100% SNA. > BSC was not the line-level protocol used by JES2 over (old style) CTCs. It was *similar*, but BSC CCWs and the overall protocol are not the same as for CTCs. BSC ran on synchronous lines via a communications controller like a 37x5. It is perhaps a bit like SNA for 3270s. There are/were local (channel-attached) 3270 control units of two types - non-SNA and SNA. VTAM supported both; things like MVS consoles supported only non-SNA. There were also remote 3270 control units using BSC or using SNA. Regardless of the low level transport the 3270 data stream was used. For NJE the multileaving protocol is used regardless of the underlying transport. In passing, I have no idea why JES2 would no longer support CTCs. Are FICON CTCs completely incompatible with Bus&Tag (and 3088) and ESCON ones? Where are the FICON ones documented? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CTC (FCTC) usage
On Wed, 29 May 2019 at 13:46, Jesse 1 Robinson wrote: > Thank you, that was my point about non-CTC links. When I started here in > the 90s, BSC links were still in use. First for NJE to VM/XA because our > implementation did not include VTAM, and for some JES2 connections because > of a perception that BSC was faster than SNA. A little testing dispelled > the latter myth, and we converted all JES2 links in short order. By the > time FCTC emerged, we were 100% SNA. > BSC was not the line-level protocol used by JES2 over (old style) CTCs. It was *similar*, but BSC CCWs and the overall protocol are not the same as for CTCs. BSC ran on synchronous lines via a communications controller like a 37x5. It is perhaps a bit like SNA for 3270s. There are/were local (channel-attached) 3270 control units of two types - non-SNA and SNA. VTAM supported both; things like MVS consoles supported only non-SNA. There were also remote 3270 control units using BSC or using SNA. Regardless of the low level transport the 3270 data stream was used. For NJE the multileaving protocol is used regardless of the underlying transport. In passing, I have no idea why JES2 would no longer support CTCs. Are FICON CTCs completely incompatible with Bus&Tag (and 3088) and ESCON ones? Where are the FICON ones documented? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Just how secure are mainframes? | Trevor Eddolls
It must be Friday somewhere. I put 'against stupidity' into Google. Schiller's exact quote popped up first. Just sayin'. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ray Overby Sent: Thursday, May 30, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see." As a developer of security interfaces for applications: It is extremely difficult to design an unprivileged application security interface in code that runs in PSW Key 8 problem state not apf-authorized. The security code path can be modified (if it is non-rent), frontended by using content supervision functions (ex - task lib), or bypassed. In addition, application storage areas + ESM (external security manager) credentials cannot be in key 8 storage as the application code could accidentally or maliciously modify them. A properly designed z/OS application would have separate application and system level programs and memory objects. These programs would be invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The application code would call the system level programs whenever an application function needs to be performed that requires security checks. In this way the system level code + memory objects they reference cannot be accidentally or maliciously compromised by the application code or other programs running on the platform. So called unprivileged application security code is really just application code. Important (really). But I do not like calling it security code as it does not meet the due diligence required for system level security code. Calling application code "Unprivileged application security code" leads people to assume that the code has integrity and therefore is secure. In most cases, this is not true. It spreads a false sense of security. In response to "It can if you don't install the broken application." * Must of the code vulnerabilities I find are zero day vulnerabilities. This means there is no fix. If there is no fix then it is almost 100% certain that the client installing and/or running the product would have no idea that they are installing/running a back door on their system. * Before you install a product (how often does that happen these days?) do you ensure that all maintenance is applied or just hipers? What about integrity fix's? You probably have a different answer depending upon which vendor it is In response to "To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code." * I don't know who Schiller is. Can you clarify? Thanks. * As an example - The platform could make a new integrity rule such as: Only SVC 107 can turn on JSCBAUTH bit. Any other SVC or any PC routine that does it will abend with S047-98 (yes, I just created a new abend code for integrity - Byte me!). This would render useless most of the currently implemented "magic SVC or PC routines" that turn on JSCBAUTH bit that are running in the wild today (FYI - this is another sub-category of a TRAP DOOR vulnerability). There are ways to get around this (several come to mind as I write this) however I would ague that a change like this would benefit all users of the platform. The same business arguments that were used to eliminate Key 8 common storage usage could be used for this change. With similar benefits. On 5/30/2019 10:28 AM, Seymour J Metz wrote: >> Does it really matter if an application vs z/OS has a trap door >> vulnerability? > Not if you don't care about security. If you care then you must investigate > both. Please note that an unprivileged application can still have a dangerous > back door that compromises, e.g., privacy, by giving a user authorized to > access the application access more data than he is authorized to see. > >> In either case z/OS and the ESM's cannot function properly when the >> TRAP DOOR vulnerability is exploited. > It can if you don't install the broken application. > >> Shouldn't z/OS be able to protect itself from accidental and/or malicious >> vulnerabilities? > To quote Schiller, "Against stupidity the gods them
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
If the trap door is in an APF authorized library, then by convention it's part of the operating system, and would be considered a platform issue. Anything that is APF authorized is expected to adhere to the statement of integrity that z/OS publishes. Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Wednesday, May 29, 2019 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > A single TRAP DOOR code vulnerability pierces the veil of integrity > and can be used to compromise the mainframe. Is this a platform weakness? An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability. I'd be willing to bet a substantial amount that the majority of penetrations in z/OS are application, configuration, personnel and process vulnerabilities rather than z/OS vulnerabilities. > Would you say that the elimination of User Key Common storage is an > example of a z/OS change to address a mainframe platform weakness Partially. -- Shmuel (Seymour J.) Metz https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%7C4ec98728280a4395aab708d6e46ff2fd%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636947566821955527&sdata=Ggtx2UoZolPoAJZgbcdFshw16B%2B1Yy998xUO7Bts%2FzU%3D&reserved=0 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Wednesday, May 29, 2019 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR code vulnerability pierces the veil of integrity and can be used to compromise the mainframe. Is this a platform weakness? I think so. The platform relies on all code it runs adhering to certain rules. z/OS could be changed to better check and enforce those rules. Would you say that the elimination of User Key Common storage is an example of a z/OS change to address a mainframe platform weakness? I think so. An interesting observation. Thanks. On 5/29/2019 5:25 AM, R.S. wrote: > That's classical FUD. > Frightening people. > "if an exploit", "if job reads you RACF db", "unintended consequences". > What exactly hacking scenario can provide RACF db to the hacker? > Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user > attribute, even UPDATE to RACF db. But it's problem of people. > Mistakes, lack of time, lack of control, lack of skills. Not a > platform weakness. > > It's typical that assurance/lock/gun salesmen tend to talk about > risks, threats and dangers. They create a vision. > My English is poor, but I can observe it for two of debaters here. > It's visible. I don't like social engineering. > -- 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
In response to "Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see." As a developer of security interfaces for applications: It is extremely difficult to design an unprivileged application security interface in code that runs in PSW Key 8 problem state not apf-authorized. The security code path can be modified (if it is non-rent), frontended by using content supervision functions (ex - task lib), or bypassed. In addition, application storage areas + ESM (external security manager) credentials cannot be in key 8 storage as the application code could accidentally or maliciously modify them. A properly designed z/OS application would have separate application and system level programs and memory objects. These programs would be invoked differently (ex - EXEC PGM= vs a SVC or PC routine). The application code would call the system level programs whenever an application function needs to be performed that requires security checks. In this way the system level code + memory objects they reference cannot be accidentally or maliciously compromised by the application code or other programs running on the platform. So called unprivileged application security code is really just application code. Important (really). But I do not like calling it security code as it does not meet the due diligence required for system level security code. Calling application code "Unprivileged application security code" leads people to assume that the code has integrity and therefore is secure. In most cases, this is not true. It spreads a false sense of security. In response to "It can if you don't install the broken application." * Must of the code vulnerabilities I find are zero day vulnerabilities. This means there is no fix. If there is no fix then it is almost 100% certain that the client installing and/or running the product would have no idea that they are installing/running a back door on their system. * Before you install a product (how often does that happen these days?) do you ensure that all maintenance is applied or just hipers? What about integrity fix's? You probably have a different answer depending upon which vendor it is In response to "To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code." * I don't know who Schiller is. Can you clarify? Thanks. * As an example - The platform could make a new integrity rule such as: Only SVC 107 can turn on JSCBAUTH bit. Any other SVC or any PC routine that does it will abend with S047-98 (yes, I just created a new abend code for integrity - Byte me!). This would render useless most of the currently implemented "magic SVC or PC routines" that turn on JSCBAUTH bit that are running in the wild today (FYI - this is another sub-category of a TRAP DOOR vulnerability). There are ways to get around this (several come to mind as I write this) however I would ague that a change like this would benefit all users of the platform. The same business arguments that were used to eliminate Key 8 common storage usage could be used for this change. With similar benefits. On 5/30/2019 10:28 AM, Seymour J Metz wrote: Does it really matter if an application vs z/OS has a trap door vulnerability? Not if you don't care about security. If you care then you must investigate both. Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see. In either case z/OS and the ESM's cannot function properly when the TRAP DOOR vulnerability is exploited. It can if you don't install the broken application. Shouldn't z/OS be able to protect itself from accidental and/or malicious vulnerabilities? To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Thursday, May 30, 2019 7:28 AM To
Re: delete volume and unit information form DDDEF
Tom, Everything with ISV installs has version release in the DSN's. I've personally never liked SYMBOLICRELATE, so I don’t use it.Cloning process is boiled down to a standard set of batch jobs that just get run. Not much thought process involved. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Thursday, May 30, 2019 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On Thu, 30 May 2019 17:02:44 +, Jousma, David wrote: >Tom, > >Our ISV product installs have the VerRelease imbedded into the installation >datasets. We use a cloning process to aggregate the updated product onto a >ISV sysres that then removes the VerRelease from the dataset names. The >"master" ISV sysres contents are not cataloged, but the environment specific >ISV sysres (i.e. the active copy) of these volumes are all indirectly >cataloged to a &VNDV1 symbol. Dave, Ok, so that's how you run your ISV products, but what about the DDDEFs for them? Do they specify the "VerRelease" and no UNIT/VOLUME? It seems like using data set aliases with SYMBOLICRELATE would be simpler than your cloning process. -- Tom Marchant >___ >__ >Dave Jousma >AVP | Manager, Systems Engineering > >Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >Rapids, MI 49546 >616.653.8429 | fax: 616.653.2717 > > > >-Original Message > >Fom: IBM Mainframe Discussion List On Behalf >Of Tom Marchant >Sent: Thursday, May 30, 2019 11:44 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: delete volume and unit information form DDDEF > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or >unexpected emails** > >OT Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: > >>I personally, don't catalog the SMPE target and DLIB datasets > >Not for MVS data sets, but what about ISV products? > >-- >Tom Marchant > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or >unexpected emails** > >This e-mail transmission contains information that is confidential and may be >privileged. It is intended only for the addressee(s) named above. If you >receive this e-mail in error, please do not read, copy or disseminate it in >any manner. If you are not the intended recipient, any disclosure, copying, >distribution or use of the contents of this information is prohibited. Please >reply to the message immediately by informing the sender that the message was >misdirected. After replying, please erase it from your computer system. Your >assistance in correcting this error is appreciated. > > >-- >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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: delete volume and unit information form DDDEF
when I was contracting Y2K and had some global services folks working with me, that was the standard, and once I moved on I found this same methodology at other sites, I adopted this strategy and documented the process in my install and maintenance process, it works for me very well, (FOR MVS) I've see all the other strategies and each works well. Carmen Vitullo - Original Message - From: "Allan Staller" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2019 12:19:25 PM Subject: Re: delete volume and unit information form DDDEF I prefer to keep the SMP/E targets uncataloged. The prevents inadvertent updating of any running system. Extremely cheap (but effective) insurance. The SMP/E targets are used *ONLY* as SMP/E targets and *NEVER* on a running system. "Clones" are used by the running system. My 0.02 USD worth -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Thursday, May 30, 2019 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF We catalog *all* SMP/E data sets including those for z/OS. I don't see how *not* cataloging data sets increases integrity. At some point you have to distinguish among different releases by typing something somewhere. I'd rather do that in the HLQ. We decided long ago to 'preserve' (i.e. avoid deleting) the release-level user catalog created by Server Pac and utilize for the life of the release. So for example, we have DDDEFs for OSR21.SYS1.LINKLIB OSR23.SYS1.LINKLIB This involves aliases so that the data set on the actual target volume is always 'SYS1.LINKLIB' for any release. The release-named volume can then be dump/restored without futzing with names. Once the catalog is correct, data set management is pretty straightforward. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Thursday, May 30, 2019 8:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: delete volume and unit information form DDDEF On Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: >I personally, don't catalog the SMPE target and DLIB datasets Not for MVS data sets, but what about ISV products? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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: delete volume and unit information form DDDEF
On Thu, 30 May 2019 17:02:44 +, Jousma, David wrote: >Tom, > >Our ISV product installs have the VerRelease imbedded into the installation >datasets. We use a cloning process to aggregate the updated product onto a >ISV sysres that then removes the VerRelease from the dataset names. The >"master" ISV sysres contents are not cataloged, but the environment specific >ISV sysres (i.e. the active copy) of these volumes are all indirectly >cataloged to a &VNDV1 symbol. Dave, Ok, so that's how you run your ISV products, but what about the DDDEFs for them? Do they specify the "VerRelease" and no UNIT/VOLUME? It seems like using data set aliases with SYMBOLICRELATE would be simpler than your cloning process. -- Tom Marchant >_ >Dave Jousma >AVP | Manager, Systems Engineering > >Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, >MI 49546 >616.653.8429 | fax: 616.653.2717 > > > >-Original Message > >Fom: IBM Mainframe Discussion List On Behalf Of Tom >Marchant >Sent: Thursday, May 30, 2019 11:44 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: delete volume and unit information form DDDEF > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >OT Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: > >>I personally, don't catalog the SMPE target and DLIB datasets > >Not for MVS data sets, but what about ISV products? > >-- >Tom Marchant > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL >EMAIL** > >**DO NOT open attachments or click on links from unknown senders or unexpected >emails** > >This e-mail transmission contains information that is confidential and may be >privileged. It is intended only for the addressee(s) named above. If you >receive this e-mail in error, please do not read, copy or disseminate it in >any manner. If you are not the intended recipient, any disclosure, copying, >distribution or use of the contents of this information is prohibited. Please >reply to the message immediately by informing the sender that the message was >misdirected. After replying, please erase it from your computer system. Your >assistance in correcting this error is appreciated. > > >-- >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: delete volume and unit information form DDDEF
I prefer to keep the SMP/E targets uncataloged. The prevents inadvertent updating of any running system. Extremely cheap (but effective) insurance. The SMP/E targets are used *ONLY* as SMP/E targets and *NEVER* on a running system. "Clones" are used by the running system. My 0.02 USD worth -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Thursday, May 30, 2019 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF We catalog *all* SMP/E data sets including those for z/OS. I don't see how *not* cataloging data sets increases integrity. At some point you have to distinguish among different releases by typing something somewhere. I'd rather do that in the HLQ. We decided long ago to 'preserve' (i.e. avoid deleting) the release-level user catalog created by Server Pac and utilize for the life of the release. So for example, we have DDDEFs for OSR21.SYS1.LINKLIB OSR23.SYS1.LINKLIB This involves aliases so that the data set on the actual target volume is always 'SYS1.LINKLIB' for any release. The release-named volume can then be dump/restored without futzing with names. Once the catalog is correct, data set management is pretty straightforward. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Thursday, May 30, 2019 8:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: delete volume and unit information form DDDEF On Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: >I personally, don't catalog the SMPE target and DLIB datasets Not for MVS data sets, but what about ISV products? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: delete volume and unit information form DDDEF
Tom, Our ISV product installs have the VerRelease imbedded into the installation datasets. We use a cloning process to aggregate the updated product onto a ISV sysres that then removes the VerRelease from the dataset names. The "master" ISV sysres contents are not cataloged, but the environment specific ISV sysres (i.e. the active copy) of these volumes are all indirectly cataloged to a &VNDV1 symbol. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Thursday, May 30, 2019 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: >I personally, don't catalog the SMPE target and DLIB datasets Not for MVS data sets, but what about ISV products? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
Thanks! On 5/30/2019 9:20 AM, Ray Overby wrote: ESM - External Security Manager. I use ESM when I am talking about ACF2, RACF, and TSS. On 5/30/2019 10:20 AM, Tom Brennan wrote: I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? On 5/30/2019 4:28 AM, Ray Overby wrote: In response to "An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability." Does it really matter if an application vs z/OS has a trap door vulnerability? In either case z/OS and the ESM's cannot function ... -- 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: Fwd: Just how secure are mainframes? | Trevor Eddolls
ESM - External Security Manager. I use ESM when I am talking about ACF2, RACF, and TSS. On 5/30/2019 10:20 AM, Tom Brennan wrote: I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? On 5/30/2019 4:28 AM, Ray Overby wrote: In response to "An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability." Does it really matter if an application vs z/OS has a trap door vulnerability? In either case z/OS and the ESM's cannot function ... -- 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: Fwd: Just how secure are mainframes? | Trevor Eddolls
Yes. On 5/30/2019 11:01 AM, Seymour J Metz wrote: It is obvious that IBM has vulnerabilities in z/OS. Water is wet; I've reported one such. But not all vulnerabilities are trap doors. Do you know of a trap door installed by IBM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lou Losee Sent: Thursday, May 30, 2019 11:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls Just because it has not been brought up and I think it is pertinent to this discussion. It is obvious that IBM has vulnerabilities in z/OS. The existence of the integrity APARs are proof of that. There may not be as many as the fixes released for Windows or Mac, but they do exist. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Thu, May 30, 2019 at 10:33 AM Seymour J Metz wrote: I've never seen a trap door installed by IBM. What I've seen was trap doors installed by data center staff and trap doors in 3rd party software. In those cases it's not the platform that is insecure but the installation. Would you blame the lock if someone leaves their key under the doormat? d) You know how to fix the trap door but management won't let you. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of R.S. Sent: Thursday, May 30, 2019 7:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls As Shmuel said an application with a trap door is an application vulnerability. Ideed, IF you know such trap door, you know z/OS vulnerability, which proves the platform is not immune. Is it as vulnerable as Windows? No, because it's still not binary, some systems are still more secure than others. Last, but not least: assuming you know such trap door. Or even several trap doors. What next? a) you submitted it to IBM and they are trying to fix it. b) despite of a) you know how to fix it by homegrown code/configuration/procedure and you offer it as a service. c) the trap door cannot be fixed and then your services are disputable - you cannot help. Of course the above *regards only the trap doors you know*, not your services portfolio. Besides that you can provide many valuable services regarding security, but not platform issues, rather people mistakes, misconfigurations, erroneous procedures, etc. It is worth to emphasize: while z/OS is quite secure, it may be quite complex to configure it properly. And here there is a field for Ray, ITschak, RSM Partners, me, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-05-29 o 17:11, Ray Overby pisze: In response to "Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR code vulnerability pierces the veil of integrity and can be used to compromise the mainframe. Is this a platform weakness? I think so. The platform relies on all code it runs adhering to certain rules. z/OS could be changed to better check and enforce those rules. Would you say that the elimination of User Key Common storage is an example of a z/OS change to address a mainframe platform weakness? I think so. An interesting observation. Thanks. On 5/29/2019 5:25 AM, R.S. wrote: That's classical FUD. Frightening people. "if an exploit", "if job reads you RACF db", "unintended consequences". What exactly hacking scenario can provide RACF db to the hacker? Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user attribute, even UPDATE to RACF db. But it's problem of people. Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness. It's typical that assurance/lock/gun salesmen tend to talk about risks, threats and dangers. They create a vision. My English is poor, but I can observe it for two of debaters here. It's visible. I don't like social engineering. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXunQmxen_zjQXxLP_IX-Ug58lArQAAiDC5ACZe4lMf0-jck0ghav2cqfF_LnMQM_LW30FcxGv_RtgvQgLZhcGgFKSX0F8zBNsaREU7crKD5N9qMEep08A3gQGMJb3xeCyGFXo40ow3C4kklzJKo8ceb3j4dNkhTHXRroJVJvFgw8OmxGSZLh5Cd0s4plzQ0KQOs4Xy6uxx3qpKYcs3SBxUf0fBQo3DcK2kSBE4k3ScihhcNjTJwUDXdyrULocL9bMwXrAVups_q5FzLwr
Re: delete volume and unit information form DDDEF
We catalog *all* SMP/E data sets including those for z/OS. I don't see how *not* cataloging data sets increases integrity. At some point you have to distinguish among different releases by typing something somewhere. I'd rather do that in the HLQ. We decided long ago to 'preserve' (i.e. avoid deleting) the release-level user catalog created by Server Pac and utilize for the life of the release. So for example, we have DDDEFs for OSR21.SYS1.LINKLIB OSR23.SYS1.LINKLIB This involves aliases so that the data set on the actual target volume is always 'SYS1.LINKLIB' for any release. The release-named volume can then be dump/restored without futzing with names. Once the catalog is correct, data set management is pretty straightforward. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Thursday, May 30, 2019 8:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: delete volume and unit information form DDDEF On Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: >I personally, don't catalog the SMPE target and DLIB datasets Not for MVS data sets, but what about ISV products? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need a second set of eyes to look at my NPF settings
By setting: $TPRT7,FORMS=* I am now getting my print into the NPF queue. I was just too close to it to see it. Thanks, Tony Thigpen Elardus Engelbrecht wrote on 5/30/19 11:34 AM: Dana Mitchell wrote: Tony Thigpen wrote: Maybe you have a 'better way' to use NPF. Could you give me an example of what you are doing? So JES2 never selects output for that printer? You don't ever get $HASP150 ? If that is the case, turn on the debug statement for JES2, something like $T DEBUG,SECURITY=Y I believe there are also other DEBUG statements, but you can also have a look in your HASPARM member for your JES2 to check out the output classes. What I do is all output for network printers goes to Class C. Different destination for each different remote printer such as OPSPRT, SYSPRT, XRXPRT. Different forms use different Options member. My printer is defined like this: PRT3CLASS=C, MODE=FSS, FSS=TCPFSS, FCB=STD8, CKPTPAGE=100, START=YES, WS=(W,R,Q,PRM,LIM/F,UCS,FCB,P), ROUTECDE=(*PRT) To Tony Thigpen after checking Dana's definitions for JES2: I see your CLASS=R match your SDSF screenprint, but I don't see any definition of your FORM=TONY (as seen from your SDSF). After you started that printer, I see FORMS=(WL1,,,), Is that correct? Is your WS=(Q,R/) correct? Perhaps the Work Selection is too restricted for your printer. I am not sure about the other criterias including that ROUTECDE... DISCLAIMER: I never worked with NPF printers, but with other types where connected to JES2 and other printing subsystems. Good luck! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> It is obvious that IBM has vulnerabilities in z/OS. Water is wet; I've reported one such. But not all vulnerabilities are trap doors. Do you know of a trap door installed by IBM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lou Losee Sent: Thursday, May 30, 2019 11:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls Just because it has not been brought up and I think it is pertinent to this discussion. It is obvious that IBM has vulnerabilities in z/OS. The existence of the integrity APARs are proof of that. There may not be as many as the fixes released for Windows or Mac, but they do exist. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Thu, May 30, 2019 at 10:33 AM Seymour J Metz wrote: > I've never seen a trap door installed by IBM. What I've seen was trap > doors installed by data center staff and trap doors in 3rd party software. > In those cases it's not the platform that is insecure but the installation. > Would you blame the lock if someone leaves their key under the doormat? > > d) You know how to fix the trap door but management won't let you. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of R.S. > Sent: Thursday, May 30, 2019 7:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > As Shmuel said an application with a trap door is an application > vulnerability. > Ideed, IF you know such trap door, you know z/OS vulnerability, which > proves the platform is not immune. Is it as vulnerable as Windows? No, > because it's still not binary, some systems are still more secure than > others. > > Last, but not least: assuming you know such trap door. Or even several > trap doors. What next? > a) you submitted it to IBM and they are trying to fix it. > b) despite of a) you know how to fix it by homegrown > code/configuration/procedure and you offer it as a service. > c) the trap door cannot be fixed and then your services are disputable - > you cannot help. > > Of course the above *regards only the trap doors you know*, not your > services portfolio. > Besides that you can provide many valuable services regarding security, > but not platform issues, rather people mistakes, misconfigurations, > erroneous procedures, etc. > It is worth to emphasize: while z/OS is quite secure, it may be quite > complex to configure it properly. And here there is a field for Ray, > ITschak, RSM Partners, me, etc. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 2019-05-29 o 17:11, Ray Overby pisze: > > In response to "Mistakes, lack of time, lack of control, lack of > > skills. Not a platform weakness." comment: The mainframe platform, > > z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR > > code vulnerability pierces the veil of integrity and can be used to > > compromise the mainframe. Is this a platform weakness? I think so. The > > platform relies on all code it runs adhering to certain rules. z/OS > > could be changed to better check and enforce those rules. > > > > Would you say that the elimination of User Key Common storage is an > > example of a z/OS change to address a mainframe platform weakness? I > > think so. > > > > An interesting observation. Thanks. > > > > On 5/29/2019 5:25 AM, R.S. wrote: > >> That's classical FUD. > >> Frightening people. > >> "if an exploit", "if job reads you RACF db", "unintended consequences". > >> What exactly hacking scenario can provide RACF db to the hacker? > >> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO > >> user attribute, even UPDATE to RACF db. But it's problem of people. > >> Mistakes, lack of time, lack of control, lack of skills. Not a > >> platform weakness. > >> > >> It's typical that assurance/lock/gun salesmen tend to talk about > >> risks, threats and dangers. They create a vision. > >> My English is poor, but I can observe it for two of debaters here. > >> It's visible. I don't like social engineering. > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXunQmxen_zjQXxLP_IX-Ug58lArQAAiDC5ACZe4lMf0-jck0ghav2cqfF_LnMQM_LW30FcxGv_RtgvQgLZhcGgFKSX
Re: delete volume and unit information form DDDEF
currently I only support one ISV product, I have my MVS hat on currently, so yes ,I do use the cataloged version of the datasets for ISV's on my sandbox LPAR. Carmen Vitullo - Original Message - From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2019 10:43:52 AM Subject: Re: delete volume and unit information form DDDEF On Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: >I personally, don't catalog the SMPE target and DLIB datasets Not for MVS data sets, but what about ISV products? -- Tom Marchant -- 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: delete volume and unit information form DDDEF
On Thu, 30 May 2019 14:42:39 +, Jousma, David wrote: >I personally, don't catalog the SMPE target and DLIB datasets Not for MVS data sets, but what about ISV products? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
Just because it has not been brought up and I think it is pertinent to this discussion. It is obvious that IBM has vulnerabilities in z/OS. The existence of the integrity APARs are proof of that. There may not be as many as the fixes released for Windows or Mac, but they do exist. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Thu, May 30, 2019 at 10:33 AM Seymour J Metz wrote: > I've never seen a trap door installed by IBM. What I've seen was trap > doors installed by data center staff and trap doors in 3rd party software. > In those cases it's not the platform that is insecure but the installation. > Would you blame the lock if someone leaves their key under the doormat? > > d) You know how to fix the trap door but management won't let you. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of R.S. > Sent: Thursday, May 30, 2019 7:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > As Shmuel said an application with a trap door is an application > vulnerability. > Ideed, IF you know such trap door, you know z/OS vulnerability, which > proves the platform is not immune. Is it as vulnerable as Windows? No, > because it's still not binary, some systems are still more secure than > others. > > Last, but not least: assuming you know such trap door. Or even several > trap doors. What next? > a) you submitted it to IBM and they are trying to fix it. > b) despite of a) you know how to fix it by homegrown > code/configuration/procedure and you offer it as a service. > c) the trap door cannot be fixed and then your services are disputable - > you cannot help. > > Of course the above *regards only the trap doors you know*, not your > services portfolio. > Besides that you can provide many valuable services regarding security, > but not platform issues, rather people mistakes, misconfigurations, > erroneous procedures, etc. > It is worth to emphasize: while z/OS is quite secure, it may be quite > complex to configure it properly. And here there is a field for Ray, > ITschak, RSM Partners, me, etc. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 2019-05-29 o 17:11, Ray Overby pisze: > > In response to "Mistakes, lack of time, lack of control, lack of > > skills. Not a platform weakness." comment: The mainframe platform, > > z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR > > code vulnerability pierces the veil of integrity and can be used to > > compromise the mainframe. Is this a platform weakness? I think so. The > > platform relies on all code it runs adhering to certain rules. z/OS > > could be changed to better check and enforce those rules. > > > > Would you say that the elimination of User Key Common storage is an > > example of a z/OS change to address a mainframe platform weakness? I > > think so. > > > > An interesting observation. Thanks. > > > > On 5/29/2019 5:25 AM, R.S. wrote: > >> That's classical FUD. > >> Frightening people. > >> "if an exploit", "if job reads you RACF db", "unintended consequences". > >> What exactly hacking scenario can provide RACF db to the hacker? > >> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO > >> user attribute, even UPDATE to RACF db. But it's problem of people. > >> Mistakes, lack of time, lack of control, lack of skills. Not a > >> platform weakness. > >> > >> It's typical that assurance/lock/gun salesmen tend to talk about > >> risks, threats and dangers. They create a vision. > >> My English is poor, but I can observe it for two of debaters here. > >> It's visible. I don't like social engineering. > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXunQmxen_zjQXxLP_IX-Ug58lArQAAiDC5ACZe4lMf0-jck0ghav2cqfF_LnMQM_LW30FcxGv_RtgvQgLZhcGgFKSX0F8zBNsaREU7crKD5N9qMEep08A3gQGMJb3xeCyGFXo40ow3C4kklzJKo8ceb3j4dNkhTHXRroJVJvFgw8OmxGSZLh5Cd0s4plzQ0KQOs4Xy6uxx3qpKYcs3SBxUf0fBQo3DcK2kSBE4k3ScihhcNjTJwUDXdyrULocL9bMwXrAVups_q5FzLwrUN5zsycmBegw6QssGwOBAEpAD4PJuMl7bPaecJqL_m4uu_J6gwb2aG9F4h4wvt2z8H95YdG86TQJTbDpHc/http%3A%2F%2Fwww.mBank.pl, > e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całoś
Re: Need a second set of eyes to look at my NPF settings
Dana Mitchell wrote: >Your output has PZGWHFL1 as a destination, but your printer is set to >ROUTECDE=(LOCAL) so it's only going to select printout with *NO* destination >coded. Thats why the printer isn't selecting that output. Do you have a NPF >route defined for PZGWHFL1? >You either need to take the dest off your output, or change the printer to >ROUTECDE=(*) I think Good catch! I mis-ROUTE(cde) that one little bugger... ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need a second set of eyes to look at my NPF settings
Dana Mitchell wrote: >Tony Thigpen wrote: >>Maybe you have a 'better way' to use NPF. Could you give me an example of >>what you are doing? >So JES2 never selects output for that printer? You don't ever get $HASP150 ? If that is the case, turn on the debug statement for JES2, something like $T DEBUG,SECURITY=Y I believe there are also other DEBUG statements, but you can also have a look in your HASPARM member for your JES2 to check out the output classes. >What I do is all output for network printers goes to Class C. Different >destination for each different remote printer such as OPSPRT, SYSPRT, XRXPRT. > >Different forms use different Options member. >My printer is defined like this: >PRT3CLASS=C, >MODE=FSS, >FSS=TCPFSS, >FCB=STD8, >CKPTPAGE=100, >START=YES, >WS=(W,R,Q,PRM,LIM/F,UCS,FCB,P), >ROUTECDE=(*PRT) To Tony Thigpen after checking Dana's definitions for JES2: I see your CLASS=R match your SDSF screenprint, but I don't see any definition of your FORM=TONY (as seen from your SDSF). After you started that printer, I see FORMS=(WL1,,,), Is that correct? Is your WS=(Q,R/) correct? Perhaps the Work Selection is too restricted for your printer. I am not sure about the other criterias including that ROUTECDE... DISCLAIMER: I never worked with NPF printers, but with other types where connected to JES2 and other printing subsystems. Good luck! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
I've never seen a trap door installed by IBM. What I've seen was trap doors installed by data center staff and trap doors in 3rd party software. In those cases it's not the platform that is insecure but the installation. Would you blame the lock if someone leaves their key under the doormat? d) You know how to fix the trap door but management won't let you. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of R.S. Sent: Thursday, May 30, 2019 7:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls As Shmuel said an application with a trap door is an application vulnerability. Ideed, IF you know such trap door, you know z/OS vulnerability, which proves the platform is not immune. Is it as vulnerable as Windows? No, because it's still not binary, some systems are still more secure than others. Last, but not least: assuming you know such trap door. Or even several trap doors. What next? a) you submitted it to IBM and they are trying to fix it. b) despite of a) you know how to fix it by homegrown code/configuration/procedure and you offer it as a service. c) the trap door cannot be fixed and then your services are disputable - you cannot help. Of course the above *regards only the trap doors you know*, not your services portfolio. Besides that you can provide many valuable services regarding security, but not platform issues, rather people mistakes, misconfigurations, erroneous procedures, etc. It is worth to emphasize: while z/OS is quite secure, it may be quite complex to configure it properly. And here there is a field for Ray, ITschak, RSM Partners, me, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-05-29 o 17:11, Ray Overby pisze: > In response to "Mistakes, lack of time, lack of control, lack of > skills. Not a platform weakness." comment: The mainframe platform, > z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR > code vulnerability pierces the veil of integrity and can be used to > compromise the mainframe. Is this a platform weakness? I think so. The > platform relies on all code it runs adhering to certain rules. z/OS > could be changed to better check and enforce those rules. > > Would you say that the elimination of User Key Common storage is an > example of a z/OS change to address a mainframe platform weakness? I > think so. > > An interesting observation. Thanks. > > On 5/29/2019 5:25 AM, R.S. wrote: >> That's classical FUD. >> Frightening people. >> "if an exploit", "if job reads you RACF db", "unintended consequences". >> What exactly hacking scenario can provide RACF db to the hacker? >> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO >> user attribute, even UPDATE to RACF db. But it's problem of people. >> Mistakes, lack of time, lack of control, lack of skills. Not a >> platform weakness. >> >> It's typical that assurance/lock/gun salesmen tend to talk about >> risks, threats and dangers. They create a vision. >> My English is poor, but I can observe it for two of debaters here. >> It's visible. I don't like social engineering. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,http://secure-web.cisco.com/14ILHCRRunYvlSTtGew3dxkMnoq-EQXunQmxen_zjQXxLP_IX-Ug58lArQAAiDC5ACZe4lMf0-jck0ghav2cqfF_LnMQM_LW30FcxGv_RtgvQgLZhcGgFKSX0F8zBNsaREU7crKD5N9qMEep08A3gQGMJb3xeCyGFXo40ow3C4kklzJKo8ceb3j4dNkhTHXRroJVJvFgw8OmxGSZLh5Cd0s4plzQ0KQOs4Xy6uxx3qpKYcs3SBxUf0fBQo3DcK2kSBE4k3ScihhcNjTJwUDXdyrULocL9bMwXrAVups_q5FzLwrUN5zsycmBegw6QssGwOBAEpAD4PJuMl7bPaecJqL_m4uu_J6gwb2aG9F4h4wvt2z8H95YdG86TQJTbDpHc/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18,
Re: Need a second set of eyes to look at my NPF settings
On Thu, 30 May 2019 10:50:09 -0400, Tony Thigpen wrote: > Display Filter View Print Options Search Help > > >SDSF OUTPUT ALL CLASSES ALL FORMSLINES 1,068 LINE 1-8 (8) >NP JOBNAME JobIDOwnerPrty C FormsDest Tot-Rec > TONY JOB22436 TTHIGPE50 R TONY PZGWHFL1 > 128 > Your output has PZGWHFL1 as a destination, but your printer is set to ROUTECDE=(LOCAL) so it's only going to select printout with *NO* destination coded. Thats why the printer isn't selecting that output. Do you have a NPF route defined for PZGWHFL1? You either need to take the dest off your output, or change the printer to ROUTECDE=(*) I think Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Classification: Public > Not exactly. It is a set of PTFs that have been extensively tested together > by IBM. > Then they have been adopted as a whole by many shops. > > -- > Tom Marchant Is that true? I thought it was just the CST that was extensively tested; that's only released quarterly, whereas RSUs are released every month. -- Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
> Does it really matter if an application vs z/OS has a trap door vulnerability? Not if you don't care about security. If you care then you must investigate both. Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see. > In either case z/OS and the ESM's cannot function > properly when the TRAP DOOR vulnerability is exploited. It can if you don't install the broken application. > Shouldn't z/OS be able to protect itself from accidental and/or malicious > vulnerabilities? To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Thursday, May 30, 2019 7:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability." Does it really matter if an application vs z/OS has a trap door vulnerability? In either case z/OS and the ESM's cannot function properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS be able to protect itself from accidental and/or malicious vulnerabilities? Isn't that what a platform is supposed to do? Isn't that a requirement of a secure system? Every program in z/OS has certain rules of the road it must abide by. System level programs (PSW Key 0-7, Supervisor State, APF authorized) regardless of whether they are in z/OS or an application have additional rules they must adhere to (i.e. - they must not violate the integrity of z/OS). These rules of the road are the responsibility of and dictated by the platform. Integrity is a platform issue. One of the reason's the mainframe is the most secure-able platform is at least partially based on integrity. Integrity as implemented by the platform is why security is possible. Without platform integrity security is not possible. So all code (z/OS and application) that operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF authorized) must not violate the integrity rules. Failure of a single program regardless of whether it is part of z/OS or an application will allow a hacker to compromise that system and all data on it. In response to "I'd be willing to bet a substantial amount that the majority of penetrations in z/OS are application, configuration, personnel and process vulnerabilities rather than z/OS vulnerabilities." In terms of numbers of vulnerabilities there are fewer code based vulnerabilities (TRAP DOOR is one example of a code based vulnerabilities - there are others) vs configuration based vulnerabilities. I would point out that a hacker only needs a single TRAP DOOR vulnerability to compromise the platform regardless of how the platform is configured. So fewer code based vulnerabilities does not help. All code based vulnerabilities have to be removed from the system in order to secure the platform. On 5/29/2019 2:57 PM, Seymour J Metz wrote: >> A single TRAP DOOR code vulnerability pierces the veil of integrity and >> can be used >> to compromise the mainframe. Is this a platform weakness? > An application with a trap door is an application vulnerability. If there is > a trap door in z/OS itself then that's a platform vulnerability. I'd be > willing to bet a substantial amount that the majority of penetrations in z/OS > are application, configuration, personnel and process vulnerabilities rather > than z/OS vulnerabilities. > >> Would you say that the elimination of User Key Common storage is an >> example of a z/OS change to address a mainframe platform weakness > Partially. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Ray Overby > Sent: Wednesday, May 29, 2019 11:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > In response to "Mistakes, lack of time, lack of control, lack of skills. > Not a platform weakness." comment: The mainframe platform, z/OS, and > ESM's all rely on integrity to function. A single TRAP DOOR code > vulnerability pierces the veil of integrity and can be used to > compromise the mainframe. Is this a platform weakness? I think so. The > platform relies on all code it runs adhering to certain rules
Re: [External] Re: Need a second set of eyes to look at my NPF settings
Are you using NPFVTAM and NPFQMGR? If so, are they running? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Thursday, May 30, 2019 9:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Need a second set of eyes to look at my NPF settings Display Filter View Print Options Search Help SDSF OUTPUT ALL CLASSES ALL FORMSLINES 1,068 LINE 1-8 (8) NP JOBNAME JobIDOwnerPrty C FormsDest Tot-Rec TONY JOB22436 TTHIGPE50 R TONY PZGWHFL1 128 $SPRT7 START NPF.FSS1,,,(JES2,0001),SUB=JES2 $HASP000 OK $HASP100 NPF ON STCINRDR IEF695I START NPF WITH JOBNAME NPF IS ASSIGNED TO USER NPF , GROUP STASKS $HASP373 NPF STARTED IEF403I NPF - STARTED - TIME=10.49.06 EZY6101I FSS1 FSS=007000, FSA=009740, FSD=00CC28, FSJ=00E420 EZY6102I FSS1 FSID=0001, ASID=006B, SUB=JES2, ROUT= 2 EZY6110I FSS1 OPTS: AMODE=31,CONNECT-WTOR=NONE, EZY6110I FSS1 OPTS: ESTAE-SDUMP=YES,ESTAE-WTOR=NO, EZY6110I FSS1 OPTS: FSA-TERM=0,MSG-SUPPRESS=INFO2, EZY6110I FSS1 OPTS: MSG1-SCROLL=NO,NOTIFY=YES, EZY6110I FSS1 OPTS: QSAMLRECL=4092,SEPARATORS=YES, EZY6110I FSS1 OPTS: SJF=YES,SMF=YES,SPIN=GROUP, EZY6110I FSS1 OPTS: SPIN-CLASS=Z,WAITS-CA=(0MS,0MS), EZY6110I FSS1 OPTS: WAITS-SNA=(0MS,0MS) EZY0676I STARTUP VALUE FOR DATASETPREFIX TCPIP EZY0676I STARTUP VALUE FOR TCPIPJOBNAME TCPIPP EZY0676I STARTUP VALUE FOR NPFPRINTPREFIXSYS2.NPF EZY0676I STARTUP VALUE FOR NPFJESALLOCATION CYL 00050 00050 EZY0676I STARTUP VALUE FOR NPFVTAMALLOCATION TRK 1 1 EZY0676I STARTUP VALUE FOR NPFQMGRTHREAD 8 EZY0676I STARTUP VALUE FOR NPFUNIT SYSDA EZY0667I PRINT STARTUP USED DATASET SYS1.PARMLIB EZY0666I File Management Initialization Completed EZY6121I FSS1 FSS-AMODE/JES-AMODE/RESOLVED-CB-RMODE=31/31/31 EZY6175IFSS1 PRT7 FSA FSID=00010001, UCB= , AMODE=31 $HASP160 PRT7 INACTIVE - CLASS=R Tony Thigpen Dana Mitchell wrote on 5/30/19 10:45 AM: > On Thu, 30 May 2019 09:59:14 -0400, Tony Thigpen wrote: > >> Maybe you have a 'better way' to use NPF. Could you give me an >> example of what you are doing? >> > So JES2 never selects output for that printer? You don't ever get $HASP150 ? > > What I do is all output for network printers goes to Class C. Different > destination for each different remote printer such as OPSPRT, SYSPRT, XRXPRT. > Different forms use different Options member. > > My printer is defined like this: > > PRT3CLASS=C, > MODE=FSS, > FSS=TCPFSS, > FCB=STD8, > CKPTPAGE=100, > START=YES, > WS=(W,R,Q,PRM,LIM/F,UCS,FCB,P), > ROUTECDE=(*PRT) > > I'm going from fuzzy memory here, as I set this up a number of years ago and > our environment is pretty static, haven't had to revisit it much. > Dana > > > > -- > 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On Wed, 29 May 2019 23:06:01 +, Jesse 1 Robinson wrote: >The advertised virtue of RSU is that it represents a well-defined bundle of >fixes that have been tested together in 'many' shops. Not exactly. It is a set of PTFs that have been extensively tested together by IBM. Then they have been adopted as a whole by many shops. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
I have been under the impression it stands for External Security Manager, of which the "big 3" would be RACF, ACF2, Top Secret. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Thursday, May 30, 2019 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Fwd: Just how secure are mainframes? | Trevor Eddolls I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? On 5/30/2019 4:28 AM, Ray Overby wrote: > In response to "An application with a trap door is an application > vulnerability. If there is a trap door in z/OS itself then that's a > platform vulnerability." > > Does it really matter if an application vs z/OS has a trap door > vulnerability? In either case z/OS and the ESM's cannot function ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: master JCL
On Wed, 29 May 2019 22:10:23 +, Pommier, Rex wrote: >Hello listers, > >I'm apparently having a case of brain-rrain. Is there an easy way to display >the currently used master JCL? I know I can look at LINKLIB and PARMLIB and >see what's there, but is there a way of displaying what's actually running? I >thought at one point in time I could see it in Omegamon or someplace. In this >case, google was not my friend. :-( Any assistance would be greatly >appreciated. SHOWMVS maybe? On the CBT tape. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
I've seen the acronym ESM a few times in this thread. I'll assume that means "Enterprise Security Management", and I'll guess it refers to security processes (not RACF), such as assigning userid's, making sure people have just the access they need, periodic audits, etc. Am I even close? On 5/30/2019 4:28 AM, Ray Overby wrote: In response to "An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability." Does it really matter if an application vs z/OS has a trap door vulnerability? In either case z/OS and the ESM's cannot function ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: delete volume and unit information form DDDEF
See Chapter 24 of https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa232275/$file/gim1000_v2r3.pdf for the syntax of the DEL DDDEF UCLIN command. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Gadi Ben-Avi Sent: Thursday, May 30, 2019 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: delete volume and unit information form DDDEF Hi, I have DDDEFs that have volume and unit information coded. How do I delete that information in batch? I am using z/OS v2.3 Thanks -- 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: Need a second set of eyes to look at my NPF settings
Display Filter View Print Options Search Help SDSF OUTPUT ALL CLASSES ALL FORMSLINES 1,068 LINE 1-8 (8) NP JOBNAME JobIDOwnerPrty C FormsDest Tot-Rec TONY JOB22436 TTHIGPE50 R TONY PZGWHFL1 128 $SPRT7 START NPF.FSS1,,,(JES2,0001),SUB=JES2 $HASP000 OK $HASP100 NPF ON STCINRDR IEF695I START NPF WITH JOBNAME NPF IS ASSIGNED TO USER NPF , GROUP STASKS $HASP373 NPF STARTED IEF403I NPF - STARTED - TIME=10.49.06 EZY6101I FSS1 FSS=007000, FSA=009740, FSD=00CC28, FSJ=00E420 EZY6102I FSS1 FSID=0001, ASID=006B, SUB=JES2, ROUT= 2 EZY6110I FSS1 OPTS: AMODE=31,CONNECT-WTOR=NONE, EZY6110I FSS1 OPTS: ESTAE-SDUMP=YES,ESTAE-WTOR=NO, EZY6110I FSS1 OPTS: FSA-TERM=0,MSG-SUPPRESS=INFO2, EZY6110I FSS1 OPTS: MSG1-SCROLL=NO,NOTIFY=YES, EZY6110I FSS1 OPTS: QSAMLRECL=4092,SEPARATORS=YES, EZY6110I FSS1 OPTS: SJF=YES,SMF=YES,SPIN=GROUP, EZY6110I FSS1 OPTS: SPIN-CLASS=Z,WAITS-CA=(0MS,0MS), EZY6110I FSS1 OPTS: WAITS-SNA=(0MS,0MS) EZY0676I STARTUP VALUE FOR DATASETPREFIX TCPIP EZY0676I STARTUP VALUE FOR TCPIPJOBNAME TCPIPP EZY0676I STARTUP VALUE FOR NPFPRINTPREFIXSYS2.NPF EZY0676I STARTUP VALUE FOR NPFJESALLOCATION CYL 00050 00050 EZY0676I STARTUP VALUE FOR NPFVTAMALLOCATION TRK 1 1 EZY0676I STARTUP VALUE FOR NPFQMGRTHREAD 8 EZY0676I STARTUP VALUE FOR NPFUNIT SYSDA EZY0667I PRINT STARTUP USED DATASET SYS1.PARMLIB EZY0666I File Management Initialization Completed EZY6121I FSS1 FSS-AMODE/JES-AMODE/RESOLVED-CB-RMODE=31/31/31 EZY6175IFSS1 PRT7 FSA FSID=00010001, UCB= , AMODE=31 $HASP160 PRT7 INACTIVE - CLASS=R Tony Thigpen Dana Mitchell wrote on 5/30/19 10:45 AM: On Thu, 30 May 2019 09:59:14 -0400, Tony Thigpen wrote: Maybe you have a 'better way' to use NPF. Could you give me an example of what you are doing? So JES2 never selects output for that printer? You don't ever get $HASP150 ? What I do is all output for network printers goes to Class C. Different destination for each different remote printer such as OPSPRT, SYSPRT, XRXPRT. Different forms use different Options member. My printer is defined like this: PRT3CLASS=C, MODE=FSS, FSS=TCPFSS, FCB=STD8, CKPTPAGE=100, START=YES, WS=(W,R,Q,PRM,LIM/F,UCS,FCB,P), ROUTECDE=(*PRT) I'm going from fuzzy memory here, as I set this up a number of years ago and our environment is pretty static, haven't had to revisit it much. Dana -- 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: Need a second set of eyes to look at my NPF settings
On Thu, 30 May 2019 09:59:14 -0400, Tony Thigpen wrote: >Maybe you have a 'better way' to use NPF. Could you give me an example >of what you are doing? > So JES2 never selects output for that printer? You don't ever get $HASP150 ? What I do is all output for network printers goes to Class C. Different destination for each different remote printer such as OPSPRT, SYSPRT, XRXPRT. Different forms use different Options member. My printer is defined like this: PRT3CLASS=C, MODE=FSS, FSS=TCPFSS, FCB=STD8, CKPTPAGE=100, START=YES, WS=(W,R,Q,PRM,LIM/F,UCS,FCB,P), ROUTECDE=(*PRT) I'm going from fuzzy memory here, as I set this up a number of years ago and our environment is pretty static, haven't had to revisit it much. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: delete volume and unit information form DDDEF
good Point, I do not use the catalog for any of my SMPE target or DLIB
libraries, I keep these on seperate SMPE volumes
Carmen Vitullo
- Original Message -
From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, May 30, 2019 9:42:39 AM
Subject: Re: delete volume and unit information form DDDEF
Something like this. Now, that being said, I personally, don't catalog the SMPE
target and DLIB datasets, and specifically use UNIT/VOL to point to them so
that there is NO Chance of accidentally updating the wrong set of datasets
(i.e. the running version).
SET BDY(yourzone) .
ZONEEDIT DDDEF .
CHANGE VOL('*','').
CHANGE UNIT('*','').
ENDZONEEDIT .
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gadi Ben-Avi
Sent: Thursday, May 30, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: delete volume and unit information form DDDEF
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
Hi,
I have DDDEFs that have volume and unit information coded.
How do I delete that information in batch?
I am using z/OS v2.3
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
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: delete volume and unit information form DDDEF
Something like this. Now, that being said, I personally, don't catalog the
SMPE target and DLIB datasets, and specifically use UNIT/VOL to point to them
so that there is NO Chance of accidentally updating the wrong set of datasets
(i.e. the running version).
SET BDY(yourzone) .
ZONEEDIT DDDEF .
CHANGE VOL('*','').
CHANGE UNIT('*','').
ENDZONEEDIT .
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Gadi Ben-Avi
Sent: Thursday, May 30, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: delete volume and unit information form DDDEF
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
Hi,
I have DDDEFs that have volume and unit information coded.
How do I delete that information in batch?
I am using z/OS v2.3
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: delete volume and unit information form DDDEF
Thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Thursday, May 30, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF SET BDY(zonename) . ZEDIT DDDEF . CHANGE UNIT(*,*) . CHANGE VOLUME(*,*) . ENDZEDIT . UCLIN . Carmen Vitullo - Original Message - From: "Gadi Ben-Avi" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2019 9:37:30 AM Subject: Re: delete volume and unit information form DDDEF I looked at that, but didn't find a way to delete the information -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, May 30, 2019 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF Read up on the SMPE ZONEEDIT command. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gadi Ben-Avi Sent: Thursday, May 30, 2019 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: delete volume and unit information form DDDEF Hi, I have DDDEFs that have volume and unit information coded. How do I delete that information in batch? I am using z/OS v2.3 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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: delete volume and unit information form DDDEF
SET BDY(zonename) . ZEDIT DDDEF . CHANGE UNIT(*,*) . CHANGE VOLUME(*,*) . ENDZEDIT . UCLIN . Carmen Vitullo - Original Message - From: "Gadi Ben-Avi" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2019 9:37:30 AM Subject: Re: delete volume and unit information form DDDEF I looked at that, but didn't find a way to delete the information -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, May 30, 2019 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF Read up on the SMPE ZONEEDIT command. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gadi Ben-Avi Sent: Thursday, May 30, 2019 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: delete volume and unit information form DDDEF Hi, I have DDDEFs that have volume and unit information coded. How do I delete that information in batch? I am using z/OS v2.3 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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: delete volume and unit information form DDDEF
I looked at that, but didn't find a way to delete the information -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, May 30, 2019 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: delete volume and unit information form DDDEF Read up on the SMPE ZONEEDIT command. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gadi Ben-Avi Sent: Thursday, May 30, 2019 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: delete volume and unit information form DDDEF Hi, I have DDDEFs that have volume and unit information coded. How do I delete that information in batch? I am using z/OS v2.3 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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: delete volume and unit information form DDDEF
Read up on the SMPE ZONEEDIT command. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gadi Ben-Avi Sent: Thursday, May 30, 2019 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: delete volume and unit information form DDDEF Hi, I have DDDEFs that have volume and unit information coded. How do I delete that information in batch? I am using z/OS v2.3 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
delete volume and unit information form DDDEF
Hi, I have DDDEFs that have volume and unit information coded. How do I delete that information in batch? I am using z/OS v2.3 Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF & REXX & ULOG problem
Try using PGM=SDSF or Address SDSF "ISFSLASH ("command.") (WAIT)"
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Sean Gleann
Sent: Thursday, May 30, 2019 4:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF & REXX & ULOG problem
I've been struggling with this one for a couple of days now, without making
any headway.
I have a REXX that works through SDSF that is intended to issue 'D R,L'
and retrieve any outstanding console messages. It works fine when I invoke
it from ISPF option 6 with an EXEC... command, but when I invoke it via a
batch job or a started task it doesn't return the expected results.
After a considerable amount of manual bashing and web browsing, I've found
a couple of threads describing a similar problem on various web fora, the
most notable one having been raised back in 2011, and responded to by a
number of the regular contributors here on IBM-MAIN.
Unfortunately, I can't make the suggested modifications do anything for me,
and I'm hoping that someone here might be able to point me in a different
direction.
My REXX is:
/* REXX */
rc=isfcalls('ON')
rc=syscalls('ON')
isfcons="NODDY"
Address SDSF ISFEXEC "'/D R,L' (wait"
say "isfulog.0: "isfulog.0
if isfulog.0>0 then do
do i=1 to isfulog.0
say i isfulog.i
end
end
rc=isfcalls('OFF')
rc=syscalls('OFF')
When I run this via EXEC... in option 6, the result is:
isfulog.0: 6
1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY ACTIVATED
2 S0W1 2019150 03:02:03.62-D R,L
3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
REQUESTS 774
4RM=1IM=0 CEM=0
EM=0 RU=0IR=0NOAMRF
5ID:R/K T SYSNAME MESSAGE
TEXT
638 R S0W1 *38
DFS996I *IMS READY* IVP1
… which is exactly as expected.
If I use a console START command to invoke the REXX via some started task
JCL...
//RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
//SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
...the SYSTSPRT output on the hold queue is;
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
isfulog.0: 0
READY
END
As can be seen, the isfulog stem has simply gone west.
The same occurs if I modify the JCL to turn it into a batch job and invoke
the REXX that way instead.
I've tried a large number of variants of the REXX logic to trace it's
progress, and in the hope of forcing something different to happen, all to
no avail.
Any ideas, anyone... please?
Regards
Sean
--
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: Need a second set of eyes to look at my NPF settings
Dana, Below is what PRT7 looks like after I start it. $Dprt7 $HASP603 PRT7 UNIT=,STATUS=INACTIVE,BURST=NO,CKPTLINE=0, CKPTMODE=PAGE,CKPTPAGE=100,CKPTSEC=0,CREATOR=, DEVFCB=,DEVFLASH=,FCB=8X8,FORMS=(WL1,, ,),FSS=FSS1,HONORTRC=YES,JOBNAME=,LASTFORM= WL1,LIMIT=(0,*),COPYMARK=DATASET,MARK=YES, MODE=FSS,NEWPAGE=DEFAULT,NPRO=0,PAUSE=NO, PLIM=(0,*),PRESELCT=YES,PRMODE=(LINE,PAGE), QUEUE=R,RANGE=(J1,99),ROUTECDE=(LOCAL), SEP=YES,SEPCHARS=DEFAULT,SEPDS=NO, SETUP=NOHALT,SPACE=,TRACE=NO,TRANS=DEFAULT, TRKCELL=YES,UCS=0,UCSVERFY=NO,VOLUME=(,,,), WRITER=,WS=(Q,R/),FSAROLTR=YES Maybe you have a 'better way' to use NPF. Could you give me an example of what you are doing? Tony Thigpen Dana Mitchell wrote on 5/30/19 9:46 AM: On Thu, 30 May 2019 06:23:32 -0400, Tony Thigpen wrote: I installed NPF and had it working for my testing. That was about 4 months ago. Now, I it's time to set up the real printers so we can start using it in production. Tony, you and I may be some of the very few members of this list that are actually running NPF... What does the printer definition look like when you display it? $D PRT7. Specifically the ROUTECDE parameter. I'm guessing that printer isn't selecting work since you have WS=(Q,R/). Mine is set to ROUTECDE=(*PRT) to select all routes that end in the characters PRT. Dana -- 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: Need a second set of eyes to look at my NPF settings
On Thu, 30 May 2019 06:23:32 -0400, Tony Thigpen wrote: >I installed NPF and had it working for my testing. That was about 4 >months ago. Now, I it's time to set up the real printers so we can start >using it in production. Tony, you and I may be some of the very few members of this list that are actually running NPF... What does the printer definition look like when you display it? $D PRT7. Specifically the ROUTECDE parameter. I'm guessing that printer isn't selecting work since you have WS=(Q,R/). Mine is set to ROUTECDE=(*PRT) to select all routes that end in the characters PRT. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
Nobody said it was immune and you sell z security which is quite a conflict of interest. Sent from Yahoo Mail for iPhone On Thursday, May 30, 2019, 9:17 AM, Ray Overby wrote: In response to "Ideed, IF you know such trap door, you know z/OS vulnerability, which proves the platform is not immune. Is it as vulnerable as Windows? No, because it's still not binary, some systems are still more secure than others." In my opinion (I am biased) z/OS is the most secure-able platform that I know of. Secure-able (is that a word?) does not mean that the platform does not have vulnerabilities (configuration and code based). There are many people that think just like Bill Johnson. Most of them that I have met and talked with when presented with forensic evidence that shows their systems have trap doors they have accepted it (They had to report the problem to vendor and then apply fix - Trust but verify ;-)). Due to the way this industry treats integrity problems that cannot currently be done publicly. In response to "Last, but not least: assuming you know such trap door. Or even several trap doors. What next?" a) I don't submit any trap doors vulnerabilities to any vendors due to the contractual nature around how and when these vulnerabilities are found. I am restricted to what I can disclose to whom. The companies that license the software report the issue. b) Vendors provide a fix for trap doors in their products. I do not fix the Vendors code. I have not been asked to fix any installation written code for vulnerabilities but would if asked to. c) If Vendor does not fix the trap door then company can now make an informed decision about whether to a) assume the risk and keep the product or b) remove the product from the system. Having the vulnerability classification and knowing the capability of a trap door should allow the company to have meaningful internal discussions about the issue and decide what is best for the company. These internal discussion can now include management, Security, Risk, Pen testers and C level people all because of the vulnerability classification (TRAP DOOR) will allow more people to understand the issue. I would argue that allowing a company to understand the vulnerability risk and make an informed decision in the company's best interest would be very valuable to any company in that situation. On 5/30/2019 6:01 AM, R.S. wrote: > As Shmuel said an application with a trap door is an application > vulnerability. > Ideed, IF you know such trap door, you know z/OS vulnerability, which > proves the platform is not immune. Is it as vulnerable as Windows? No, > because it's still not binary, some systems are still more secure than > others. > > Last, but not least: assuming you know such trap door. Or even > several trap doors. What next? > a) you submitted it to IBM and they are trying to fix it. > b) despite of a) you know how to fix it by homegrown > code/configuration/procedure and you offer it as a service. > c) the trap door cannot be fixed and then your services are disputable > - you cannot help. > > Of course the above *regards only the trap doors you know*, not your > services portfolio. > Besides that you can provide many valuable services regarding > security, but not platform issues, rather people mistakes, > misconfigurations, erroneous procedures, etc. > It is worth to emphasize: while z/OS is quite secure, it may be quite > complex to configure it properly. And here there is a field for Ray, > ITschak, RSM Partners, me, etc. > -- 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: Fwd: Just how secure are mainframes? | Trevor Eddolls
In response to "Ideed, IF you know such trap door, you know z/OS vulnerability, which proves the platform is not immune. Is it as vulnerable as Windows? No, because it's still not binary, some systems are still more secure than others." In my opinion (I am biased) z/OS is the most secure-able platform that I know of. Secure-able (is that a word?) does not mean that the platform does not have vulnerabilities (configuration and code based). There are many people that think just like Bill Johnson. Most of them that I have met and talked with when presented with forensic evidence that shows their systems have trap doors they have accepted it (They had to report the problem to vendor and then apply fix - Trust but verify ;-)). Due to the way this industry treats integrity problems that cannot currently be done publicly. In response to "Last, but not least: assuming you know such trap door. Or even several trap doors. What next?" a) I don't submit any trap doors vulnerabilities to any vendors due to the contractual nature around how and when these vulnerabilities are found. I am restricted to what I can disclose to whom. The companies that license the software report the issue. b) Vendors provide a fix for trap doors in their products. I do not fix the Vendors code. I have not been asked to fix any installation written code for vulnerabilities but would if asked to. c) If Vendor does not fix the trap door then company can now make an informed decision about whether to a) assume the risk and keep the product or b) remove the product from the system. Having the vulnerability classification and knowing the capability of a trap door should allow the company to have meaningful internal discussions about the issue and decide what is best for the company. These internal discussion can now include management, Security, Risk, Pen testers and C level people all because of the vulnerability classification (TRAP DOOR) will allow more people to understand the issue. I would argue that allowing a company to understand the vulnerability risk and make an informed decision in the company's best interest would be very valuable to any company in that situation. On 5/30/2019 6:01 AM, R.S. wrote: As Shmuel said an application with a trap door is an application vulnerability. Ideed, IF you know such trap door, you know z/OS vulnerability, which proves the platform is not immune. Is it as vulnerable as Windows? No, because it's still not binary, some systems are still more secure than others. Last, but not least: assuming you know such trap door. Or even several trap doors. What next? a) you submitted it to IBM and they are trying to fix it. b) despite of a) you know how to fix it by homegrown code/configuration/procedure and you offer it as a service. c) the trap door cannot be fixed and then your services are disputable - you cannot help. Of course the above *regards only the trap doors you know*, not your services portfolio. Besides that you can provide many valuable services regarding security, but not platform issues, rather people mistakes, misconfigurations, erroneous procedures, etc. It is worth to emphasize: while z/OS is quite secure, it may be quite complex to configure it properly. And here there is a field for Ray, ITschak, RSM Partners, me, etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF & REXX & ULOG problem
For what it's worth, an earlier modification of the REXX featured the use
of the WHO command to retrieve that sort of information.
The user is STCOPER, which doesn't have a TSO segment, it's true, even
though - per Itschak - one isn't necessary.
As part of pursuing this problem, I PERMITted both CONSOLE and SPECIAL
attributes for this user, as well as READ access to all resources inn the
SDSF class.
(have since backed those changes out, because they didn't move things
forward at all).
Regards
John
On Thu, 30 May 2019 at 13:48, ITschak Mugzach wrote:
> Msg IKJ56644I is always issued. Tso batch does not requires tao segment.
> However, as John noticed this is not the same user. Has a look at the first
> message of the stc job log to see which user associated with your task and
> make sure it has permission to command ulog in sdsf resource class.
>
> ITschak
>
> בתאריך יום ה׳, 30 במאי 2019, 15:33, מאת John McKown <
> john.archie.mck...@gmail.com>:
>
> > This is probably your problem:
> >
> > KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> >
> > What RACF ID is the job running under? It must have a TSO segment and be
> > authorized to use SDSF.
> >
> > On Thu, May 30, 2019 at 3:14 AM Sean Gleann
> wrote:
> >
> > > I've been struggling with this one for a couple of days now, without
> > making
> > > any headway.
> > >
> > > I have a REXX that works through SDSF that is intended to issue 'D R,L'
> > > and retrieve any outstanding console messages. It works fine when I
> > invoke
> > > it from ISPF option 6 with an EXEC... command, but when I invoke it
> via a
> > > batch job or a started task it doesn't return the expected results.
> > >
> > > After a considerable amount of manual bashing and web browsing, I've
> > found
> > > a couple of threads describing a similar problem on various web fora,
> the
> > > most notable one having been raised back in 2011, and responded to by a
> > > number of the regular contributors here on IBM-MAIN.
> > >
> > > Unfortunately, I can't make the suggested modifications do anything for
> > me,
> > > and I'm hoping that someone here might be able to point me in a
> different
> > > direction.
> > >
> > > My REXX is:
> > > /* REXX */
> > > rc=isfcalls('ON')
> > > rc=syscalls('ON')
> > > isfcons="NODDY"
> > > Address SDSF ISFEXEC "'/D R,L' (wait"
> > > say "isfulog.0: "isfulog.0
> > > if isfulog.0>0 then do
> > > do i=1 to isfulog.0
> > > say i isfulog.i
> > > end
> > > end
> > > rc=isfcalls('OFF')
> > > rc=syscalls('OFF')
> > >
> > > When I run this via EXEC... in option 6, the result is:
> > > isfulog.0: 6
> > > 1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY
> > > ACTIVATED
> > > 2 S0W1 2019150 03:02:03.62-D R,L
> > > 3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
> > > REQUESTS 774
> > > 4RM=1IM=0 CEM=0
> > > EM=0 RU=0IR=0NOAMRF
> > > 5ID:R/K T SYSNAME
> > MESSAGE
> > > TEXT
> > > 638 R S0W1 *38
> > > DFS996I *IMS READY* IVP1
> > > … which is exactly as expected.
> > >
> > > If I use a console START command to invoke the REXX via some started
> task
> > > JCL...
> > > //RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
> > > //SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
> > > //SYSTSPRT DD SYSOUT=*
> > > //SYSTSIN DD DUMMY
> > >
> > > ...the SYSTSPRT output on the hold queue is;
> > > IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> > > isfulog.0: 0
> > > READY
> > > END
> > >
> > > As can be seen, the isfulog stem has simply gone west.
> > > The same occurs if I modify the JCL to turn it into a batch job and
> > invoke
> > > the REXX that way instead.
> > > I've tried a large number of variants of the REXX logic to trace it's
> > > progress, and in the hope of forcing something different to happen, all
> > to
> > > no avail.
> > >
> > > Any ideas, anyone... please?
> > >
> > > Regards
> > > Sean
> > >
> > > --
> > > 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
> >
>
> --
> 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 acce
Re: master JCL
Thanks David et al, I knew system told me somewhere but for the life of me, I couldn't find it. The confusion on my part came from the fact that I have the IEASYS00 line to use MSTJCL00. However, member MSTJCL00 doesn't exist in SYS1.PARMLIB but it is in a concatenated PARMLIB library. Being the master scheduler starts so early, I didn't know if the system was up far enough to use concatenated PARMLIBs or if it was just using SYS1.PARMLIB. Hence I didn't know which MSTJCL00 was being used. Digging back through the syslog tells me that the concatenated PARMLIB is in effect, as my IEFJ200I says it is coming from PARMLIB. Thanks again, all. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Wednesday, May 29, 2019 6:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: master JCL Hi Skip, This is a SYSLOG excerpt. IEE252I MEMBER MSTJCL00 FOUND IN ADCD.Z23A.PARMLIB . . . IEFJ200I MASTER SCHEDULER JCL FOR THIS IPL TAKEN FROM MEMBER MSTJCL00 OF PARMLIB IEF196I 1 //MSTJCL00 JOB MSGLEVEL=(1,1),TIME=1440 IEF196I 2 // EXEC PGM=IEEMB860,DPRTY=(15,15) IEF196I 3 //STCINRDR DD SYSOUT=(A,INTRDR) IEF196I 4 //TSOINRDR DD SYSOUT=(A,INTRDR) IEF196I 5 //IEFPDSI DD DSN=USER.&SYSVER..PROCLIB,DISP=SHR IEF196I IEFC653I SUBSTITUTION JCL - DSN=USER.Z23A.PROCLIB, IEF196I DISP=SHR IEF196I 6 // DD DSN=FEU.&SYSVER..PROCLIB,DISP=SHR IEF196I IEFC653I SUBSTITUTION JCL - DSN=FEU.Z23A.PROCLIB, IEF196I DISP=SHR IEF196I 7 // DD DSN=ADCD.&SYSVER..PROCLIB,DISP=SHR IEF196I IEFC653I SUBSTITUTION JCL - DSN=ADCD.Z23A.PROCLIB, IEF196I DISP=SHR IEF196I 8 // DD DSN=SYS1.PROCLIB,DISP=SHR IEF196I 9 //SYSUADS DD DSN=SYS1.UADS,DISP=SHR IEF196I 10 //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR IEF196I 11 //IEFPARM DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3CFG1, IEF196I // DSN=USER.Z23A.PARMLIB IEF196I 12 // DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3CFG1, IEF196I // DSN=FEU.Z23A.PARMLIB IEF196I 13 // DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=A3SYS1, IEF196I // DSN=ADCD.Z23A.PARMLIB IEF196I 14 // DD DISP=SHR, IEF196I // DSN=SYS1.PARMLIB IEF196I //* LOADxx parmlibs put in MSTRJCL concatenation IEF403I MSTJCL00 - STARTED - TIME=12.38.58 Regards, David On 2019-05-29 18:52, Jesse 1 Robinson wrote: > For a reeealy lonng time MVS has supported member MSTJCLxx in > PARMLIB for master JCL. As for finding the content of MSTJCLxx at NIP for the > current IPL, I'm at a loss. Does not seem to be captured in operlog. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Pommier, Rex > Sent: Wednesday, May 29, 2019 3:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):master JCL > > Hello listers, > > I'm apparently having a case of brain-drain. Is there an easy way to display > the currently used master JCL? I know I can look at LINKLIB and PARMLIB and > see what's there, but is there a way of displaying what's actually running? > I thought at one point in time I could see it in Omegamon or someplace. In > this case, google was not my friend. :-( Any assistance would be greatly > appreciated. > > TIA, > > Rex > > > -- > 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF & REXX & ULOG problem
On Thu, May 30, 2019 at 7:48 AM ITschak Mugzach wrote: > Msg IKJ56644I is always issued. Tso batch does not requires tao segment. > However, as John noticed this is not the same user. Has a look at the first > message of the stc job log to see which user associated with your task and > make sure it has permission to command ulog in sdsf resource class. > Hum, must be some difference between our systems. I submitted a TSO batch job from ISPF and did not see that message anywhere in my output. > ITschak > > -- 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: SDSF & REXX & ULOG problem
Msg IKJ56644I is always issued. Tso batch does not requires tao segment.
However, as John noticed this is not the same user. Has a look at the first
message of the stc job log to see which user associated with your task and
make sure it has permission to command ulog in sdsf resource class.
ITschak
בתאריך יום ה׳, 30 במאי 2019, 15:33, מאת John McKown <
john.archie.mck...@gmail.com>:
> This is probably your problem:
>
> KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
>
> What RACF ID is the job running under? It must have a TSO segment and be
> authorized to use SDSF.
>
> On Thu, May 30, 2019 at 3:14 AM Sean Gleann wrote:
>
> > I've been struggling with this one for a couple of days now, without
> making
> > any headway.
> >
> > I have a REXX that works through SDSF that is intended to issue 'D R,L'
> > and retrieve any outstanding console messages. It works fine when I
> invoke
> > it from ISPF option 6 with an EXEC... command, but when I invoke it via a
> > batch job or a started task it doesn't return the expected results.
> >
> > After a considerable amount of manual bashing and web browsing, I've
> found
> > a couple of threads describing a similar problem on various web fora, the
> > most notable one having been raised back in 2011, and responded to by a
> > number of the regular contributors here on IBM-MAIN.
> >
> > Unfortunately, I can't make the suggested modifications do anything for
> me,
> > and I'm hoping that someone here might be able to point me in a different
> > direction.
> >
> > My REXX is:
> > /* REXX */
> > rc=isfcalls('ON')
> > rc=syscalls('ON')
> > isfcons="NODDY"
> > Address SDSF ISFEXEC "'/D R,L' (wait"
> > say "isfulog.0: "isfulog.0
> > if isfulog.0>0 then do
> > do i=1 to isfulog.0
> > say i isfulog.i
> > end
> > end
> > rc=isfcalls('OFF')
> > rc=syscalls('OFF')
> >
> > When I run this via EXEC... in option 6, the result is:
> > isfulog.0: 6
> > 1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY
> > ACTIVATED
> > 2 S0W1 2019150 03:02:03.62-D R,L
> > 3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
> > REQUESTS 774
> > 4RM=1IM=0 CEM=0
> > EM=0 RU=0IR=0NOAMRF
> > 5ID:R/K T SYSNAME
> MESSAGE
> > TEXT
> > 638 R S0W1 *38
> > DFS996I *IMS READY* IVP1
> > … which is exactly as expected.
> >
> > If I use a console START command to invoke the REXX via some started task
> > JCL...
> > //RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
> > //SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN DD DUMMY
> >
> > ...the SYSTSPRT output on the hold queue is;
> > IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> > isfulog.0: 0
> > READY
> > END
> >
> > As can be seen, the isfulog stem has simply gone west.
> > The same occurs if I modify the JCL to turn it into a batch job and
> invoke
> > the REXX that way instead.
> > I've tried a large number of variants of the REXX logic to trace it's
> > progress, and in the hope of forcing something different to happen, all
> to
> > no avail.
> >
> > Any ideas, anyone... please?
> >
> > Regards
> > Sean
> >
> > --
> > 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
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
On Wed, May 29, 2019 at 1:23 PM Schuffenhauer, Mark wrote: > My sales favorite was knowing key functionality is vaporware, talking up > everything the software would do some day. Then being horrified when you > realize the 'decision makers' are eating it up. None of them ends up in > hell when the product doesn't work and the functionality delivery date > keeps getting pushed forward... but, I got to work with a 3745 until 2009. > I dislike some sales people's tactics. We bought a z890 and got an IFL. Two statements: (1) Linux runs on an IFL. (2) Linux can run Windows applications using WINE. The missing portion of statement #2 ", on an Intel processor." Management didn't ask any technical people, they just got the z890 + IFL. Then things got bad. > > Security is no good without PEN testing and auditing from the Security > Technical Implementation Guide (STIG) documents. If you haven't crossed > your eyes and dotted your teas wait, reverse that. Your odds of solid > security can be greatly decreased. > > No security by obscurity. > EBCDIC is not a method of encryption. > Stop people from using stupid passwords. Ideally daily ID's have no > elevated access, any elevated id must be checked out, activated, with a new > password on each use. I realize that would be messy, but if you have > better password security(pass phrases, excluded words (months of the year, > or seasons) or MFA going, never mind. This isn't the paragraph you're > looking for... > Although I agree with that paragraph, I have never been in a shop which does it. The closest was when I worked for "The Equitable". I did not have update access to datasets on the production system volumes. If I needed to update something, such as PARMLIB, or a PROCLIB, or do SMP/E work, I had to get with my manager; he would put in a request to the security admin; she would grant me update authority for a short time & audit me; When I was finished, she would revoke my access and print an audit report of my activity while I had escalated access. -- 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: SDSF & REXX & ULOG problem
This is probably your problem:
KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
What RACF ID is the job running under? It must have a TSO segment and be
authorized to use SDSF.
On Thu, May 30, 2019 at 3:14 AM Sean Gleann wrote:
> I've been struggling with this one for a couple of days now, without making
> any headway.
>
> I have a REXX that works through SDSF that is intended to issue 'D R,L'
> and retrieve any outstanding console messages. It works fine when I invoke
> it from ISPF option 6 with an EXEC... command, but when I invoke it via a
> batch job or a started task it doesn't return the expected results.
>
> After a considerable amount of manual bashing and web browsing, I've found
> a couple of threads describing a similar problem on various web fora, the
> most notable one having been raised back in 2011, and responded to by a
> number of the regular contributors here on IBM-MAIN.
>
> Unfortunately, I can't make the suggested modifications do anything for me,
> and I'm hoping that someone here might be able to point me in a different
> direction.
>
> My REXX is:
> /* REXX */
> rc=isfcalls('ON')
> rc=syscalls('ON')
> isfcons="NODDY"
> Address SDSF ISFEXEC "'/D R,L' (wait"
> say "isfulog.0: "isfulog.0
> if isfulog.0>0 then do
> do i=1 to isfulog.0
> say i isfulog.i
> end
> end
> rc=isfcalls('OFF')
> rc=syscalls('OFF')
>
> When I run this via EXEC... in option 6, the result is:
> isfulog.0: 6
> 1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY
> ACTIVATED
> 2 S0W1 2019150 03:02:03.62-D R,L
> 3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
> REQUESTS 774
> 4RM=1IM=0 CEM=0
> EM=0 RU=0IR=0NOAMRF
> 5ID:R/K T SYSNAME MESSAGE
> TEXT
> 638 R S0W1 *38
> DFS996I *IMS READY* IVP1
> … which is exactly as expected.
>
> If I use a console START command to invoke the REXX via some started task
> JCL...
> //RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
> //SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
> //SYSTSPRT DD SYSOUT=*
> //SYSTSIN DD DUMMY
>
> ...the SYSTSPRT output on the hold queue is;
> IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> isfulog.0: 0
> READY
> END
>
> As can be seen, the isfulog stem has simply gone west.
> The same occurs if I modify the JCL to turn it into a batch job and invoke
> the REXX that way instead.
> I've tried a large number of variants of the REXX logic to trace it's
> progress, and in the hope of forcing something different to happen, all to
> no avail.
>
> Any ideas, anyone... please?
>
> Regards
> Sean
>
> --
> 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: master JCL
On Wed, May 29, 2019 at 5:10 PM Pommier, Rex wrote: > Hello listers, > > I'm apparently having a case of brain-drain. Is there an easy way to > display the currently used master JCL? I know I can look at LINKLIB and > PARMLIB and see what's there, but is there a way of displaying what's > actually running? I thought at one point in time I could see it in > Omegamon or someplace. In this case, google was not my friend. :-( Any > assistance would be greatly appreciated. > I don't have any of that fancy Omegamon type stuff. So I start here: IEE254I 06.47.04 IPLINFO DISPLAY 503 SYSTEM IPLED AT 15.57.51 ON 03/10/2019 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD11 IN SYS1.IPLPARM ON 02BB0 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 11 IEASYS LIST = (11) (OP) IODF DEVICE: ORIGINAL(02BB0) CURRENT(02BB0) IPL DEVICE: ORIGINAL(02BB1) CURRENT(02BB1) VOLUME(I17RS1) I can then look at the LOAD11 member in SYS1.IPLPARM on I17CAT (D U,,,2BB0,1 to get the volser, or just assume it is catalogued). I found this: PARMLIB SYS1.LIH1.PARMLIBI17CAT PARMLIB SYS1.PARMLIB I17CAT PARMLIB CPAC.PARMLIB I17CAT PARMLIB SYS1.IBM.PARMLIB I17RS1 PARMLIB SYS1.LIH1.UNICODELIHTS1 Now, I have a nice little TSO ISPF command called SYSPARM which will bring up a ISPF 3.4 type display of the current PARMLIB concatenation. You can get this on http://cbttape.org in file #968. I look and see that my IEASYS member is 11, which is concatenated before IEASYS00. So I look in those members, in the aforementioned PARMLIB concatention, I saw MSTRJCL=00 in IEASYS00. You will need to look at each of the IEASYSnn members, in order to see where, and if, MSTRJCL=nn is first specified. Using the same ISPF 3.4 display of the PARMLIBs, I then look at MSTJCL00. Of course, if someone has modified this member since IPL, it will be inaccurate. I don't know if the actual JCL used internally to start the *MASTER* address space is kept anywhere. Having gone all over this mess, I remembered that we do have BMC Mainview/MVS (very old). It has RESOLVE. So I did this: F RES,TIO,*MASTER*,MAP AMT00DI Enter SYSPROG command (LIH1) AMTE11I STC41311 MSTJCL00 OPSUSS Prty 255 Page I/Os 9,968 AMTE12I DD STCINRDR AMTE13I DSN .MSTR.MS.STCINRDR AMTE12I DD TSOINRDR AMTE13I DSN .MSTR.MS.TSOINRDR AMTE12I DD IEFPDSI Unit 2BB0 Volume I17CAT AMTE13I DSN SYS1.LIH1.PROCLIB AMTE12I Unit 2BB0 Volume I17CAT AMTE13I DSN SYS1.PROCLIB AMTE12I Unit 2BB0 Volume I17CAT AMTE13I DSN CPAC.PROCLIB AMTE12I Unit 2BB1 Volume I17RS1 AMTE13I DSN SYS1.IBM.PROCLIB AMTE12I DD SYSUADS Unit 2BB2 Volume I17RS2 AMTE13I DSN SYS1.UADS AMTE12I DD IEFJOBS Unit 2BB0 Volume I17CAT AMTE13I DSN SYS1.LIH1.STCJOBS AMTE12I DD IEFPARM Unit 2BB0 Volume I17CAT AMTE13I DSN SYS1.LIH1.PARMLIB AMTE12I Unit 2BB0 Volume I17CAT AMTE13I DSN SYS1.PARMLIB AMTE12I Unit 2BB0 Volume I17CAT AMTE13I DSN CPAC.PARMLIB AMTE12I Unit 2BB1 Volume I17RS1 AMTE13I DSN SYS1.IBM.PARMLIB AMTE12I Unit 2401 Volume LIHTS1 AMTE13I DSN SYS1.LIH1.UNICODE AMTE12I DD SYSLBCUnit 2401 Volume LIHTS1 Excp 27,395 AMTE13I DSN SYS1.PLEXLIH1.BRODCAST AMTE12I DD SYS1 Unit 2203 Volume LIHTS7 AMTE13I DSN SYS1.RACF AMTE12I DD SYS2 Unit 2501 Volume LIHTSA AMTE13I DSN SYS1.RACF.MIRROR AMTE12I DD SYS3 Unit 2BB1 Volume I17RS1 Excp 102 AMTE13I DSN SYS1.SCUNTBL AMTE12I DD SYSLOG81 JES2 AMTE13I DSN +MASTER+.SYSLOG.STC41311.D182.? > > TIA, > > Rex > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > -- > 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
Re: master JCL
Found it here: http://www.oocities.org/siliconvalley/peaks/4170/articles/selfdoc.html On Wed, May 29, 2019 at 11:39 PM Bruce Hewson wrote: > Skip, > > A long time ago I read :- > > Building a Self-Documenting MVS/ESA System > by Mark S. Hahn > Reprinted with permission. ©1992 Candle Corp. > > Can't see to find it via Google now, but Dave Alcock has refenrce to it:- > > http://planetmvs.com/mvstips/#SELFDOC > > > > On Wed, 29 May 2019 23:36:59 +, Jesse 1 Robinson < > jesse1.robin...@sce.com> wrote: > > >Well, I'll be hornswoggled. With a little digging I found in > > > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/ieae200314.htm > > > >that the parm in IEASYSxx is MSTRJCL=(xx[,L]) along with the advice to > 'use...L only for debugging purposes'. We don't seem to have 'L' on any > system. > > > >. > >. > >J.O.Skip Robinson > >Southern California Edison Company > >Electric Dragon Team Paddler > >SHARE MVS Program Co-Manager > >323-715-0595 Mobile > >626-543-6132 Office ⇐=== NEW > >robin...@sce.com > > I have coded my systems this way since then. > > Regards > Bruce Hewson > > -- > 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: Fwd: Just how secure are mainframes? | Trevor Eddolls
In response to "An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability." Does it really matter if an application vs z/OS has a trap door vulnerability? In either case z/OS and the ESM's cannot function properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS be able to protect itself from accidental and/or malicious vulnerabilities? Isn't that what a platform is supposed to do? Isn't that a requirement of a secure system? Every program in z/OS has certain rules of the road it must abide by. System level programs (PSW Key 0-7, Supervisor State, APF authorized) regardless of whether they are in z/OS or an application have additional rules they must adhere to (i.e. - they must not violate the integrity of z/OS). These rules of the road are the responsibility of and dictated by the platform. Integrity is a platform issue. One of the reason's the mainframe is the most secure-able platform is at least partially based on integrity. Integrity as implemented by the platform is why security is possible. Without platform integrity security is not possible. So all code (z/OS and application) that operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF authorized) must not violate the integrity rules. Failure of a single program regardless of whether it is part of z/OS or an application will allow a hacker to compromise that system and all data on it. In response to "I'd be willing to bet a substantial amount that the majority of penetrations in z/OS are application, configuration, personnel and process vulnerabilities rather than z/OS vulnerabilities." In terms of numbers of vulnerabilities there are fewer code based vulnerabilities (TRAP DOOR is one example of a code based vulnerabilities - there are others) vs configuration based vulnerabilities. I would point out that a hacker only needs a single TRAP DOOR vulnerability to compromise the platform regardless of how the platform is configured. So fewer code based vulnerabilities does not help. All code based vulnerabilities have to be removed from the system in order to secure the platform. On 5/29/2019 2:57 PM, Seymour J Metz wrote: A single TRAP DOOR code vulnerability pierces the veil of integrity and can be used to compromise the mainframe. Is this a platform weakness? An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability. I'd be willing to bet a substantial amount that the majority of penetrations in z/OS are application, configuration, personnel and process vulnerabilities rather than z/OS vulnerabilities. Would you say that the elimination of User Key Common storage is an example of a z/OS change to address a mainframe platform weakness Partially. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ray Overby Sent: Wednesday, May 29, 2019 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR code vulnerability pierces the veil of integrity and can be used to compromise the mainframe. Is this a platform weakness? I think so. The platform relies on all code it runs adhering to certain rules. z/OS could be changed to better check and enforce those rules. Would you say that the elimination of User Key Common storage is an example of a z/OS change to address a mainframe platform weakness? I think so. An interesting observation. Thanks. On 5/29/2019 5:25 AM, R.S. wrote: That's classical FUD. Frightening people. "if an exploit", "if job reads you RACF db", "unintended consequences". What exactly hacking scenario can provide RACF db to the hacker? Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user attribute, even UPDATE to RACF db. But it's problem of people. Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness. It's typical that assurance/lock/gun salesmen tend to talk about risks, threats and dangers. They create a vision. My English is poor, but I can observe it for two of debaters here. It's visible. I don't like social engineering. -- 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 -- Fo
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
As Shmuel said an application with a trap door is an application vulnerability. Ideed, IF you know such trap door, you know z/OS vulnerability, which proves the platform is not immune. Is it as vulnerable as Windows? No, because it's still not binary, some systems are still more secure than others. Last, but not least: assuming you know such trap door. Or even several trap doors. What next? a) you submitted it to IBM and they are trying to fix it. b) despite of a) you know how to fix it by homegrown code/configuration/procedure and you offer it as a service. c) the trap door cannot be fixed and then your services are disputable - you cannot help. Of course the above *regards only the trap doors you know*, not your services portfolio. Besides that you can provide many valuable services regarding security, but not platform issues, rather people mistakes, misconfigurations, erroneous procedures, etc. It is worth to emphasize: while z/OS is quite secure, it may be quite complex to configure it properly. And here there is a field for Ray, ITschak, RSM Partners, me, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-05-29 o 17:11, Ray Overby pisze: In response to "Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness." comment: The mainframe platform, z/OS, and ESM's all rely on integrity to function. A single TRAP DOOR code vulnerability pierces the veil of integrity and can be used to compromise the mainframe. Is this a platform weakness? I think so. The platform relies on all code it runs adhering to certain rules. z/OS could be changed to better check and enforce those rules. Would you say that the elimination of User Key Common storage is an example of a z/OS change to address a mainframe platform weakness? I think so. An interesting observation. Thanks. On 5/29/2019 5:25 AM, R.S. wrote: That's classical FUD. Frightening people. "if an exploit", "if job reads you RACF db", "unintended consequences". What exactly hacking scenario can provide RACF db to the hacker? Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user attribute, even UPDATE to RACF db. But it's problem of people. Mistakes, lack of time, lack of control, lack of skills. Not a platform weakness. It's typical that assurance/lock/gun salesmen tend to talk about risks, threats and dangers. They create a vision. My English is poor, but I can observe it for two of debaters here. It's visible. I don't like social engineering. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Need a second set of eyes to look at my NPF settings
I installed NPF and had it working for my testing. That was about 4 months ago. Now, I it's time to set up the real printers so we can start using it in production. But, now my original test no longer works. NPF will no longer pull the print from the JES queue and place it in the routing queue. Turns out that our contract sysprog decided to 'get it working' after I already had it working, and messed something up. And, of course, he did not save any of the working setup and can't tell me what he did. I have been though the JES2 setup and the NPF setups and can't find the problem. I think I just need a second set of eyes. JCL: //CMPRT01 DD SYSOUT=(R,,TONY), // DCB=(RECFM=FM),DEST=PZGWHFL1 Routing Entries: EZAPPFL TYPE=ROUTING, MAJKEY=PZGWHFL1, MINKEY=RTONY, RETAINS=5, RETAINU=10, RETRYT=5, RETRYL=2, NDEST=1, OPTNAME=NONE, INAME=10.10.50.06, PNAME=PZGWHCR1 EZAPPFL TYPE=OPTIONS, OPTNAME=NONE, OPTIONS=TRACE - JES2 config: FSS(FSS1) PROC=NPF, HASPFSSM=HASPFSSM,AUTOSTOP=YES OUTCLASS(R) BLNKTRNC=YES, OUTDISP=(KEEP,KEEP), OUTPUT=PRINT, TRKCELL=NO PRT(7) CLASS=R, FSS=FSS1, DRAIN,MODE=FSS, PRMODE=(LINE,PAGE), UCS=0, SE=NO, SEP=YES, SEPDS=NO, CKPTPAGE=100, START=NO, SETUP=NOHALT, NPRO=0, MARK=YES, TRKCELL=YES, WS=(Q,R/) When I start the printer ($SPRT7), the NPF FSS auto-starts as expected. It just never pulls the print output from the JES2 queue. Thanks, Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF & REXX & ULOG problem
Please ignore my previous post. I've manged to create a solution via a different method. Using ADDRESS SDSF "ISFLOG READ TYPE(SYSLOG) (WTOR)" gives me what I need to progress this work. Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF & REXX & ULOG problem
I've been struggling with this one for a couple of days now, without making
any headway.
I have a REXX that works through SDSF that is intended to issue 'D R,L'
and retrieve any outstanding console messages. It works fine when I invoke
it from ISPF option 6 with an EXEC... command, but when I invoke it via a
batch job or a started task it doesn't return the expected results.
After a considerable amount of manual bashing and web browsing, I've found
a couple of threads describing a similar problem on various web fora, the
most notable one having been raised back in 2011, and responded to by a
number of the regular contributors here on IBM-MAIN.
Unfortunately, I can't make the suggested modifications do anything for me,
and I'm hoping that someone here might be able to point me in a different
direction.
My REXX is:
/* REXX */
rc=isfcalls('ON')
rc=syscalls('ON')
isfcons="NODDY"
Address SDSF ISFEXEC "'/D R,L' (wait"
say "isfulog.0: "isfulog.0
if isfulog.0>0 then do
do i=1 to isfulog.0
say i isfulog.i
end
end
rc=isfcalls('OFF')
rc=syscalls('OFF')
When I run this via EXEC... in option 6, the result is:
isfulog.0: 6
1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY ACTIVATED
2 S0W1 2019150 03:02:03.62-D R,L
3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
REQUESTS 774
4RM=1IM=0 CEM=0
EM=0 RU=0IR=0NOAMRF
5ID:R/K T SYSNAME MESSAGE
TEXT
638 R S0W1 *38
DFS996I *IMS READY* IVP1
… which is exactly as expected.
If I use a console START command to invoke the REXX via some started task
JCL...
//RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
//SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
...the SYSTSPRT output on the hold queue is;
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
isfulog.0: 0
READY
END
As can be seen, the isfulog stem has simply gone west.
The same occurs if I modify the JCL to turn it into a batch job and invoke
the REXX that way instead.
I've tried a large number of variants of the REXX logic to trace it's
progress, and in the hope of forcing something different to happen, all to
no avail.
Any ideas, anyone... please?
Regards
Sean
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
