Re: JES2 shutdown failure - OMVS will not shut down
you left ZFS running. It should come down before you issue the commands you listed. As in: F OMVS,STOPPFS=ZFS F BPXOINIT,SHUTDOWN=FORKINIT SETRRS SHUTDOWN F OMVS,SHUTDOWN /DU,STA /PJES2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure
At the end of the shutdown process, it's a good idea to issue these commands. The first one will ask you to verify that it's okay to stop ZFS., the rest won't ask you anything at all. F OMVS,STOPPFS=ZFS F BPXOINIT,SHUTDOWN=FORKINIT SETRRS SHUTDOWN F OMVS,SHUTDOWN $DU,STA $PJES2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE question
I think that one of the CBTtape files has a program that is a generic abend catcher and you execute it, passing it a parm of your program and it builds the ESTAEX cushion around your program. Alternatively, our SyzMPF/z product can intercept the cancel command and keep it from being done when you don't want it to be, so I'm sure that most if not all other automation products can do that same thing. You could also write a simple command exit which would intercept ALL cancel commands and do any kind of processing you want to it (including ignore it for certain jobs/tasks) and have that same exit allow some other command (like XANCLE instead of "CANCEL" or "C") to actually work for those jobs that are your favorites. Obviously our product makes this really easy, (it allows scripts with many, many variables to help decide if things should be allowed to happen or modify the commands and/or send email or text messages if/when commands are changed) and everyone should buy it from us, but it's really not that difficult to design and write your own for simple single use things like this. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure - OMVS will not shut down
Any system tasks using an OMVS file? On Tue, May 14, 2019 at 10:07 PM Tony Thigpen wrote: > > As everything indicates that OMVS was the problem, I brought the machine > back up and try shutting down OMVS outside of my system shutdown. This > is the results: > > 22.02.52 HUP1 F BPXOINIT,SHUTDOWN=FORKINIT > 22.02.52 HUP1 BPXM037I BPXAS INITIATOR SHUTDOWN DELAYED. > 22.02.52 HUP1 STC03368 IEF404I BPXAS - ENDED - TIME=22.02.52 > 22.02.52 HUP1 STC03334 IEF404I BPXAS - ENDED - TIME=22.02.52 > 22.02.52 HUP1 STC03368 $HASP395 BPXASENDED > 22.02.52 HUP1 STC03369 IEF404I BPXAS - ENDED - TIME=22.02.52 > 22.02.52 HUP1 STC03334 $HASP395 BPXASENDED > 22.02.52 HUP1 STC03370 IEF404I BPXAS - ENDED - TIME=22.02.52 > 22.02.52 HUP1 STC03369 $HASP395 BPXASENDED > 22.02.52 HUP1 STC03370 $HASP395 BPXASENDED > 22.03.16 HUP1 F OMVS,SHUTDOWN > 22.03.16 HUP1 IEE342I MODIFY REJECTED-TASK BUSY > > Thoughts? > > Tony Thigpen > > Tony Thigpen wrote on 5/14/19 5:55 PM: > > F BPXOINIT,SHUTDOWN=FORKINIT > > BPXM036I BPXAS INITIATORS SHUTDOWN. > > F OMVS,SHUTDOWN > > IEE342I MODIFY REJECTED-TASK BUSY > > > > Tony Thigpen > > > > Cieri, Anthony wrote on 5/14/19 5:50 PM: > >> Under the OAS column of your D A,L display there is still one task. > >> > >> Was a $P JES2 command ever issued. Usually, when we are at this > >> point in a DR environment and the $P JES2 command is issued, JES2 may > >> tell you what is still active if the stop command fails. > >> > >> Here are some other possibly useful commands: > >> > >> F BPXOINIT,SHUTDOEN=FORKINIT > >> F OMVS,SHUTDOWN > >> > >> Hth > >> Tony > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Jerry Whitteridge > >> Sent: Tuesday, May 14, 2019 5:40 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: JES2 shutdown failure > >> > >> [[ SEI WARNING *** This email was sent from an external source. Do not > >> open attachments or click on links from unknown or suspicious senders. > >> *** ]] > >> > >> > >> I'd be suspicious of your OMVS environment at this point. Try using a > >> D A,A > >> to see more tasks active. > >> > >> Jerry Whitteridge > >> Delivery Manager / Mainframe Architect > >> GTS - Safeway Account > >> 602 527 4871 Mobile > >> jerry.whitteri...@ibm.com > >> > >> IBM Services > >> > >> IBM Mainframe Discussion List wrote on > >> 05/14/2019 02:35:25 PM: > >> > >>> From: Brian France > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Date: 05/14/2019 02:35 PM > >>> Subject: [EXTERNAL] Re: JES2 shutdown failure > >>> Sent by: IBM Mainframe Discussion List > >>> > >>> init's drained? lines drained? omvs shutdown? > >>> > >>> On 5/14/19 5:32 PM, Tony Thigpen wrote: > I am testing on a DR box, and I am seeing a shutdown problem with JES2. > > Here is the console log: > $da > $HASP612 NO ACTIVE JOBS > $P JES2 > IEA964I HARDCOPY SUSPENDED, REASON=HCSW > $da > IEE707I $DA NOT EXECUTED > D A,L > JOBS M/STS USERSSYSASINITS ACTIVE/MAX VTAM > >> OAS > 020 0002500/0 > >> 1 > JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT > >> S > > At this point, JES2 never seems to shut down. (The only job running is > SHUTHUP1 which is the automated shutdown procedure that runs outside > of JES2.) > > Thoughts? > > >>> -- > >>> Brian W. France > >>> Systems Administrator (Mainframe) > >>> Pennsylvania State University > >>> Administrative Information Services - Infrastructure/SYSARC > >>> Rm 25 Shields Bldg., University Park, Pa. 16802 > >>> 814-863-4739 > >>> b...@psu.edu > >>> > >>> "To make an apple pie from scratch, you must first invent the universe." > >>> > >>> -- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >>> > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu
Re: JES2 shutdown failure - OMVS will not shut down
As everything indicates that OMVS was the problem, I brought the machine back up and try shutting down OMVS outside of my system shutdown. This is the results: 22.02.52 HUP1 F BPXOINIT,SHUTDOWN=FORKINIT 22.02.52 HUP1 BPXM037I BPXAS INITIATOR SHUTDOWN DELAYED. 22.02.52 HUP1 STC03368 IEF404I BPXAS - ENDED - TIME=22.02.52 22.02.52 HUP1 STC03334 IEF404I BPXAS - ENDED - TIME=22.02.52 22.02.52 HUP1 STC03368 $HASP395 BPXASENDED 22.02.52 HUP1 STC03369 IEF404I BPXAS - ENDED - TIME=22.02.52 22.02.52 HUP1 STC03334 $HASP395 BPXASENDED 22.02.52 HUP1 STC03370 IEF404I BPXAS - ENDED - TIME=22.02.52 22.02.52 HUP1 STC03369 $HASP395 BPXASENDED 22.02.52 HUP1 STC03370 $HASP395 BPXASENDED 22.03.16 HUP1 F OMVS,SHUTDOWN 22.03.16 HUP1 IEE342I MODIFY REJECTED-TASK BUSY Thoughts? Tony Thigpen Tony Thigpen wrote on 5/14/19 5:55 PM: F BPXOINIT,SHUTDOWN=FORKINIT BPXM036I BPXAS INITIATORS SHUTDOWN. F OMVS,SHUTDOWN IEE342I MODIFY REJECTED-TASK BUSY Tony Thigpen Cieri, Anthony wrote on 5/14/19 5:50 PM: Under the OAS column of your D A,L display there is still one task. Was a $P JES2 command ever issued. Usually, when we are at this point in a DR environment and the $P JES2 command is issued, JES2 may tell you what is still active if the stop command fails. Here are some other possibly useful commands: F BPXOINIT,SHUTDOEN=FORKINIT F OMVS,SHUTDOWN Hth Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Tuesday, May 14, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: From: Brian France To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/14/2019 02:35 PM Subject: [EXTERNAL] Re: JES2 shutdown failure Sent by: IBM Mainframe Discussion List init's drained? lines drained? omvs shutdown? On 5/14/19 5:32 PM, Tony Thigpen wrote: I am testing on a DR box, and I am seeing a shutdown problem with JES2. Here is the console log: $da $HASP612 NO ACTIVE JOBS $P JES2 IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT EXECUTED D A,L JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS 0 2 0 00025 0 0/0 1 JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S At this point, JES2 never seems to shut down. (The only job running is SHUTHUP1 which is the automated shutdown procedure that runs outside of JES2.) Thoughts? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SHA-1 collision attacks are now actually practical and a looming danger
https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCPIP.DATA file
Does this help? https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/resolver_cfg_files.htm#resconf__ftypet On Tue, May 14, 2019 at 5:57 PM Tony Thigpen wrote: > Currently, all the TCPIP jobs have to specify the //SYSTCPD DD > statement. Since we only have one stach and one TCPIP.DATA file, are > there any options at the system level that will eliminate the need for > each batch job to have a //SYSTCPD DD? > > -- > Tony Thigpen > > -- > 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: mainframe hacking "success stories"?
+ 1 בתאריך יום ג׳, 14 במאי 2019, 21:29, מאת Alan Altmark < alan_altm...@us.ibm.com>: > Reading all of these posts has brought out the salient points of IT > security: > > 1. All the technology in the world won't help you if you don't use it. > > 2. Stupid people can outwit a capable machine (SET SECURITY OFF). > > 3. Z security builds on its long history and culture of talented people, > effective processes, and robust products. When all are fully engaged, its > security mechanisms are really hard to beat. > > 4. The bad guys have time on their side, often putting the good guys on > the defensive. The difference between the two is what protects you. The > more places you have those buffers, the better the protection will be. > > 5. Sometimes obscurity is good. Sometimes not. It depends on what you > are hiding and from whom. But don't be upset when your secret is becomes > known. It shouldn't be your only defense. > > 6. When someone possesses valid credentials to a system, only their > activities while using them will tell you if they are Good or Evil. This > is the weakest part of all system security. Humans are vital to IT > security, yet are the weakest link, being both easiest to manipulate and > capable of being compromised. (I've seen the movies; retinal scanners > won't help.)We try to recognize changes in system behavior to know when > something is wrong, yet we pay little attention to human activities. (How > to recognize when your Db2 database is being surreptitiously unloaded in > small bits over a long period of time.) > > 7. The "Z" on the box doesn't make it more secure than any other platform > (no miracles or magic). It does, however, come with an impressive arsenal > that you can use to make it so. I would be comfortable saying that it is > "more securable" than any other general purpose platform. That encompasses > both the types of security services and the difficulty in subverting them. > > 8. Prevention is better than detection, but detection lets us know when > our preventive measures have failed. > > 9. Have you done all that is *commercially reasonable* to protect your > data and your services? All that is possible may not be reasonable in some > contexts, so don't fall into that trap. Understanding your liability (cost > of loss) helps you assess "reasonable". > > 10. Assume that nothing is perfect. (You would be correct.) Bad things > happen to good people. If you detect that, in spite of your best attempts, > the unthinkable has happened, are you prepared to deal with it competently, > calmly, and quickly? > > > Alan Altmark > IBM Systems Lab Services > z/VM Consultant > > -- > 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
TCPIP.DATA file
Currently, all the TCPIP jobs have to specify the //SYSTCPD DD statement. Since we only have one stach and one TCPIP.DATA file, are there any options at the system level that will eliminate the need for each batch job to have a //SYSTCPD DD? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure
17.27.15 HUP1 D OMVS,A=ALL 17.27.15 HUP1 BPXO040I 17.27.15 DISPLAY OMVS 921 OMVS 000E FORK SHUTDOWN OMVS=(00,P1) USER JOBNAME ASIDPID PPID STATE START CT_SECS OMVSKERN BPXOINIT 001D 1 0 MRI 16.03.18 .148 LATCHWAITPID= 0 CMD=BPXPINPR SERVER=Init Process AF=0 MF=0 TYPE=FILE Tony Thigpen Cieri, Anthony wrote on 5/14/19 6:05 PM: OMVS is still doing something You might try D OMVS,A=ALL for more information -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Tuesday, May 14, 2019 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] F BPXOINIT,SHUTDOWN=FORKINIT BPXM036I BPXAS INITIATORS SHUTDOWN. F OMVS,SHUTDOWN IEE342I MODIFY REJECTED-TASK BUSY Tony Thigpen Cieri, Anthony wrote on 5/14/19 5:50 PM: Under the OAS column of your D A,L display there is still one task. Was a $P JES2 command ever issued. Usually, when we are at this point in a DR environment and the $P JES2 command is issued, JES2 may tell you what is still active if the stop command fails. Here are some other possibly useful commands: F BPXOINIT,SHUTDOEN=FORKINIT F OMVS,SHUTDOWN Hth Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Tuesday, May 14, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: From: Brian France To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/14/2019 02:35 PM Subject: [EXTERNAL] Re: JES2 shutdown failure Sent by: IBM Mainframe Discussion List init's drained? lines drained? omvs shutdown? On 5/14/19 5:32 PM, Tony Thigpen wrote: I am testing on a DR box, and I am seeing a shutdown problem with JES2. Here is the console log: $da $HASP612 NO ACTIVE JOBS $P JES2 IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT EXECUTED D A,L JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS 0 2 0 00025 0 0/0 1 JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S At this point, JES2 never seems to shut down. (The only job running is SHUTHUP1 which is the automated shutdown procedure that runs outside of JES2.) Thoughts? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure [EXTERNAL]
'NOT EXECUTED' means that JES2 has gone down too far to execute normal commands. Try '$PJES2,ABEND', which almost always works. Then start it back up again and see if a normal shutdown goes alright. . . 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 Thigpen Sent: Tuesday, May 14, 2019 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JES2 shutdown failure [EXTERNAL] $DA,X IEE707I $DA,XNOT EXECUTED Tony Thigpen Feller, Paul wrote on 5/14/19 5:50 PM: > Sometimes a $DA,X can help find what is going on. Also all the other > suggestions are good to try. > > Thanks.. > > Paul Feller > AGT Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jerry Whitteridge > Sent: Tuesday, May 14, 2019 4:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 shutdown failure [EXTERNAL] > > I'd be suspicious of your OMVS environment at this point. Try using a D A,A > to see more tasks active. > > Jerry Whitteridge > Delivery Manager / Mainframe Architect GTS - Safeway Account > 602 527 4871 Mobile > jerry.whitteri...@ibm.com > > IBM Services > > IBM Mainframe Discussion List wrote on > 05/14/2019 02:35:25 PM: > >> From: Brian France >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 05/14/2019 02:35 PM >> Subject: [EXTERNAL] Re: JES2 shutdown failure Sent by: IBM Mainframe >> Discussion List >> >> init's drained? lines drained? omvs shutdown? >> >> On 5/14/19 5:32 PM, Tony Thigpen wrote: >>> I am testing on a DR box, and I am seeing a shutdown problem with JES2. >>> >>> Here is the console log: >>> $da >>> $HASP612 NO ACTIVE JOBS >>> $P JES2 >>> IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT >>> EXECUTED D A,L >>> JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM > OAS >>> 0 2 0 00025 0 0/0 > 1 >>> JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 >>> OWT > S >>> >>> At this point, JES2 never seems to shut down. (The only job running >>> is >>> SHUTHUP1 which is the automated shutdown procedure that runs outside >>> of JES2.) >>> >>> Thoughts? >>> >> -- >> Brian W. France >> Systems Administrator (Mainframe) >> Pennsylvania State University >> Administrative Information Services - Infrastructure/SYSARC Rm 25 >> Shields Bldg., University Park, Pa. 16802 >> 814-863-4739 >> b...@psu.edu >> >> "To make an apple pie from scratch, you must first invent the universe." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure
OMVS is still doing something You might try D OMVS,A=ALL for more information -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Tuesday, May 14, 2019 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] F BPXOINIT,SHUTDOWN=FORKINIT BPXM036I BPXAS INITIATORS SHUTDOWN. F OMVS,SHUTDOWN IEE342I MODIFY REJECTED-TASK BUSY Tony Thigpen Cieri, Anthony wrote on 5/14/19 5:50 PM: > Under the OAS column of your D A,L display there is still one task. > > Was a $P JES2 command ever issued. Usually, when we are at this point > in a DR environment and the $P JES2 command is issued, JES2 may tell you what > is still active if the stop command fails. > > Here are some other possibly useful commands: > > F BPXOINIT,SHUTDOEN=FORKINIT > F OMVS,SHUTDOWN > > Hth > Tony > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jerry Whitteridge > Sent: Tuesday, May 14, 2019 5:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 shutdown failure > > [[ SEI WARNING *** This email was sent from an external source. Do not open > attachments or click on links from unknown or suspicious senders. *** ]] > > > I'd be suspicious of your OMVS environment at this point. Try using a D A,A > to see more tasks active. > > Jerry Whitteridge > Delivery Manager / Mainframe Architect > GTS - Safeway Account > 602 527 4871 Mobile > jerry.whitteri...@ibm.com > > IBM Services > > IBM Mainframe Discussion List wrote on > 05/14/2019 02:35:25 PM: > >> From: Brian France >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 05/14/2019 02:35 PM >> Subject: [EXTERNAL] Re: JES2 shutdown failure >> Sent by: IBM Mainframe Discussion List >> >> init's drained? lines drained? omvs shutdown? >> >> On 5/14/19 5:32 PM, Tony Thigpen wrote: >>> I am testing on a DR box, and I am seeing a shutdown problem with JES2. >>> >>> Here is the console log: >>> $da >>> $HASP612 NO ACTIVE JOBS >>> $P JES2 >>> IEA964I HARDCOPY SUSPENDED, REASON=HCSW >>> $da >>> IEE707I $DA NOT EXECUTED >>> D A,L >>> JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM > OAS >>> 0 2 0 00025 0 0/0 > 1 >>> JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT > S >>> >>> At this point, JES2 never seems to shut down. (The only job running is >>> SHUTHUP1 which is the automated shutdown procedure that runs outside >>> of JES2.) >>> >>> Thoughts? >>> >> -- >> Brian W. France >> Systems Administrator (Mainframe) >> Pennsylvania State University >> Administrative Information Services - Infrastructure/SYSARC >> Rm 25 Shields Bldg., University Park, Pa. 16802 >> 814-863-4739 >> b...@psu.edu >> >> "To make an apple pie from scratch, you must first invent the universe." >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure
F BPXOINIT,SHUTDOWN=FORKINIT BPXM036I BPXAS INITIATORS SHUTDOWN. F OMVS,SHUTDOWN IEE342I MODIFY REJECTED-TASK BUSY Tony Thigpen Cieri, Anthony wrote on 5/14/19 5:50 PM: Under the OAS column of your D A,L display there is still one task. Was a $P JES2 command ever issued. Usually, when we are at this point in a DR environment and the $P JES2 command is issued, JES2 may tell you what is still active if the stop command fails. Here are some other possibly useful commands: F BPXOINIT,SHUTDOEN=FORKINIT F OMVS,SHUTDOWN Hth Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Tuesday, May 14, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: From: Brian France To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/14/2019 02:35 PM Subject: [EXTERNAL] Re: JES2 shutdown failure Sent by: IBM Mainframe Discussion List init's drained? lines drained? omvs shutdown? On 5/14/19 5:32 PM, Tony Thigpen wrote: I am testing on a DR box, and I am seeing a shutdown problem with JES2. Here is the console log: $da $HASP612 NO ACTIVE JOBS $P JES2 IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT EXECUTED D A,L JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS 0 2 0 00025 0 0/0 1 JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S At this point, JES2 never seems to shut down. (The only job running is SHUTHUP1 which is the automated shutdown procedure that runs outside of JES2.) Thoughts? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." -- 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: JES2 shutdown failure [EXTERNAL]
$DA,X IEE707I $DA,XNOT EXECUTED Tony Thigpen Feller, Paul wrote on 5/14/19 5:50 PM: Sometimes a $DA,X can help find what is going on. Also all the other suggestions are good to try. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Tuesday, May 14, 2019 4:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [EXTERNAL] I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: From: Brian France To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/14/2019 02:35 PM Subject: [EXTERNAL] Re: JES2 shutdown failure Sent by: IBM Mainframe Discussion List init's drained? lines drained? omvs shutdown? On 5/14/19 5:32 PM, Tony Thigpen wrote: I am testing on a DR box, and I am seeing a shutdown problem with JES2. Here is the console log: $da $HASP612 NO ACTIVE JOBS $P JES2 IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT EXECUTED D A,L JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS 0 2 0 00025 0 0/0 1 JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S At this point, JES2 never seems to shut down. (The only job running is SHUTHUP1 which is the automated shutdown procedure that runs outside of JES2.) Thoughts? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." -- 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 -- Please note: This message originated outside your organization. Please use caution when opening links or attachments. -- 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: JES2 shutdown failure
Output from D A,A. *MASTER* *MASTER* NSW * A=0001 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=018.344S ET=00.48.06 WUID=STC03246 USERID=+MASTER+ WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO PCAUTH PCAUTHNSW * A=0002 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.009S ET=00.48.06 WKL=SYSTEM SCL=SYSSTC P=1 RGP=N/A SRVR=NO QSC=NO RASP RASP NSW * A=0003 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.005S ET=00.48.06 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO TRACETRACE NSW * A=0004 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.010S ET=00.48.06 WKL=SYSTEM SCL=SYSSTC P=1 RGP=N/A SRVR=NO QSC=NO DUMPSRV DUMPSRV DUMPSRV NSW * A=0005 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.134S ET=00.48.04 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO XCFASXCFASIEFPROC NSW * A=0006 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=002.059S ET=00.48.04 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO GRS GRS NSW * A=0007 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.092S ET=00.48.06 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO SMXC SMXC NSW * A=0008 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.760S ET=00.48.06 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO SYSBMAS SYSBMAS NSW * A=0009 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.031S ET=00.48.06 WKL=SYSTEM SCL=SYSSTC P=1 RGP=N/A SRVR=NO QSC=NO CONSOLE CONSOLE NSW * A=000A PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=004.199S ET=00.48.06 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO WLM WLM IEFPROC NSW * A=000B PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=004.067S ET=00.48.04 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO ANTMAIN ANTMAIN IEFPROC NSW * A=000C PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.277S ET=00.48.04 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO ANTAS000 ANTAS000 IEFPROC NSW * A=000D PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.110S ET=00.48.02 WKL=SYSTEM SCL=SYSSTC P=1 RGP=N/A SRVR=NO QSC=NO OMVS OMVS OMVS NSW * A=000E PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=000.517S ET=00.48.04 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO JESXCF JESXCF IEFPROC NSW * A=0010 PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE CT=004.067S ET=00.48.04 WKL=SYSTEM SCL=SYSTEM P=1 RGP=N/A SRVR=NO QSC=NO ANTMAIN ANTMAIN IEFPROC NSW * A=000C PER=NO SMC=000 PGN=N/A DMN=N/A AFF=NONE
Re: JES2 shutdown failure
Under the OAS column of your D A,L display there is still one task. Was a $P JES2 command ever issued. Usually, when we are at this point in a DR environment and the $P JES2 command is issued, JES2 may tell you what is still active if the stop command fails. Here are some other possibly useful commands: F BPXOINIT,SHUTDOEN=FORKINIT F OMVS,SHUTDOWN Hth Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Tuesday, May 14, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: > From: Brian France > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/14/2019 02:35 PM > Subject: [EXTERNAL] Re: JES2 shutdown failure > Sent by: IBM Mainframe Discussion List > > init's drained? lines drained? omvs shutdown? > > On 5/14/19 5:32 PM, Tony Thigpen wrote: > > I am testing on a DR box, and I am seeing a shutdown problem with JES2. > > > > Here is the console log: > > $da > > $HASP612 NO ACTIVE JOBS > > $P JES2 > > IEA964I HARDCOPY SUSPENDED, REASON=HCSW > > $da > > IEE707I $DA NOT EXECUTED > > D A,L > > JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS > > 0 2 0 00025 0 0/0 1 > > JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S > > > > At this point, JES2 never seems to shut down. (The only job running is > > SHUTHUP1 which is the automated shutdown procedure that runs outside > > of JES2.) > > > > Thoughts? > > > -- > Brian W. France > Systems Administrator (Mainframe) > Pennsylvania State University > Administrative Information Services - Infrastructure/SYSARC > Rm 25 Shields Bldg., University Park, Pa. 16802 > 814-863-4739 > b...@psu.edu > > "To make an apple pie from scratch, you must first invent the universe." > > -- > 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: JES2 shutdown failure [EXTERNAL]
Sometimes a $DA,X can help find what is going on. Also all the other suggestions are good to try. Thanks.. Paul Feller AGT Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Tuesday, May 14, 2019 4:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 shutdown failure [EXTERNAL] I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: > From: Brian France > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/14/2019 02:35 PM > Subject: [EXTERNAL] Re: JES2 shutdown failure Sent by: IBM Mainframe > Discussion List > > init's drained? lines drained? omvs shutdown? > > On 5/14/19 5:32 PM, Tony Thigpen wrote: > > I am testing on a DR box, and I am seeing a shutdown problem with JES2. > > > > Here is the console log: > > $da > > $HASP612 NO ACTIVE JOBS > > $P JES2 > > IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT > > EXECUTED D A,L > > JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS > > 0 2 0 00025 0 0/0 1 > > JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 > > OWT S > > > > At this point, JES2 never seems to shut down. (The only job running > > is > > SHUTHUP1 which is the automated shutdown procedure that runs outside > > of JES2.) > > > > Thoughts? > > > -- > Brian W. France > Systems Administrator (Mainframe) > Pennsylvania State University > Administrative Information Services - Infrastructure/SYSARC Rm 25 > Shields Bldg., University Park, Pa. 16802 > 814-863-4739 > b...@psu.edu > > "To make an apple pie from scratch, you must first invent the universe." > > -- > 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 -- Please note: This message originated outside your organization. Please use caution when opening links or attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 shutdown failure
I'd be suspicious of your OMVS environment at this point. Try using a D A,A to see more tasks active. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 05/14/2019 02:35:25 PM: > From: Brian France > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/14/2019 02:35 PM > Subject: [EXTERNAL] Re: JES2 shutdown failure > Sent by: IBM Mainframe Discussion List > > init's drained? lines drained? omvs shutdown? > > On 5/14/19 5:32 PM, Tony Thigpen wrote: > > I am testing on a DR box, and I am seeing a shutdown problem with JES2. > > > > Here is the console log: > > $da > > $HASP612 NO ACTIVE JOBS > > $P JES2 > > IEA964I HARDCOPY SUSPENDED, REASON=HCSW > > $da > > IEE707I $DA NOT EXECUTED > > D A,L > > JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS > > 0 2 0 00025 0 0/0 1 > > JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S > > > > At this point, JES2 never seems to shut down. (The only job running is > > SHUTHUP1 which is the automated shutdown procedure that runs outside > > of JES2.) > > > > Thoughts? > > > -- > Brian W. France > Systems Administrator (Mainframe) > Pennsylvania State University > Administrative Information Services - Infrastructure/SYSARC > Rm 25 Shields Bldg., University Park, Pa. 16802 > 814-863-4739 > b...@psu.edu > > "To make an apple pie from scratch, you must first invent the universe." > > -- > 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: JES2 shutdown failure
init's drained? lines drained? omvs shutdown? On 5/14/19 5:32 PM, Tony Thigpen wrote: > I am testing on a DR box, and I am seeing a shutdown problem with JES2. > > Here is the console log: > $da > $HASP612 NO ACTIVE JOBS > $P JES2 > IEA964I HARDCOPY SUSPENDED, REASON=HCSW > $da > IEE707I $DA NOT EXECUTED > D A,L > JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS > 0 2 0 00025 0 0/0 1 > JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S > > At this point, JES2 never seems to shut down. (The only job running is > SHUTHUP1 which is the automated shutdown procedure that runs outside > of JES2.) > > Thoughts? > -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 shutdown failure
I am testing on a DR box, and I am seeing a shutdown problem with JES2. Here is the console log: $da $HASP612 NO ACTIVE JOBS $P JES2 IEA964I HARDCOPY SUSPENDED, REASON=HCSW $da IEE707I $DA NOT EXECUTED D A,L JOBS M/STS USERSSYSASINITS ACTIVE/MAX VTAM OAS 020 0002500/0 1 JES2 JES2 IEFPROC NSW S SHUTHUP1 SHUTHUP1 COMAND00 OWT S At this point, JES2 never seems to shut down. (The only job running is SHUTHUP1 which is the automated shutdown procedure that runs outside of JES2.) Thoughts? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
+1CharlesSent from a mobile; please excuse the brevity. Original message From: Alan Altmark Date: 5/14/19 11:28 AM (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Reading all of these posts has brought out the salient points of IT security:1. All the technology in the world won't help you if you don't use it.2. Stupid people can outwit a capable machine (SET SECURITY OFF).3. Z security builds on its long history and culture of talented people, effective processes, and robust products. When all are fully engaged, its security mechanisms are really hard to beat.4. The bad guys have time on their side, often putting the good guys on the defensive. The difference between the two is what protects you. The more places you have those buffers, the better the protection will be.5. Sometimes obscurity is good. Sometimes not. It depends on what you are hiding and from whom. But don't be upset when your secret is becomes known. It shouldn't be your only defense.6. When someone possesses valid credentials to a system, only their activities while using them will tell you if they are Good or Evil. This is the weakest part of all system security. Humans are vital to IT security, yet are the weakest link, being both easiest to manipulate and capable of being compromised. (I've seen the movies; retinal scanners won't help.) We try to recognize changes in system behavior to know when something is wrong, yet we pay little attention to human activities. (How to recognize when your Db2 database is being surreptitiously unloaded in small bits over a long period of time.)7. The "Z" on the box doesn't make it more secure than any other platform (no miracles or magic). It does, however, come with an impressive arsenal that you can use to make it so. I would be comfortable saying that it is "more securable" than any other general purpose platform. That encompasses both the types of security services and the difficulty in subverting them.8. Prevention is better than detection, but detection lets us know when our preventive measures have failed.9. Have you done all that is *commercially reasonable* to protect your data and your services? All that is possible may not be reasonable in some contexts, so don't fall into that trap. Understanding your liability (cost of loss) helps you assess "reasonable".10. Assume that nothing is perfect. (You would be correct.) Bad things happen to good people. If you detect that, in spite of your best attempts, the unthinkable has happened, are you prepared to deal with it competently, calmly, and quickly?Alan AltmarkIBM Systems Lab Servicesz/VM Consultant--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: LE question
You can get control in an ESTAE exit after a cancel, you can't do a retry. If your management isn't willing to rein in rogue operators than there is no good solution. At one point checkpoint/restart might have helped, but how many applications these days have only a single task? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of scott Ford Sent: Tuesday, May 14, 2019 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LE question All: I need to do some research on how job is cancelled via the Operator , Abend S222. I read through some of the Boston share doc of some time ago by Ed, Sam and Skip. Its great. I have a question in regard to something that was stated on the presentation. I have a job written in Cobol, this job has mission critical data storage in a table or array in program storage and that job has been cancelled by an Operator. I dont want to lose that data. I want to know how i should approach it. The other qualifier here is that this is Cobol v4.2 which i am stuck with. Would I have to write a non-LE assembler caller and somehow set and ESPIE or ESTAE and then somehow involve CALLRTM ? I have done a lot of digging and not sure recovery of this nature ( LE ) is mentioned. I understand Condition Handling can be called also but will it handle an Operator cancel ...I know there are products, thats not an option because of cost. Regards, -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” http://secure-web.cisco.com/1i6HehjnekxzPINpYjHo4xHxkhlaIaxo0mUQVzHZD8XuBxmIMjE4j9VFFiAegSf9cFHiQx-hLH7NgcDNxcDiHYrHWhF9-MB-8z8-hFkWaehTi6vaAKK-x2may5wKk6Wfur4Dz5mqUoIQVPyQww7JecRtP39WKljV5W9MFfhryIzn5CJxXMcZ6nY48U7x9IzqyZFH0fRM-FKUAFpeckQ3CGrPBonOSnKOD1N8Vhxq9izDhH49RnyEr9l1fbzsq4k-pl1sWQX4J3bop2xGgZivNCeZS-8GGy2L59xw0Noo8ruZuPT-SjRCouy6rqxApVBloGCoJDzLozSSHNnfytJO39tFDljE30Aet7iUDOaUaAEP1YwFc4dvxsSCEb0zsf_EGVY38usPCasOizskY7MPt2GJ4uYpo0_4Kb7ip8NKBMxjlXTUEfM15E8pz9_a9svwX/http%3A%2F%2Fwww.idmworks.com scott.f...@idmworks.com Blog: http://secure-web.cisco.com/1dg9HxTLnZxcpqR83IfIqactoHIAZEFJ4rPxwE3WwOu8SB_ySFT-YvKSVAaIQVyHbiJlHhGjBrIsgDpv9_PqYBPaKFWpzjBKa23bt1DKTK54n3Bg6_D6zdFbvzWG-tDX7UqVCHSz4kul2AgTjQR6mka3SIdtsl_eNr5GPQ_EuHzLDkhzsNPQzGQw_BsugseFtlDR53m6LA_tfQCeZjMvtR9UujlLL0ezxK-QxPEIkLsT2U9aH9smh32GHh8BKkiZbUZdsUJhUogFs8OyeFYusRfdRZ3uV47VM0tS6ig9oVgxEYPsi533JsRGEpOJLLUUt27WdqLcrHSBAQPjGBvgzgYh0NPO2msipV0WvrY5XTECpSAAXn27Q6HFiOwbxLeclu0ylqWTNaQPcGQcODH2nJddI8eIsA3kWWBZyPiAfAh-rzIpCn9JWxHLy2TX1U1sj/http%3A%2F%2Fwww.idmworks.com%2Fblog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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: LE question
I might be going off on a weird tangent. But if this is a started task, instead of a program running in a batch job. And if it can be run as a single step STC (not sure if this is a requirement). And it resides in an APF authorized library. Then I would "register" the program in the SCHEDnn member with the PPT option of NOCANCEL. If anyone issues a CANCEL command, it will be rejected. I think that a FORCE n,ARM will still work however. But not many people, other than sysprogs, use that. I might ever use the SYST option: PPT PROGRAM(myprog) NOCANCEL SYST https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae200/ieae200540.htm -- 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: LE question
scott Ford wrote:
>I need to do some research on how job is cancelled via the Operator , Abend
>S222. I read through some of the Boston share doc of some time ago by Ed, Sam
>and Skip. Its great.
>I have a job written in Cobol, this job has mission critical data storage in a
>table or array in program storage and that job has been cancelled by an
>Operator. I dont want to lose that data.
Aw crap, crap CRAP! Just ensure that the lame operator ('tape ape') does not
cancel your precious job(s). [1]
Why, oh why, did he/she/it canceled that job in the first place? Huh?
Did he/she/it smoked some 'Durban Poison' (dagga/marijuana)?
Stopping this cancelling fun will save you a lot of grey hairs and having you
to invent innovative abend handling steps.
>I want to know how i should approach it. The other qualifier here is that this
>is Cobol v4.2 which i am stuck with.
There is no way to recover the data, unless you have a backup and the COBOL
program can be rerun without any extra steps.
Ouch, your scenario is a real PITA! Sorry for not giving you a real solution on
how to handle that S222 abend.
Groete / Greetings
Elardus Engelbrecht
[1] - These ops also just reply on a console WTOR with whatever they want...
Gr...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS specific commits (was: ... "awk" ...)
On 5/14/2019 12:00 PM, Tom Marchant wrote: On Tue, 14 May 2019 11:29:22 -0500, John McKown wrote: IIRC, Rocket will supply the source if you request it I disagree. See part 6 of the GPL v3 " for a price no more than your reasonable cost of physically performing this conveying of source". Tom has the correct interpretation of the GPL. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
sme...@gmu.edu (Seymour J Metz) writes: > On the S/360 the Alternate CPU Recovery facility was limited to 65MP > (I don't know about 9020 or TSS/360.) On MVS it was a standard > facility, although on an AP or MP without Channel Set Switching losing > the processor with the I/O channels was fatal. With MVS/XA and later > I/O was more robust. 360/65MP shared memory ... but processors had their own dedicated channels, to simulate "shared" i/o, it required controllers with multi-channel interfaces. 360/67MP had "channel controller" ... that included all channels to be accessed by all processors had bunch of switches to reconfigure hardware ... and switch settings were visible in the control registers. It also had hardware multiple paths to memory, introduced additional latency overhead ... but for I/O intensive workloads (where processors and I/O could simultaneously be doing transfers) it could have significant higher throughput (non-MP 360/67 was more like 65 and other 360s, where I/O memory accesses could interfer with cpu memory accesses). Could order a MP with only one processor and get channel controller and independent paths to memory. http://www.bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf Originally 360/67 announcement was for up to four processors (and the channel controller control register values had fields for all four processors). However (mostly) just two processors were built ... except for a special three processor 360/67 done for Lockheed and the manned orbital laboratory project. https://en.wikipedia.org/wiki/Manned_Orbiting_Laboratory tri-plex machine also provided for the configuration switch settings to be changed by changing the control register values (not just sensing the switch settings). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE question
On Tue, 14 May 2019 14:22:37 -0400 scott Ford wrote: :>I need to do some research on how job is cancelled via the Operator , Abend :>S222. I read through some of the Boston share doc of some time ago by Ed, :>Sam and Skip. Its great. :>I have a question in regard to something that was stated on the :>presentation. :> :>I have a job written in Cobol, this job has mission critical data storage :>in a table or array in program storage and that job has been cancelled by :>an Operator. I dont want to lose that data. Well, the first step would to not allow the job to be canceled. One would think that automation products would be able to do that. And instructions to the operator. Why would he be willy-nilly canceling jobs? :>I want to know how i should approach it. The other qualifier here is that :>this is Cobol v4.2 which i am stuck with. I would approach this procedurally. :>Would I have to write a non-LE assembler caller and somehow set and ESPIE :>or ESTAE and then somehow involve CALLRTM ? :>I have done a lot of digging and not sure recovery of this nature ( LE ) is :>mentioned. I understand Condition Handling can be called also but :>will it handle an Operator cancel ...I know there are products, thats not :>an option because of cost. What about if the job abends from its own failures? This sounds like what checkpoint/restart was made for. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE question
Good luck! -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Tuesday, May 14, 2019 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE question Alan, I found some more info, we have a ECVT customer table entry. This sounds like what I want. Scott On Tue, May 14, 2019 at 2:55 PM scott Ford wrote: > Alan, > > A big thanks ..A Common Dataspace is good , i will have to find how to > anchor ..homework. > > Regards, > Scott > > On Tue, May 14, 2019 at 2:45 PM Allan Staller > wrote: > >> That is why I specified a COMMON data space (as opposed to a data >> space), and the init/term routines. >> A "data space" has no persistence beyond the creating task. A "common >> dataspace" is anchored somewhere in the operating system. >> I will leave the details to your perusal of the FM's. >> Recommended reading: >> SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level >> Languages >> SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide >> >> For the pendants on the list, please forgive me I have used incorrect >> terminology. >> Additional responses interspersed below. >> >> HTH, >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of scott Ford >> Sent: Tuesday, May 14, 2019 1:35 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LE question >> >> Alan, >> >> Yes that was my thinking. What about persistence ? >> --> "common dataspace" vs. dataspace. >> My question is there a dataspace that can be up without an owning >> running TCB ? >> --> YES >> Even it is require, if memory serves me another program if they need >> to access the dataspace can query for the ALET ? >> --> See recommended reading >> Can someone tell me if i am correct ? >> >> Scott >> >> On Tue, May 14, 2019 at 2:28 PM Allan Staller >> wrote: >> >> > Common Data Space? This is kind of what data spaces were invented for. >> > An init routine to run more or less @ IPL time to create, anchor >> > and load the data space. >> > Cobol to access/update the data via the dataspace Optional routine >> > to save the dataspace @ shutdown. >> > >> > HTH, >> > >> > -Original Message- >> > From: IBM Mainframe Discussion List On >> > Behalf Of scott Ford >> > Sent: Tuesday, May 14, 2019 1:23 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: LE question >> > >> > All: >> > >> > I need to do some research on how job is cancelled via the Operator >> > , Abend S222. I read through some of the Boston share doc of some >> > time ago by Ed, Sam and Skip. Its great. >> > I have a question in regard to something that was stated on the >> > presentation. >> > >> > I have a job written in Cobol, this job has mission critical data >> > storage in a table or array in program storage and that job has >> > been cancelled by an Operator. I dont want to lose that data. >> > I want to know how i should approach it. The other qualifier here >> > is that this is Cobol v4.2 which i am stuck with. >> > >> > Would I have to write a non-LE assembler caller and somehow set and >> > ESPIE or ESTAE and then somehow involve CALLRTM ? >> > I have done a lot of digging and not sure recovery of this nature ( >> > LE >> > ) is mentioned. I understand Condition Handling can be called also >> > but will it handle an Operator cancel ...I know there are products, >> > thats not an option because of cost. >> > >> > Regards, >> > >> > -- >> > >> > >> > >> > *IDMWORKS * >> > >> > Scott Ford >> > >> > z/OS Dev. >> > >> > >> > >> > >> > “By elevating a friend or Collegue you elevate yourself, by >> > demeaning a friend or collegue you demean yourself” >> > >> > >> > >> > >> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.co >> > m >> > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d >> > 6d8 >> > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752 >> > 619 >> > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dres >> > erv >> > ed=0 >> > >> > scott.f...@idmworks.com >> > >> > Blog: >> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.co >> > m%2 >> > Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5 >> > 769 >> > a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63693455 >> > 768 >> > 7752619sdata=IvvsMACZMrze2eQUcFI2BYSxbK%2Fw%2BB4U%2B8xIHbFtFYw >> > %3D >> > reserved=0 >> > >> > >> > >> > >> > >> > *The information contained in this email message and any attachment >> > may be privileged, confidential, proprietary or otherwise protected >> > from disclosure. If the reader of this message is not the intended >> > recipient, you are hereby notified that any dissemination, >> > distribution, copying or use of this message and any attachment is >> > strictly prohibited. If you have received this message in error, >> > please notify us immediately by replying to the message and >> > permanently delete it from your computer and
Re: LE question
Alan, I found some more info, we have a ECVT customer table entry. This sounds like what I want. Scott On Tue, May 14, 2019 at 2:55 PM scott Ford wrote: > Alan, > > A big thanks ..A Common Dataspace is good , i will have to find how to > anchor ..homework. > > Regards, > Scott > > On Tue, May 14, 2019 at 2:45 PM Allan Staller > wrote: > >> That is why I specified a COMMON data space (as opposed to a data space), >> and the init/term routines. >> A "data space" has no persistence beyond the creating task. A "common >> dataspace" is anchored somewhere in the operating system. >> I will leave the details to your perusal of the FM's. >> Recommended reading: >> SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level >> Languages >> SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide >> >> For the pendants on the list, please forgive me I have used incorrect >> terminology. >> Additional responses interspersed below. >> >> HTH, >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf >> Of scott Ford >> Sent: Tuesday, May 14, 2019 1:35 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LE question >> >> Alan, >> >> Yes that was my thinking. What about persistence ? >> --> "common dataspace" vs. dataspace. >> My question is there a dataspace that can be up without an owning running >> TCB ? >> --> YES >> Even it is require, if memory serves me another program if they need to >> access the dataspace can query for the ALET ? >> --> See recommended reading >> Can someone tell me if i am correct ? >> >> Scott >> >> On Tue, May 14, 2019 at 2:28 PM Allan Staller >> wrote: >> >> > Common Data Space? This is kind of what data spaces were invented for. >> > An init routine to run more or less @ IPL time to create, anchor and >> > load the data space. >> > Cobol to access/update the data via the dataspace Optional routine to >> > save the dataspace @ shutdown. >> > >> > HTH, >> > >> > -Original Message- >> > From: IBM Mainframe Discussion List On >> > Behalf Of scott Ford >> > Sent: Tuesday, May 14, 2019 1:23 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: LE question >> > >> > All: >> > >> > I need to do some research on how job is cancelled via the Operator , >> > Abend S222. I read through some of the Boston share doc of some time >> > ago by Ed, Sam and Skip. Its great. >> > I have a question in regard to something that was stated on the >> > presentation. >> > >> > I have a job written in Cobol, this job has mission critical data >> > storage in a table or array in program storage and that job has been >> > cancelled by an Operator. I dont want to lose that data. >> > I want to know how i should approach it. The other qualifier here is >> > that this is Cobol v4.2 which i am stuck with. >> > >> > Would I have to write a non-LE assembler caller and somehow set and >> > ESPIE or ESTAE and then somehow involve CALLRTM ? >> > I have done a lot of digging and not sure recovery of this nature ( LE >> > ) is mentioned. I understand Condition Handling can be called also but >> > will it handle an Operator cancel ...I know there are products, thats >> > not an option because of cost. >> > >> > Regards, >> > >> > -- >> > >> > >> > >> > *IDMWORKS * >> > >> > Scott Ford >> > >> > z/OS Dev. >> > >> > >> > >> > >> > “By elevating a friend or Collegue you elevate yourself, by demeaning >> > a friend or collegue you demean yourself” >> > >> > >> > >> > >> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com >> > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d6d8 >> > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752619 >> > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dreserv >> > ed=0 >> > >> > scott.f...@idmworks.com >> > >> > Blog: >> > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2 >> > Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769 >> > a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63693455768 >> > 7752619sdata=IvvsMACZMrze2eQUcFI2BYSxbK%2Fw%2BB4U%2B8xIHbFtFYw%3D >> > reserved=0 >> > >> > >> > >> > >> > >> > *The information contained in this email message and any attachment >> > may be privileged, confidential, proprietary or otherwise protected >> > from disclosure. If the reader of this message is not the intended >> > recipient, you are hereby notified that any dissemination, >> > distribution, copying or use of this message and any attachment is >> > strictly prohibited. If you have received this message in error, >> > please notify us immediately by replying to the message and >> > permanently delete it from your computer and destroy any printout >> > thereof.* >> > >> > -- >> > For IBM-MAIN subscribe / signoff / archive access instructions, send >> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >
Re: LE question
Alan, A big thanks ..A Common Dataspace is good , i will have to find how to anchor ..homework. Regards, Scott On Tue, May 14, 2019 at 2:45 PM Allan Staller wrote: > That is why I specified a COMMON data space (as opposed to a data space), > and the init/term routines. > A "data space" has no persistence beyond the creating task. A "common > dataspace" is anchored somewhere in the operating system. > I will leave the details to your perusal of the FM's. > Recommended reading: > SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level > Languages > SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide > > For the pendants on the list, please forgive me I have used incorrect > terminology. > Additional responses interspersed below. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of scott Ford > Sent: Tuesday, May 14, 2019 1:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LE question > > Alan, > > Yes that was my thinking. What about persistence ? > --> "common dataspace" vs. dataspace. > My question is there a dataspace that can be up without an owning running > TCB ? > --> YES > Even it is require, if memory serves me another program if they need to > access the dataspace can query for the ALET ? > --> See recommended reading > Can someone tell me if i am correct ? > > Scott > > On Tue, May 14, 2019 at 2:28 PM Allan Staller > wrote: > > > Common Data Space? This is kind of what data spaces were invented for. > > An init routine to run more or less @ IPL time to create, anchor and > > load the data space. > > Cobol to access/update the data via the dataspace Optional routine to > > save the dataspace @ shutdown. > > > > HTH, > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of scott Ford > > Sent: Tuesday, May 14, 2019 1:23 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: LE question > > > > All: > > > > I need to do some research on how job is cancelled via the Operator , > > Abend S222. I read through some of the Boston share doc of some time > > ago by Ed, Sam and Skip. Its great. > > I have a question in regard to something that was stated on the > > presentation. > > > > I have a job written in Cobol, this job has mission critical data > > storage in a table or array in program storage and that job has been > > cancelled by an Operator. I dont want to lose that data. > > I want to know how i should approach it. The other qualifier here is > > that this is Cobol v4.2 which i am stuck with. > > > > Would I have to write a non-LE assembler caller and somehow set and > > ESPIE or ESTAE and then somehow involve CALLRTM ? > > I have done a lot of digging and not sure recovery of this nature ( LE > > ) is mentioned. I understand Condition Handling can be called also but > > will it handle an Operator cancel ...I know there are products, thats > > not an option because of cost. > > > > Regards, > > > > -- > > > > > > > > *IDMWORKS * > > > > Scott Ford > > > > z/OS Dev. > > > > > > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning > > a friend or collegue you demean yourself” > > > > > > > > > > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com > > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d6d8 > > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752619 > > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dreserv > > ed=0 > > > > scott.f...@idmworks.com > > > > Blog: > > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2 > > Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769 > > a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63693455768 > > 7752619sdata=IvvsMACZMrze2eQUcFI2BYSxbK%2Fw%2BB4U%2B8xIHbFtFYw%3D > > reserved=0 > > > > > > > > > > > > *The information contained in this email message and any attachment > > may be privileged, confidential, proprietary or otherwise protected > > from disclosure. If the reader of this message is not the intended > > recipient, you are hereby notified that any dissemination, > > distribution, copying or use of this message and any attachment is > > strictly prohibited. If you have received this message in error, > > please notify us immediately by replying to the message and > > permanently delete it from your computer and destroy any printout > > thereof.* > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ::DISCLAIMER:: > > > > -- > > -- > > -- > >
Re: z/OS specific commits (was: ... "awk" ...)
On Tue, May 14, 2019 at 12:51 PM Seymour J Metz wrote: > You could charge $1,000 for the modified source but the purchaser would > have the right to give copies away as long as he complied with the license. > Correct. That's likely why nobody has tried it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of John McKown > Sent: Tuesday, May 14, 2019 12:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS specific commits (was: ... "awk" ...) > > On Tue, May 14, 2019 at 11:13 AM Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > On Tue, 14 May 2019 13:58:20 +0800, David Crayford wrote: > > > > >If you've got a C compiler you can build "gawk" yourself. It's already > > >been ported to z/OS and I can see there are z/OS specific commits as > > >recently as a few months ago. > > > > > > > https://secure-web.cisco.com/1uW3-ld0yEsT2HlwUIXZpyCUydLZ008AtCZCHSVSHua5bq_qnuddX_naIBGNKYWD9GCxC01HPDkhCw5cLikz8Lulx-IpJUJZjgUWIAcWJNCXlL21t2w1wthU51k4TvjdSc-T31M2KClean81wToNnQR-juiOYKk3Au7nwolF79q_M66ttyPis_w16Bp5BRBh10FZOY9R3dh14vAzhZR9DfPMCkOD1jGPZZtWS7UOIhk1Xx_DWURdLxaVnc6ZTWw_OaMaWlF7ZJtVETxZGNKt9ZTbhO25UlGG97nVLkvHcR8Wzb_qrgNwqW0YD8o1TaeLiz2A19IftO-gHJA8J-7uDlmTOMjKf6GCirTzhDuIkgohlxXHo02e_o7xIq0ih2Rni/https%3A%2F%2Fgithub.com%2Fredox-os%2Fgawk > > > > > Are the z/OS specific mods to other GNU utilities, mainly by Rocket, > > likewise > > committed to the primary source tree(s), or independent forks? > > > > I understand GPL requires that the source be somehow available. > > > > IIRC, Rocket will supply the source if you request it. It is not, IMO, > easily available because you must ask for it and give Rocket information. > As best as I know, asking for information before supplying source is > allowed by the GPL. That is the "price" for the software. GPL addresses the > right to source (free as in freedom), but does not require that it be > gratis (free as in beer). I just reviewed the license. It does not put any > sort of restriction on the "price" itself. So I guess that I could try > taking some GNU software, modifying it for z/OS, then charge a 1_000_000 > dollars for the modified source. Not that I would. > > > > > > > -- gil > > > > -- > 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 > -- 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: LE question
That is why I specified a COMMON data space (as opposed to a data space), and the init/term routines. A "data space" has no persistence beyond the creating task. A "common dataspace" is anchored somewhere in the operating system. I will leave the details to your perusal of the FM's. Recommended reading: SA23-1377-08 z/OS MVS Programming: Callable Services for High-Level Languages SA23-1394-01 z/OS MVS Programming: Extended Addressability Guide For the pendants on the list, please forgive me I have used incorrect terminology. Additional responses interspersed below. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Tuesday, May 14, 2019 1:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE question Alan, Yes that was my thinking. What about persistence ? --> "common dataspace" vs. dataspace. My question is there a dataspace that can be up without an owning running TCB ? --> YES Even it is require, if memory serves me another program if they need to access the dataspace can query for the ALET ? --> See recommended reading Can someone tell me if i am correct ? Scott On Tue, May 14, 2019 at 2:28 PM Allan Staller wrote: > Common Data Space? This is kind of what data spaces were invented for. > An init routine to run more or less @ IPL time to create, anchor and > load the data space. > Cobol to access/update the data via the dataspace Optional routine to > save the dataspace @ shutdown. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of scott Ford > Sent: Tuesday, May 14, 2019 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: LE question > > All: > > I need to do some research on how job is cancelled via the Operator , > Abend S222. I read through some of the Boston share doc of some time > ago by Ed, Sam and Skip. Its great. > I have a question in regard to something that was stated on the > presentation. > > I have a job written in Cobol, this job has mission critical data > storage in a table or array in program storage and that job has been > cancelled by an Operator. I dont want to lose that data. > I want to know how i should approach it. The other qualifier here is > that this is Cobol v4.2 which i am stuck with. > > Would I have to write a non-LE assembler caller and somehow set and > ESPIE or ESTAE and then somehow involve CALLRTM ? > I have done a lot of digging and not sure recovery of this nature ( LE > ) is mentioned. I understand Condition Handling can be called also but > will it handle an Operator cancel ...I know there are products, thats > not an option because of cost. > > Regards, > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning > a friend or collegue you demean yourself” > > > > > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com > mp;data=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769a08d6d8 > 9b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934557687752619 > sdata=WcUM4%2B0Y5pEl4eXF4pWvUR44qE9d85MMcwEAVS17LH0%3Dreserv > ed=0 > > scott.f...@idmworks.com > > Blog: > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2 > Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C066c2a8677f046e5769 > a08d6d89b0533%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63693455768 > 7752619sdata=IvvsMACZMrze2eQUcFI2BYSxbK%2Fw%2BB4U%2B8xIHbFtFYw%3D > reserved=0 > > > > > > *The information contained in this email message and any attachment > may be privileged, confidential, proprietary or otherwise protected > from disclosure. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, > distribution, copying or use of this message and any attachment is > strictly prohibited. If you have received this message in error, > please notify us immediately by replying to the message and > permanently delete it from your computer and destroy any printout > thereof.* > > -- > 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
Re: LE question
Alan, Yes that was my thinking. What about persistence ? My question is there a dataspace that can be up without an owning running TCB ? Even it is require, if memory serves me another program if they need to access the dataspace can query for the ALET ? Can someone tell me if i am correct ? Scott On Tue, May 14, 2019 at 2:28 PM Allan Staller wrote: > Common Data Space? This is kind of what data spaces were invented for. > An init routine to run more or less @ IPL time to create, anchor and > load the data space. > Cobol to access/update the data via the dataspace > Optional routine to save the dataspace @ shutdown. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of scott Ford > Sent: Tuesday, May 14, 2019 1:23 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: LE question > > All: > > I need to do some research on how job is cancelled via the Operator , > Abend S222. I read through some of the Boston share doc of some time ago by > Ed, Sam and Skip. Its great. > I have a question in regard to something that was stated on the > presentation. > > I have a job written in Cobol, this job has mission critical data storage > in a table or array in program storage and that job has been cancelled by > an Operator. I dont want to lose that data. > I want to know how i should approach it. The other qualifier here is that > this is Cobol v4.2 which i am stuck with. > > Would I have to write a non-LE assembler caller and somehow set and ESPIE > or ESTAE and then somehow involve CALLRTM ? > I have done a lot of digging and not sure recovery of this nature ( LE ) > is mentioned. I understand Condition Handling can be called also but will > it handle an Operator cancel ...I know there are products, thats not an > option because of cost. > > Regards, > > -- > > > > *IDMWORKS * > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.comdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=huczJhFn5eteBZJp2I%2BRNbzzK2MzZVNXbaNkXPFUGXc%3Dreserved=0 > > scott.f...@idmworks.com > > Blog: > https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=V1Ah%2FVAlb9m%2FftOG%2FD8TgXV8DYeSJRNUFUADHBVgjWo%3Dreserved=0 > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from > disclosure. If the reader of this message is not the intended recipient, > you are hereby notified that any dissemination, distribution, copying or > use of this message and any attachment is strictly prohibited. If you have > received this message in error, please notify us immediately by replying to > the message and permanently delete it from your computer and destroy any > printout thereof.* > > -- > 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. > >
Re: mainframe hacking "success stories"?
Reading all of these posts has brought out the salient points of IT security: 1. All the technology in the world won't help you if you don't use it. 2. Stupid people can outwit a capable machine (SET SECURITY OFF). 3. Z security builds on its long history and culture of talented people, effective processes, and robust products. When all are fully engaged, its security mechanisms are really hard to beat. 4. The bad guys have time on their side, often putting the good guys on the defensive. The difference between the two is what protects you. The more places you have those buffers, the better the protection will be. 5. Sometimes obscurity is good. Sometimes not. It depends on what you are hiding and from whom. But don't be upset when your secret is becomes known. It shouldn't be your only defense. 6. When someone possesses valid credentials to a system, only their activities while using them will tell you if they are Good or Evil. This is the weakest part of all system security. Humans are vital to IT security, yet are the weakest link, being both easiest to manipulate and capable of being compromised. (I've seen the movies; retinal scanners won't help.)We try to recognize changes in system behavior to know when something is wrong, yet we pay little attention to human activities. (How to recognize when your Db2 database is being surreptitiously unloaded in small bits over a long period of time.) 7. The "Z" on the box doesn't make it more secure than any other platform (no miracles or magic). It does, however, come with an impressive arsenal that you can use to make it so. I would be comfortable saying that it is "more securable" than any other general purpose platform. That encompasses both the types of security services and the difficulty in subverting them. 8. Prevention is better than detection, but detection lets us know when our preventive measures have failed. 9. Have you done all that is *commercially reasonable* to protect your data and your services? All that is possible may not be reasonable in some contexts, so don't fall into that trap. Understanding your liability (cost of loss) helps you assess "reasonable". 10. Assume that nothing is perfect. (You would be correct.) Bad things happen to good people. If you detect that, in spite of your best attempts, the unthinkable has happened, are you prepared to deal with it competently, calmly, and quickly? Alan Altmark IBM Systems Lab Services z/VM Consultant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE question
Common Data Space? This is kind of what data spaces were invented for. An init routine to run more or less @ IPL time to create, anchor and load the data space. Cobol to access/update the data via the dataspace Optional routine to save the dataspace @ shutdown. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: Tuesday, May 14, 2019 1:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LE question All: I need to do some research on how job is cancelled via the Operator , Abend S222. I read through some of the Boston share doc of some time ago by Ed, Sam and Skip. Its great. I have a question in regard to something that was stated on the presentation. I have a job written in Cobol, this job has mission critical data storage in a table or array in program storage and that job has been cancelled by an Operator. I dont want to lose that data. I want to know how i should approach it. The other qualifier here is that this is Cobol v4.2 which i am stuck with. Would I have to write a non-LE assembler caller and somehow set and ESPIE or ESTAE and then somehow involve CALLRTM ? I have done a lot of digging and not sure recovery of this nature ( LE ) is mentioned. I understand Condition Handling can be called also but will it handle an Operator cancel ...I know there are products, thats not an option because of cost. Regards, -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.comdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=huczJhFn5eteBZJp2I%2BRNbzzK2MzZVNXbaNkXPFUGXc%3Dreserved=0 scott.f...@idmworks.com Blog: https://apc01.safelinks.protection.outlook.com/?url=www.idmworks.com%2Fblogdata=02%7C01%7Callan.staller%40HCL.COM%7C1c14bc4c80bd4afe3c4d08d6d8993b40%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636934550010311268sdata=V1Ah%2FVAlb9m%2FftOG%2FD8TgXV8DYeSJRNUFUADHBVgjWo%3Dreserved=0 *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- 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
LE question
All: I need to do some research on how job is cancelled via the Operator , Abend S222. I read through some of the Boston share doc of some time ago by Ed, Sam and Skip. Its great. I have a question in regard to something that was stated on the presentation. I have a job written in Cobol, this job has mission critical data storage in a table or array in program storage and that job has been cancelled by an Operator. I dont want to lose that data. I want to know how i should approach it. The other qualifier here is that this is Cobol v4.2 which i am stuck with. Would I have to write a non-LE assembler caller and somehow set and ESPIE or ESTAE and then somehow involve CALLRTM ? I have done a lot of digging and not sure recovery of this nature ( LE ) is mentioned. I understand Condition Handling can be called also but will it handle an Operator cancel ...I know there are products, thats not an option because of cost. Regards, -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS specific commits (was: ... "awk" ...)
On Tue, 14 May 2019 11:29:22 -0500, John McKown wrote: >IIRC, Rocket will supply the source if you request it. It is not, IMO, >easily available because you must ask for it and give Rocket information. >As best as I know, asking for information before supplying source is >allowed by the GPL. That is the "price" for the software. GPL addresses the >right to source (free as in freedom), but does not require that it be >gratis (free as in beer). I just reviewed the license. It does not put any >sort of restriction on the "price" itself. So I guess that I could try >taking some GNU software, modifying it for z/OS, then charge a 1_000_000 >dollars for the modified source. Not that I would. I disagree. See part 6 of the GPL v3 " for a price no more than your reasonable cost of physically performing this conveying of source". b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. GPL v1 and GPL v2 have similar clauses. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS specific commits (was: ... "awk" ...)
You could charge $1,000 for the modified source but the purchaser would have the right to give copies away as long as he complied with the license. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Tuesday, May 14, 2019 12:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS specific commits (was: ... "awk" ...) On Tue, May 14, 2019 at 11:13 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 14 May 2019 13:58:20 +0800, David Crayford wrote: > > >If you've got a C compiler you can build "gawk" yourself. It's already > >been ported to z/OS and I can see there are z/OS specific commits as > >recently as a few months ago. > > > >https://secure-web.cisco.com/1uW3-ld0yEsT2HlwUIXZpyCUydLZ008AtCZCHSVSHua5bq_qnuddX_naIBGNKYWD9GCxC01HPDkhCw5cLikz8Lulx-IpJUJZjgUWIAcWJNCXlL21t2w1wthU51k4TvjdSc-T31M2KClean81wToNnQR-juiOYKk3Au7nwolF79q_M66ttyPis_w16Bp5BRBh10FZOY9R3dh14vAzhZR9DfPMCkOD1jGPZZtWS7UOIhk1Xx_DWURdLxaVnc6ZTWw_OaMaWlF7ZJtVETxZGNKt9ZTbhO25UlGG97nVLkvHcR8Wzb_qrgNwqW0YD8o1TaeLiz2A19IftO-gHJA8J-7uDlmTOMjKf6GCirTzhDuIkgohlxXHo02e_o7xIq0ih2Rni/https%3A%2F%2Fgithub.com%2Fredox-os%2Fgawk > > > Are the z/OS specific mods to other GNU utilities, mainly by Rocket, > likewise > committed to the primary source tree(s), or independent forks? > > I understand GPL requires that the source be somehow available. > IIRC, Rocket will supply the source if you request it. It is not, IMO, easily available because you must ask for it and give Rocket information. As best as I know, asking for information before supplying source is allowed by the GPL. That is the "price" for the software. GPL addresses the right to source (free as in freedom), but does not require that it be gratis (free as in beer). I just reviewed the license. It does not put any sort of restriction on the "price" itself. So I guess that I could try taking some GNU software, modifying it for z/OS, then charge a 1_000_000 dollars for the modified source. Not that I would. > > -- gil > -- 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: Concatenating VB and FB ?
SMPE has supported RECFM=VB elements since Old Man Noach cornered the market in Gopher Wood. While access methods don't support PO concatenation of FB and VB, a bit of REXX coding using, e.g., LIBDEF, can greatly alleviate the problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Monday, May 13, 2019 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Concatenating VB and FB ? I've worked for several large, mature shops. Large means many users who need TLC; some will be quite influential within the organization. Mature means lots of processes deeply embedded in the infrastructure; some will be considered Tier 1 production. The problem with FB vs. VB--mostly in script management involving CLIST or REXX--is as old as MVS. For most of affected shops, the conundrum is the reverse of OP's. Vendor distribution is usually FB--SMPE pretty much requires that--while older shops chose *many decades* ago to standardize on VB in order to economize on SLED space and I/O overhead. I have never heard of a generic mechanism to allow FB and VB SYSPROC or SYSEXEC concatenations to coexist transparently. So it usually falls on the sysprog team to convert supplied data sets to the user-expected format. The biggest problem with format conversion is that you have to keep up with vendor updates. That's way more trouble than the original conversion. So if pressure on the vendor gains you nothing, you need to live with the hassle. One technique to simplify life works if you can isolate a product to a particular set of users. For example, SMPE and IPCS are used by sysprogs. You can write an 'INIT' REXX that allocates vendor-supplied data sets--including e.g. REXX of the opposite format--and instruct users to run *your* application. The INIT REXX almost never needs updating; vendor updates everything else. . . 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 Seymour J Metz Sent: Monday, May 13, 2019 8:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Concatenating VB and FB ? Concatenation of FB and VB isn't going to work. I prefer VB, but changing it after the fact is a user hostile move. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tim Hare Sent: Sunday, May 12, 2019 10:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Concatenating VB and FB ? I seem to be finding different answers on this. A vendor used to ship some files as PDSes with RECFM=FB and LRECL=80 (BLKSIZE 23440). User-customized members at this shop were put in a different PDS, with the same attributes, and concatenated in cataloged procedures, ahead of the vendor's libraries. Pretty standard practice I'm sure most are familiar with. Suddenly, because (I'm told) of a merging of code bases at the vendor, their PDSes are now RECFM=VB and LRECL=2044 (BLKSIZE 27998) ! My instincts tell me this isn't going to work well, but with changes in concatenation of libraries over the course of my career I'm not sure.Here's what I think: because of the "new" rule where the largest BLKSIZE sets the buffer size, we'll be OK for reading the blocks (23440 fits into 27998) but when we try to read a member from the VB library, the RDWs are going to mess things up. I have tried searching for the answer, but haven't, apparently, found the right source yet. What say you all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Concatenating VB and FB ?
That's a concatenation of PS datasets, which {B|S]SAM can handle if you set the
unlike attributes bit. For a concatenation of PO you'd need to use EXCP.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Sri
h Kolusu
Sent: Monday, May 13, 2019 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concatenating VB and FB ?
>>Concatenation of FB and VB isn't going to work. I prefer VB, but changing
it after the fact is a user hostile move.
Utilities like File-Manager are quite capable of handling concatenation of
VB with FB datasets. As long as your VB dataset is the first dataset in
concatenation you can copy the copy the contents.
Here is a simple example.
//*
//* CREATE A FB AND VB DATASET USING DFSORT *
//* FB DATASET WILL HAVE THE 1-3 RECORDS *
//* VB DATASET WILL HAVE THE 4-6 RECORDS *
//*
//STEP0100 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD *
ABC
DEF
GHI
JKL
MNO
QRS
//FB DD DSN=&,DISP=(,PASS),SPACE=(CYL,(1,1),RLSE)
//VB DD DSN=&,DISP=(,PASS),SPACE=(CYL,(1,1),RLSE)
//SYSINDD *
OPTION COPY
INREC OVERLAY=(80:1,3,CHANGE=(1,C'ABC',C'A',
C'MNO',C'M'),
NOMATCH=(C' '))
OUTFIL FNAMES=FB,ENDREC=3
OUTFIL FNAMES=VB,FTOV,STARTREC=4,VLTRIM=C' '
//*
//*
//* CONCATENATE A VB AND FB DATASET AND COPY IT TO USING FILEMGR *
//* IF VB DATASET IS CONCATENATED FIRST, THE COPY IS SUCCESSFUL *
//*
//STEP0200 EXEC PGM=FILEMGR
//SYSPRINT DD SYSOUT=*
//DDIN DD DISP=(OLD,PASS),DSN=&
// DD DISP=(OLD,PASS),DSN=&
//DDOUTDD SYSOUT=*
//SYSINDD *
$$FILEM DSC
//*
//*
//* CONCATENATE A FB AND VB DATASET AND COPY IT TO USING FILEMGR *
//* IF FB DATASET IS CONCATENATED FIRST, THE RESULT IS JUST A *
//* COPY OF FB AND ENDS WITH A RETURN CODE OF 16. *
//*
//STEP0300 EXEC PGM=FILEMGR
//SYSPRINT DD SYSOUT=*
//DDIN DD DISP=(OLD,PASS),DSN=&
// DD DISP=(OLD,PASS),DSN=&
//DDOUTDD SYSOUT=*
//SYSINDD *
$$FILEM DSC
//*
The output from step0200 is (VB is concatenated first)
JKL
MNO
M
QRS
ABC
A
DEF
GHI
Relavant messages from File-manager
IBM File Manager for z/OS
$$FILEM DSC
FMNBA377 3 record(s) read from DDIN/SYS19133.T092252.RA000.CONFBVB.VB.H03
FMNBA377 3 record(s) read from DDIN/SYS19133.T092252.RA000.CONFBVB.FB.H03
FMNBB298 6 record(s) copied: 0 truncated: 0 fields truncated
The output from step0300 is (FB is concatenated first)
ABC
A
DEF
GHI
Relevant messages from File-Manager
IBM File Manager for z/OS
$$FILEM DSC
FMNBA377 3 record(s) read from DDIN/SYS19133.T092252.RA000.CONFBVB.FB.H03
FMNBA355 Record size (3) invalid for FIXED,80 output
FMNBA377 1 record(s) read from DDIN/SYS19133.T092252.RA000.CONFBVB.VB.H03
FMNBB441 Copy procedure terminated. 3 rec(s) processed
Thanks,
Kolusu
IBM Corporation
--
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: mainframe hacking "success stories"?
On Tue, 14 May 2019 09:35:42 -0600, Grant Taylor wrote: >On 5/14/19 7:08 AM, Tom Marchant wrote: >> Mildly? > >Yes, "mildly" is the word that I wanted to use. I explained why I chose it. > >> You can leave out the parenthetical "significantly". z machines can >> take a hard failure of a CP and a spare is switched in dynamically >> to take over the work. The unit of work that was running on that >> processor is moved to the new processor without interruption. There is >> a brief pause while it is switched, but the workload is not impacted. >> The operating system does not have to do anything to make this happen. >> It is done entirely in hardware. The failed processor can even be >> running critical operating system functions. It makes no difference. > >Said "brief pause" qualifies as a non-significant impact to me. Hence >the workload was impacted while it was moved from one CP to another. Ummm... That's an interesting way to spin it. How long does it take for the hardware to reassign the currently running program to another CP? Microseconds? Nanoseconds? I don't know. The failing instruction is run on the new processor, followed by all subsequent instructions, until that program is interrupted. > >> Sure, detecting a potential failure situation and responding to that >> should be relatively trivial. >> >> That's the big difference, isn't it? > >Yes, it is a difference. What you said did not indicate to me that the >CPU had faulted. I guess you didn't notice "a hard failure of a CP"? >Rather I took what you said to mean that the CPU had a >cooling problem. Cooling problem? AFAIR, you are the only one who mentioned cooling problems. Nothing that I wrote was remotely related to a cooling problem. zArchitecture systems, and many generations of processor before that, responded to cooling problems in other ways. >That does not mean that the CPU is failed to me. Is >it usable as is? No. Is it spewing errors, shorting something, >otherwise adversely impacting the rest of the system? No. Wow. You have a strange notion of what a machine check means. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E support for UNIX files
Motivated by recent discussion of SMP/E support for UNIX files, I read: SMP/E for z/OS IBM Reference SA23-2276-30 Hierarchical file system element MCS The hierarchical file system element MCSs describe elements located in a UNIX file system. Hierarchical file system elements can have any of the following characteristics: o The record format (RECFM) must be F, FA, FM, FB, FBA, FBM, V, VA, VM, VB, VBA, or VBM. o Elements with variable-length records cannot contain spanned records. o The maximum LRECL is 32,654. o The records can be numbered or unnumbered. WTF!? ROFL! Someone sure talks UNIX with an MVS accent. On Mon, 13 May 2019 10:35:47 -0500, John McKown wrote: >This has made me wonder. One thing I like about UNIX (or Windows) files is >that they don't impose any structure on the data. ... Yeah, right. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO Reconnect ABEND=S622
Thanks, I'll check -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS specific commits (was: ... "awk" ...)
On Tue, May 14, 2019 at 11:13 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 14 May 2019 13:58:20 +0800, David Crayford wrote: > > >If you've got a C compiler you can build "gawk" yourself. It's already > >been ported to z/OS and I can see there are z/OS specific commits as > >recently as a few months ago. > > > >https://github.com/redox-os/gawk > > > Are the z/OS specific mods to other GNU utilities, mainly by Rocket, > likewise > committed to the primary source tree(s), or independent forks? > > I understand GPL requires that the source be somehow available. > IIRC, Rocket will supply the source if you request it. It is not, IMO, easily available because you must ask for it and give Rocket information. As best as I know, asking for information before supplying source is allowed by the GPL. That is the "price" for the software. GPL addresses the right to source (free as in freedom), but does not require that it be gratis (free as in beer). I just reviewed the license. It does not put any sort of restriction on the "price" itself. So I guess that I could try taking some GNU software, modifying it for z/OS, then charge a 1_000_000 dollars for the modified source. Not that I would. > > -- gil > -- 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: CBU expiration and activate dynamic
So to activate another test CBU. Does it require a POR ? On Mon, 13 May, 2019, 6:02 PM Vielka-Lee Heitz, < vielkalee.he...@siriuscom.com> wrote: > CBU test activation is 10 days max for each test. > A CBU REAL ACTIVATION (you are in a DR situation) would be up to 90 days. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter > Sent: Monday, May 13, 2019 5:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CBU expiration and activate dynamic > > Parwez > > I was going through the z14 Zr1 guide . I don't see about grace period for > CBU test Activation. > > I am I missing something ? > > On Mon, 13 May, 2019, 1:38 PM Parwez, wrote: > > > Re grace period. I believe its 2 days. > > > > However, my personal knowledge is a bit rusty now. Try this manual: > > > > z Systems > > Capacity on Demand User's Guide > > SC28-6943-01 > > > > Regards > > > > Parwez Hamid > > > > > > From: IBM Mainframe Discussion List on > > behalf of Peter > > Sent: 13 May 2019 09:14 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: CBU expiration and activate dynamic > > > > Hi > > > > Will there be any grace period before it expires? > > > > On Mon, 13 May, 2019, 12:01 PM Peter, wrote: > > > > > Hi > > > > > > We have activated CBU for our DR site and it remains for 10 days. > > > Now > > This > > > is nearing for expiration. > > > > > > Is it possible to activate another CBU token without IPLing the LPAR > > > ? Is there a way to activate CBU dynamically ? > > > > > > Hardware : z14 zr1 > > > > > > Peter > > > > > > > -- > > 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 > This message (including any attachments) is intended only for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, privileged, confidential, and > exempt from disclosure under applicable law or may constitute as attorney > work product. If you are not the intended recipient, you are hereby > notified that any use, dissemination, distribution, or copying of this > communication is strictly prohibited. If you have received this > communication in error, notify us immediately by telephone and (i) destroy > this message if a facsimile or (ii) delete this message immediately if this > is an electronic communication. Thank you. > > -- > 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: TSO Reconnect ABEND=S622
Different IEFUTL exits? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, May 14, 2019 11:52 AM, Roland Kinsman wrote: > I have two LPARs, each with identical contents in TSOKEY00. They specify > RECONLIM=10. On one of the systems, you can reconnect to an inactive TSO > session after several days of inactivity, I'm not sure how long. On that > LPAR, ABEND=S622 does occur, but not very often. On the other LPAR, > ABEND=S622 is much more frequent, and TSO sessions timeout after around an > hour. I want to change the configuration of the second LPAR to behave like > the first one. Any ideas on where to look for the differences? > > > > 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: Concatenating VB and FB ?
I wouldn’t dispute that the Unix solution works. My issue with this and other suggested solutions is the burden it would place on ordinary users. It has long been customary in the MVS world for each user to logon to TSO with a concatenation of CLIST/EXEC libraries, some supplied by infrastructure, some by the local 'department', and some by the individual user. A 'salable' solution cannot seriously compromise productivity. I support users on two continents. Technical elegance ranks pretty far down the list. . . 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 Paul Gilmartin Sent: Monday, May 13, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Concatenating VB and FB ? On Mon, 13 May 2019 22:12:45 +, Jesse 1 Robinson wrote: >I haven’t researched SMPE on this question for a long time. VB REXX elements >may be legal now. If you have any, that proves your case. > They always have been legal. IIRC, when Rexx first came to TSO/E v2, circa advent of MVS/XA, IBM issued a GIM recommending SYSEXEC have RECFM=VB, no line numbers, and mixed case for legibility. IBM didn't follow its own advice. >OTOH it doesn't matter much because if there is even one each of FB and VB >elements, you still have the same problem with concatenation.. This will not >work: > >//SYSEXEC DD DSN=FB-PDS >// DD DSN=VB-PDS > True, but: //SYSEXEC DD DSN=FB-PDS // DD PATH='UNIX-Directory' and //SYSEXEC DD DSN=VB-PDS // DD PATH='UNIX-Directory' ... both work with the *very*same* UNIX-Directory. A strong argument for using the UNIX filesystem. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS specific commits (was: ... "awk" ...)
On Tue, 14 May 2019 13:58:20 +0800, David Crayford wrote: >If you've got a C compiler you can build "gawk" yourself. It's already >been ported to z/OS and I can see there are z/OS specific commits as >recently as a few months ago. > >https://github.com/redox-os/gawk > Are the z/OS specific mods to other GNU utilities, mainly by Rocket, likewise committed to the primary source tree(s), or independent forks? I understand GPL requires that the source be somehow available. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TSO Reconnect ABEND=S622
I have two LPARs, each with identical contents in TSOKEY00. They specify RECONLIM=10. On one of the systems, you can reconnect to an inactive TSO session after several days of inactivity, I'm not sure how long. On that LPAR, ABEND=S622 does occur, but not very often. On the other LPAR, ABEND=S622 is much more frequent, and TSO sessions timeout after around an hour. I want to change the configuration of the second LPAR to behave like the first one. Any ideas on where to look for the differences? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
On the S/360 the Alternate CPU Recovery facility was limited to 65MP (I don't know about 9020 or TSS/360.) On MVS it was a standard facility, although on an AP or MP without Channel Set Switching losing the processor with the I/O channels was fatal. With MVS/XA and later I/O was more robust. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> Sent: Monday, May 13, 2019 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? On 5/13/19 9:25 AM, Seymour J Metz wrote: > SPARC? I was shocked when I found out that the failure of a sing > processor could bring Solaris down. It really depends on the machine. Some machines are meant to allow processors to fail, be replaced, be added, and brought online while the workload continues. The SPARC Enterprise 1 (Starfire) comes to mind. I suspect that a System 360 would have had major problems if the ""processor failed. Most Open Systems are not designed with the ability for Online Insertion and Removal of components, including processor and memory. Some are. -- Grant. . . . unix || die -- 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: mainframe hacking "success stories"?
On 5/14/19 7:08 AM, Tom Marchant wrote: Mildly? Yes, "mildly" is the word that I wanted to use. I explained why I chose it. You can leave out the parenthetical "significantly". z machines can take a hard failure of a CP and a spare is switched in dynamically to take over the work. The unit of work that was running on that processor is moved to the new processor without interruption. There is a brief pause while it is switched, but the workload is not impacted. The operating system does not have to do anything to make this happen. It is done entirely in hardware. The failed processor can even be running critical operating system functions. It makes no difference. Said "brief pause" qualifies as a non-significant impact to me. Hence the workload was impacted while it was moved from one CP to another. Sure, detecting a potential failure situation and responding to that should be relatively trivial. That's the big difference, isn't it? Yes, it is a difference. What you said did not indicate to me that the CPU had faulted. Rather I took what you said to mean that the CPU had a cooling problem. That does not mean that the CPU is failed to me. Is it usable as is? No. Is it spewing errors, shorting something, otherwise adversely impacting the rest of the system? No. -- Grant. . . . unix || die -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
On Mon, 13 May 2019 21:17:32 -0600, Grant Taylor wrote: >On 5/13/19 9:46 AM, John McKown wrote: >> Yes, we have had a TCM fail. I was almost called a liar when I told the >> Windows people that the z simply switch the work transparently (on the >> hardware level) to another CP. They were shocked and amazed that we >> could "hot swap" a new TCM into the box without any outage. > >TCM as in Thermal Conduction Module? > >IMHO that's mildly impressive. I say /mildly/ because I would /expect/ >a mainframe to be able to survive that without (significantly) impacting >the workload. Mildly? You can leave out the parenthetical "significantly". z machines can take a hard failure of a CP and a spare is switched in dynamically to take over the work. The unit of work that was running on that processor is moved to the new processor without interruption. There is a brief pause while it is switched, but the workload is not impacted. The operating system does not have to do anything to make this happen. It is done entirely in hardware. The failed processor can even be running critical operating system functions. It makes no difference. >I also would like to think that some of the more advanced schedulers in >Linux could detect that a CPU (set of cores) was overheating and needed >to be taken out of service. I would hope that if the chassis was >designed properly, a good CE could replace the TCM without taking the >machine down. Sure, detecting a potential failure situation and responding to that should be relatively trivial. >I'm also assuming that the CPU was not actually faulted and would still >pass sanity checks as long as no actual work was scheduled on it. That's the big difference, isn't it? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?
Clark, The answer to your original question is 'yes'. With regard to FDR, see the following article in our RACF Tips newsletter. https://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__January_2008.pdf Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.twitter.com/RSH_RACF www.rshconsulting.com - Upcoming RSH RACF Training - WebEx - RACF Audit & Compliance Roadmap - SEPT 23-27, 2019 - RACF Level I Administration - DEC 9-13, 2019 - RACF Level II Administration - NOV 18-22, 2019 - RACF Level III Admin, Audit, & Compliance - NOV 4-8, 2019 - RACF - Securing z/OS UNIX - SEPT 9-13, 2019 - -Original Message- Date:Tue, 7 May 2019 09:26:58 -0300 From:Clark Morris Subject: Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"? [Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >In most shops only 2 people have the required access to the RACF database. > Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database and then download the dump of the database? Clark Morris (snip) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
