Re: Where do started PROC errors go?
I haven't had it enough to develop a strong preference, although I found the homemade Slivowitz at DGS to be too sweet for my taste. In fact, before that I had never heard of sweet Slivowitz. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Thursday, May 21, 2020 10:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Hi Slivovitz drinkers, Which brand do you prefer? Regards, David On 2020-05-21 22:39, Jesse 1 Robinson wrote: > It may not be echt, but I like my Slivowitz well iced. > > . > . > 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: Thursday, May 21, 2020 5:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Where do started PROC errors go? > > CAUTION EXTERNAL EMAIL > > I would like a virtual Slivowitz; please don't refrigerate. > > > -- > Shmuel (Seymour J.) Metz > https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C4f2a1a64809b4e98893508d7fdf959a1%7C84df9e7fe9f640afb435%7C1%7C0%7C637257119702470001sdata=%2BqBiUmE7sxszSzZe%2BUnFoJ9cBgEMGvLP8tPz2EGkE7E%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Tom Brennan [t...@tombrennansoftware.com] > Sent: Thursday, May 21, 2020 8:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > Maybe we should all have a six-pack in the fridge that we're not allowed to > touch until someone offers one. > > On 5/21/2020 4:44 PM, Jesse 1 Robinson wrote: >> Sam Virtual Adams. >> >> . >> . >> 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 Charles Mills >> Sent: Thursday, May 21, 2020 4:39 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: (External):Re: Where do started PROC errors go? >> >> CAUTION EXTERNAL EMAIL >> >> It did not but now it does and it works! >> >> Gosh, got it right on the first try. Guessed at the changes to make to the >> below and seem to have gotten them all right on the first try. >> >> I owe you all a virtual beer in Boston. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Wayne Bickerdike >> Sent: Thursday, May 21, 2020 12:52 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Where do started PROC errors go? >> >> Charles did your setup include something like this? >> >> RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) >> PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER >> STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH >> RACLIST(STARTED) >> >> >> -- >> 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: Where do started PROC errors go?
Hi Slivovitz drinkers, Which brand do you prefer? Regards, David On 2020-05-21 22:39, Jesse 1 Robinson wrote: It may not be echt, but I like my Slivowitz well iced. . . 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: Thursday, May 21, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where do started PROC errors go? CAUTION EXTERNAL EMAIL I would like a virtual Slivowitz; please don't refrigerate. -- Shmuel (Seymour J.) Metz https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7C%7C4f2a1a64809b4e98893508d7fdf959a1%7C84df9e7fe9f640afb435%7C1%7C0%7C637257119702470001sdata=%2BqBiUmE7sxszSzZe%2BUnFoJ9cBgEMGvLP8tPz2EGkE7E%3Dreserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Thursday, May 21, 2020 8:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Maybe we should all have a six-pack in the fridge that we're not allowed to touch until someone offers one. On 5/21/2020 4:44 PM, Jesse 1 Robinson wrote: Sam Virtual Adams. . . 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 Charles Mills Sent: Thursday, May 21, 2020 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where do started PROC errors go? CAUTION EXTERNAL EMAIL It did not but now it does and it works! Gosh, got it right on the first try. Guessed at the changes to make to the below and seem to have gotten them all right on the first try. I owe you all a virtual beer in Boston. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Charles did your setup include something like this? RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) -- 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: Where do started PROC errors go?
It may not be echt, but I like my Slivowitz well iced. . . 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: Thursday, May 21, 2020 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where do started PROC errors go? CAUTION EXTERNAL EMAIL I would like a virtual Slivowitz; please don't refrigerate. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Thursday, May 21, 2020 8:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Maybe we should all have a six-pack in the fridge that we're not allowed to touch until someone offers one. On 5/21/2020 4:44 PM, Jesse 1 Robinson wrote: > Sam Virtual Adams. > > . > . > 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 Charles Mills > Sent: Thursday, May 21, 2020 4:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Where do started PROC errors go? > > CAUTION EXTERNAL EMAIL > > It did not but now it does and it works! > > Gosh, got it right on the first try. Guessed at the changes to make to the > below and seem to have gotten them all right on the first try. > > I owe you all a virtual beer in Boston. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 12:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > > -- > 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: Where do started PROC errors go?
Old Peculier for a Yorkshireman :) On Fri, May 22, 2020 at 10:26 AM Seymour J Metz wrote: > I would like a virtual Slivowitz; please don't refrigerate. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Tom Brennan [t...@tombrennansoftware.com] > Sent: Thursday, May 21, 2020 8:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > Maybe we should all have a six-pack in the fridge that we're not allowed > to touch until someone offers one. > > On 5/21/2020 4:44 PM, Jesse 1 Robinson wrote: > > Sam Virtual Adams. > > > > . > > . > > 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 Charles Mills > > Sent: Thursday, May 21, 2020 4:39 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Where do started PROC errors go? > > > > CAUTION EXTERNAL EMAIL > > > > It did not but now it does and it works! > > > > Gosh, got it right on the first try. Guessed at the changes to make to > the below and seem to have gotten them all right on the first try. > > > > I owe you all a virtual beer in Boston. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Wayne Bickerdike > > Sent: Thursday, May 21, 2020 12:52 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Where do started PROC errors go? > > > > Charles did your setup include something like this? > > > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > > > > > -- > > 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 > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
I would like a virtual Slivowitz; please don't refrigerate. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Thursday, May 21, 2020 8:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Maybe we should all have a six-pack in the fridge that we're not allowed to touch until someone offers one. On 5/21/2020 4:44 PM, Jesse 1 Robinson wrote: > Sam Virtual Adams. > > . > . > 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 > Charles Mills > Sent: Thursday, May 21, 2020 4:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Where do started PROC errors go? > > CAUTION EXTERNAL EMAIL > > It did not but now it does and it works! > > Gosh, got it right on the first try. Guessed at the changes to make to the > below and seem to have gotten them all right on the first try. > > I owe you all a virtual beer in Boston. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 12:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT > MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED > MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) > > > -- > 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: Where do started PROC errors go?
Maybe we should all have a six-pack in the fridge that we're not allowed to touch until someone offers one. On 5/21/2020 4:44 PM, Jesse 1 Robinson wrote: Sam Virtual Adams. . . 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 Charles Mills Sent: Thursday, May 21, 2020 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where do started PROC errors go? CAUTION EXTERNAL EMAIL It did not but now it does and it works! Gosh, got it right on the first try. Guessed at the changes to make to the below and seem to have gotten them all right on the first try. I owe you all a virtual beer in Boston. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Charles did your setup include something like this? RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) -- 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: Where do started PROC errors go?
Yep, and different OUTCLASS's. So either the doc. is wrong (or misread) or something stepped in and changed the disposition. Either way, it's ALL still on the spool until all the out groups are purged (not considering the effects of SPIN). First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 7:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] It's all there in ST: DDNAME StepName ProcStep DSID OwnerC Dest Rec-Cnt JESJCLIN 1 K 2 JESMSGLG JES2 2 K LOCAL6 JESJCL JES2 3 K LOCAL 18 JESYSMSG JES2 4 K LOCAL 20 $INTTEXT JES2 5 A 7 SYSTSPRT QMONITOR 101 H LOCAL 34 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jackson, Rob Sent: Thursday, May 21, 2020 3:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Ah, I was looking at a mushed-up email, and it was hard to see all of it. And yeah, the Init and Tuning reference seems to say what you suggest. All I know is when it doesn't show up in the output or held queue when you expect it to, some part of the output was not purged, so you can see it all in ST. Could it be a report collection product changing it via SSI? We have a bunch of JES2 exits in our shop that change these things; I suppose that's another possibility. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] Doesn't this take precedence: JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jackson, Rob [rwjack...@firsthorizon.com] Sent: Thursday, May 21, 2020 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? He was sending that one SYSOUT to class H; the output class for JOBCLASS(STC) was K. I'm sure K wasn't set to PURGE. And the output doesn't really go away until it ALL goes away. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] I don't understand how it is still there for ST to find. shouldn't JES2 have purged it due to the OUTDISP=(PURGE,HOLD)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List
Re: Where do started PROC errors go?
Sam Virtual Adams. . . 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 Charles Mills Sent: Thursday, May 21, 2020 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where do started PROC errors go? CAUTION EXTERNAL EMAIL It did not but now it does and it works! Gosh, got it right on the first try. Guessed at the changes to make to the below and seem to have gotten them all right on the first try. I owe you all a virtual beer in Boston. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Charles did your setup include something like this? RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
It did not but now it does and it works! Gosh, got it right on the first try. Guessed at the changes to make to the below and seem to have gotten them all right on the first try. I owe you all a virtual beer in Boston. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Charles did your setup include something like this? RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
It's all there in ST: DDNAME StepName ProcStep DSID OwnerC Dest Rec-Cnt JESJCLIN 1 K 2 JESMSGLG JES2 2 K LOCAL6 JESJCL JES2 3 K LOCAL 18 JESYSMSG JES2 4 K LOCAL 20 $INTTEXT JES2 5 A 7 SYSTSPRT QMONITOR 101 H LOCAL 34 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jackson, Rob Sent: Thursday, May 21, 2020 3:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Ah, I was looking at a mushed-up email, and it was hard to see all of it. And yeah, the Init and Tuning reference seems to say what you suggest. All I know is when it doesn't show up in the output or held queue when you expect it to, some part of the output was not purged, so you can see it all in ST. Could it be a report collection product changing it via SSI? We have a bunch of JES2 exits in our shop that change these things; I suppose that's another possibility. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] Doesn't this take precedence: JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jackson, Rob [rwjack...@firsthorizon.com] Sent: Thursday, May 21, 2020 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? He was sending that one SYSOUT to class H; the output class for JOBCLASS(STC) was K. I'm sure K wasn't set to PURGE. And the output doesn't really go away until it ALL goes away. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] I don't understand how it is still there for ST to find. shouldn't JES2 have purged it due to the OUTDISP=(PURGE,HOLD)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Wayne Bickerdike > Sent: Thursday, May 21, 2020
Re: Where do started PROC errors go?
Ah, I was looking at a mushed-up email, and it was hard to see all of it. And yeah, the Init and Tuning reference seems to say what you suggest. All I know is when it doesn't show up in the output or held queue when you expect it to, some part of the output was not purged, so you can see it all in ST. Could it be a report collection product changing it via SSI? We have a bunch of JES2 exits in our shop that change these things; I suppose that's another possibility. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 6:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] Doesn't this take precedence: JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jackson, Rob [rwjack...@firsthorizon.com] Sent: Thursday, May 21, 2020 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? He was sending that one SYSOUT to class H; the output class for JOBCLASS(STC) was K. I'm sure K wasn't set to PURGE. And the output doesn't really go away until it ALL goes away. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] I don't understand how it is still there for ST to find. shouldn't JES2 have purged it due to the OUTDISP=(PURGE,HOLD)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don't click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike > wrote: > > > Two things, no definition for the STC in RACF. > > > > If I have
Re: Where do started PROC errors go?
Doesn't this take precedence: JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jackson, Rob [rwjack...@firsthorizon.com] Sent: Thursday, May 21, 2020 5:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? He was sending that one SYSOUT to class H; the output class for JOBCLASS(STC) was K. I'm sure K wasn't set to PURGE. And the output doesn't really go away until it ALL goes away. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] I don't understand how it is still there for ST to find. shouldn't JES2 have purged it due to the OUTDISP=(PURGE,HOLD)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don't click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike > wrote: > > > Two things, no definition for the STC in RACF. > > > > If I have difficulty diagnosing STC problems, I run them as a job in > > JCL to capture error messages. > > > > > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > > > >> He posted messages showing that the STC ran normally. His primary > >> problem is OUTDISP; once he fixes that we can see whether the > >> userid is causing other problems. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason. > >> gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C8156 > >> 95 > >> bad7c4430c0e0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7 > >> C0 > >> %7C637256875802443954sdata=yrxVy3cUu7HVu23lPvqIkCAxcwCqRQm4GJw > >> wB > >> Ocm9VQ%3Dreserved=0 > >> > >> > >> From: IBM Mainframe Discussion List
z/OSMF & TSS
Does anyone have z/OSMF active using TSS (Top Secret) ? I have been using the "Convert z/OS 2.3 member IZUSEC from RACF to TSS commands". z/OSMF still has problems activating - I would like to see how other sites have setup the ID's IBM requires. My main concern is IZUADMIN. The documentation says to set this up as a profile but z/OSMF uses that ID as a USER. If you prefer you may contact me offline. Thank You *** Disclaimer *** This communication (including all attachments) is solely for the use of the person to whom it is addressed and is a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying is prohibited. If you received this email in error, please immediately delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
He was sending that one SYSOUT to class H; the output class for JOBCLASS(STC) was K. I'm sure K wasn't set to PURGE. And the output doesn't really go away until it ALL goes away. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, May 21, 2020 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [External Email. Exercise caution when clicking links or opening attachments.] I don't understand how it is still there for ST to find. shouldn't JES2 have purged it due to the OUTDISP=(PURGE,HOLD)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don't click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike > wrote: > > > Two things, no definition for the STC in RACF. > > > > If I have difficulty diagnosing STC problems, I run them as a job in > > JCL to capture error messages. > > > > > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > > > >> He posted messages showing that the STC ran normally. His primary > >> problem is OUTDISP; once he fixes that we can see whether the > >> userid is causing other problems. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason. > >> gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C8156 > >> 95 > >> bad7c4430c0e0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7 > >> C0 > >> %7C637256875802443954sdata=yrxVy3cUu7HVu23lPvqIkCAxcwCqRQm4GJw > >> wB > >> Ocm9VQ%3Dreserved=0 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >> behalf of Christopher Y. Blaicher [cblaic...@syncsort.com] > >> Sent: Thursday, May 21, 2020 2:48 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> Generally the job name is the name of the PROC you issued the start for. > >> Have you tried using the ST option of SDSF? Also, some errors get > >> put on the bottom of the queue. Also, did you look in the SYSLOG? > >> You should see the start and end messages > >> > >> Chris Blaicher > >> Technical Architect > >> Syncsort, Inc. > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List > >> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen > >> Sent: Thursday, May 21, 2020 2:38 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> [ External - This message originated Externally. Use proper > >> judgement and caution with attachments, links, or responses. ] > >> > >> Try running the PROC in a batch job. > >> > >> You do realize that without proper setup the STC is probably using > >> a different userid. > >> > >> On Thu, 21 May 2020 09:11:10 -0700 Charles Mills > >> wrote: > >> > >> :>I have a program that runs successfully in a job. I just cloned > >> the JCL :>appropriately into a PROC. When I issue a START for the > >> PROC I get a started :>message and an ended message but no clue as > >> to why it failed. (It is :>supposed to be long-running, so ending > >> is a > >> failure.) I don't think it is a :>JCL error because I get a JCL >
Re: Where do started PROC errors go?
I don't understand how it is still there for ST to find. shouldn't JES2 have purged it due to the OUTDISP=(PURGE,HOLD)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike > wrote: > > > Two things, no definition for the STC in RACF. > > > > If I have difficulty diagnosing STC problems, I run them as a job in > > JCL to capture error messages. > > > > > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > > > >> He posted messages showing that the STC ran normally. His primary > >> problem is OUTDISP; once he fixes that we can see whether the userid > >> is causing other problems. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason. > >> gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C815695 > >> bad7c4430c0e0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0 > >> %7C637256875802443954sdata=yrxVy3cUu7HVu23lPvqIkCAxcwCqRQm4GJwwB > >> Ocm9VQ%3Dreserved=0 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >> behalf of Christopher Y. Blaicher [cblaic...@syncsort.com] > >> Sent: Thursday, May 21, 2020 2:48 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> Generally the job name is the name of the PROC you issued the start for. > >> Have you tried using the ST option of SDSF? Also, some errors get > >> put on the bottom of the queue. Also, did you look in the SYSLOG? > >> You should see the start and end messages > >> > >> Chris Blaicher > >> Technical Architect > >> Syncsort, Inc. > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Binyamin Dissen > >> Sent: Thursday, May 21, 2020 2:38 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> [ External - This message originated Externally. Use proper > >> judgement and caution with attachments, links, or responses. ] > >> > >> Try running the PROC in a batch job. > >> > >> You do realize that without proper setup the STC is probably using a > >> different userid. > >> > >> On Thu, 21 May 2020 09:11:10 -0700 Charles Mills > >> wrote: > >> > >> :>I have a program that runs successfully in a job. I just cloned the > >> JCL :>appropriately into a PROC. When I issue a START for the PROC I > >> get a started :>message and an ended message but no clue as to why it > >> failed. (It is :>supposed to be long-running, so ending is a > >> failure.) I don't think it is a :>JCL error because I get a JCL error > >> message in that case, and I have :>evidence that it actually ran "some." > >> :> > >> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I > >> have strong :>evidence that the program is getting far enough that it > >> would have written :>several lines to SYSTSPRT. > >> :> > >> :>I see nothing in SDSF, even with PREFIX * and OWNER *. > >> :> > >> :>Where is my output going? How do I determine that? How do I view it? > >> :> > >> :>There is nothing in the PROC statement: //procname PROC and no > >> operands on :>the START other than
Re: [External] Re: What crashing COBOL systems reveal about applications maintenance -- GCN
We found higher CPU was generally down to the new version of LE routines. COBOL itself was not found to be an issue CPU-wise, although there was only limited comparative testing done. On Thu, 21 May 2020 at 13:48, Pommier, Rex wrote: > OPT(0) burns that much more CPU? Is this on all compiles or many or just > a few of them? If compiles are that bad using OPT(0), what will an OPT(2) > do? We're just starting our install of 6.3, going from 4.2 and this sounds > like something we need to be aware of. > > Thanks, > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of ste...@copper.net > Sent: Wednesday, May 20, 2020 5:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: What crashing COBOL systems reveal about > applications maintenance -- GCN > > We setup for OPT(1) because IBM said that was the thing to do initially. > > We’ve only recently been told to go OPT(2). > > We’ve also run into an interesting issue of COBOL 6.2 compiles using > OPT(0) taking > 10x CPU of same compile with 4.2. > > I don’t recall being told that we would see that level of CPU burn for > planning for capacity for migrating to 6.2. > > Regards > Steve Thompson > > --- frank.swarbr...@outlook.com wrote: > > From: Frank Swarbrick > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] What crashing COBOL systems reveal about > applications maintenance -- GCN > Date: Wed, 20 May 2020 21:28:33 + > > We use OPT(1). Probably for no good reason. (And it was my decision, > meaning its easy enough to change!) > > > From: IBM Mainframe Discussion List on behalf > of Tom Ross > Sent: Wednesday, May 20, 2020 3:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What crashing COBOL systems reveal about applications > maintenance -- GCN > > >Suppose that they took a group of programmers and got the production > >online= programs to all compile with COBOL 6.2 and OPT(1). Would they > >see a signif= icant reduction in MSUs? Assuming they are running on z14s > minimally? > > I sure hope no one is using OPT(1) with 3rd generation COBOL! IBM expects > all users to compile with OPT(2) for production performance. I am honestly > not sure why we shipped OPT(1). Users should use OPT(0) if they want more > straight-forward debugging (no optimizations) and then after unit test > compile with OPT(2) for performance, and and never use OPT(1). > Alternatively, they could compile with OPT(2) for debugging and get used to > odd things like statements getting moved or deleted while debugging. > > Cheers, > TomR >> COBOL is the Language of the Future! << > > -- > 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 > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
Thanks all! - Yes, SDSF ST finds it. Why is it visible in ST but not in H or O? - Problem is the lack of a userid. I will get that fixed up. Back here if I hit something else I cannot solve. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 1:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike > wrote: > > > Two things, no definition for the STC in RACF. > > > > If I have difficulty diagnosing STC problems, I run them as a job in > > JCL to capture error messages. > > > > > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > > > >> He posted messages showing that the STC ran normally. His primary > >> problem is OUTDISP; once he fixes that we can see whether the userid > >> is causing other problems. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason. > >> gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C815695 > >> bad7c4430c0e0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0 > >> %7C637256875802443954sdata=yrxVy3cUu7HVu23lPvqIkCAxcwCqRQm4GJwwB > >> Ocm9VQ%3Dreserved=0 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >> behalf of Christopher Y. Blaicher [cblaic...@syncsort.com] > >> Sent: Thursday, May 21, 2020 2:48 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> Generally the job name is the name of the PROC you issued the start for. > >> Have you tried using the ST option of SDSF? Also, some errors get > >> put on the bottom of the queue. Also, did you look in the SYSLOG? > >> You should see the start and end messages > >> > >> Chris Blaicher > >> Technical Architect > >> Syncsort, Inc. > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Binyamin Dissen > >> Sent: Thursday, May 21, 2020 2:38 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> [ External - This message originated Externally. Use proper > >> judgement and caution with attachments, links, or responses. ] > >> > >> Try running the PROC in a batch job. > >> > >> You do realize that without proper setup the STC is probably using a > >> different userid. > >> > >> On Thu, 21 May 2020 09:11:10 -0700 Charles Mills > >> wrote: > >> > >> :>I have a program that runs successfully in a job. I just cloned the > >> JCL :>appropriately into a PROC. When I issue a START for the PROC I > >> get a started :>message and an ended message but no clue as to why it > >> failed. (It is :>supposed to be long-running, so ending is a > >> failure.) I don't think it is a :>JCL error because I get a JCL error > >> message in that case, and I have :>evidence that it actually ran "some." > >> :> > >> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I > >> have strong :>evidence that the program is getting far enough that it > >> would have written :>several lines to SYSTSPRT. > >> :> > >> :>I see nothing in SDSF, even with PREFIX * and OWNER *. > >> :> > >> :>Where is my output going? How do I determine that? How do I view it? > >> :> > >> :>There is nothing in the PROC statement: //procname PROC and no > >> operands on :>the START other than the PROC name. The program is > >> IKJEFT01 and a Rexx EXEC :>FWIW. Again, it works in a job. > >> :> > >> :>Thanks, > >> :>Charles > >> > >> -- > >> Binyamin Dissen > >> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl > >> defense.com%2Fv3%2F__http%3A%2F%2Fwww.dissensoftware.com__%3B!!I6-MEf > >> EZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_Z > >>
Re: Where do started PROC errors go?
Bingo Allan. If I have a jobcard, I'll use MSGCLASS=X and in the SYSOUT SYSOUT=* Same JCL in an STC and SYSOUT=* does indeed disappear goes to a different (disappearing class) On Fri, May 22, 2020 at 6:11 AM Allan Staller wrote: > S STCNAME...MSGCLASS=(held sysout class). > > I.e. ODISP=(keep,keep) > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Wayne Bickerdike > Sent: Thursday, May 21, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > Charles did your setup include something like this? > > RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) > PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER > STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH > RACLIST(STARTED) > > On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike > wrote: > > > Two things, no definition for the STC in RACF. > > > > If I have difficulty diagnosing STC problems, I run them as a job in > > JCL to capture error messages. > > > > > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > > > >> He posted messages showing that the STC ran normally. His primary > >> problem is OUTDISP; once he fixes that we can see whether the userid > >> is causing other problems. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason. > >> gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C815695 > >> bad7c4430c0e0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0 > >> %7C637256875802443954sdata=yrxVy3cUu7HVu23lPvqIkCAxcwCqRQm4GJwwB > >> Ocm9VQ%3Dreserved=0 > >> > >> > >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > >> behalf of Christopher Y. Blaicher [cblaic...@syncsort.com] > >> Sent: Thursday, May 21, 2020 2:48 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> Generally the job name is the name of the PROC you issued the start for. > >> Have you tried using the ST option of SDSF? Also, some errors get > >> put on the bottom of the queue. Also, did you look in the SYSLOG? > >> You should see the start and end messages > >> > >> Chris Blaicher > >> Technical Architect > >> Syncsort, Inc. > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >> On Behalf Of Binyamin Dissen > >> Sent: Thursday, May 21, 2020 2:38 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Where do started PROC errors go? > >> > >> [ External - This message originated Externally. Use proper > >> judgement and caution with attachments, links, or responses. ] > >> > >> Try running the PROC in a batch job. > >> > >> You do realize that without proper setup the STC is probably using a > >> different userid. > >> > >> On Thu, 21 May 2020 09:11:10 -0700 Charles Mills > >> wrote: > >> > >> :>I have a program that runs successfully in a job. I just cloned the > >> JCL :>appropriately into a PROC. When I issue a START for the PROC I > >> get a started :>message and an ended message but no clue as to why it > >> failed. (It is :>supposed to be long-running, so ending is a > >> failure.) I don't think it is a :>JCL error because I get a JCL error > >> message in that case, and I have :>evidence that it actually ran "some." > >> :> > >> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I > >> have strong :>evidence that the program is getting far enough that it > >> would have written :>several lines to SYSTSPRT. > >> :> > >> :>I see nothing in SDSF, even with PREFIX * and OWNER *. > >> :> > >> :>Where is my output going? How do I determine that? How do I view it? > >> :> > >> :>There is nothing in the PROC statement: //procname PROC and no > >> operands on :>the START other than the PROC name. The program is > >> IKJEFT01 and a Rexx EXEC :>FWIW. Again, it works in a job. > >> :> > >> :>Thanks, > >> :>Charles > >> > >> -- > >> Binyamin Dissen > >> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl > >> defense.com%2Fv3%2F__http%3A%2F%2Fwww.dissensoftware.com__%3B!!I6-MEf > >> EZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_Z > >> uA%24data=02%7C01%7Callan.staller%40HCL.COM%7C815695bad7c4430c0e > >> 0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637256875 > >> 802443954sdata=NSfQ%2FMbui1Nb9ExxAsuil0npRskyp%2BoKBhBN%2BCsq8j8 > >> %3Dreserved=0 > >> > >> 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
Re: Where do started PROC errors go?
S STCNAME...MSGCLASS=(held sysout class). I.e. ODISP=(keep,keep) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Wayne Bickerdike Sent: Thursday, May 21, 2020 2:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Charles did your setup include something like this? RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike wrote: > Two things, no definition for the STC in RACF. > > If I have difficulty diagnosing STC problems, I run them as a job in > JCL to capture error messages. > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > >> He posted messages showing that the STC ran normally. His primary >> problem is OUTDISP; once he fixes that we can see whether the userid >> is causing other problems. >> >> >> -- >> Shmuel (Seymour J.) Metz >> https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason. >> gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C815695 >> bad7c4430c0e0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0 >> %7C637256875802443954sdata=yrxVy3cUu7HVu23lPvqIkCAxcwCqRQm4GJwwB >> Ocm9VQ%3Dreserved=0 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of Christopher Y. Blaicher [cblaic...@syncsort.com] >> Sent: Thursday, May 21, 2020 2:48 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Where do started PROC errors go? >> >> Generally the job name is the name of the PROC you issued the start for. >> Have you tried using the ST option of SDSF? Also, some errors get >> put on the bottom of the queue. Also, did you look in the SYSLOG? >> You should see the start and end messages >> >> Chris Blaicher >> Technical Architect >> Syncsort, Inc. >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Binyamin Dissen >> Sent: Thursday, May 21, 2020 2:38 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Where do started PROC errors go? >> >> [ External - This message originated Externally. Use proper >> judgement and caution with attachments, links, or responses. ] >> >> Try running the PROC in a batch job. >> >> You do realize that without proper setup the STC is probably using a >> different userid. >> >> On Thu, 21 May 2020 09:11:10 -0700 Charles Mills >> wrote: >> >> :>I have a program that runs successfully in a job. I just cloned the >> JCL :>appropriately into a PROC. When I issue a START for the PROC I >> get a started :>message and an ended message but no clue as to why it >> failed. (It is :>supposed to be long-running, so ending is a >> failure.) I don't think it is a :>JCL error because I get a JCL error >> message in that case, and I have :>evidence that it actually ran "some." >> :> >> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I >> have strong :>evidence that the program is getting far enough that it >> would have written :>several lines to SYSTSPRT. >> :> >> :>I see nothing in SDSF, even with PREFIX * and OWNER *. >> :> >> :>Where is my output going? How do I determine that? How do I view it? >> :> >> :>There is nothing in the PROC statement: //procname PROC and no >> operands on :>the START other than the PROC name. The program is >> IKJEFT01 and a Rexx EXEC :>FWIW. Again, it works in a job. >> :> >> :>Thanks, >> :>Charles >> >> -- >> Binyamin Dissen >> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl >> defense.com%2Fv3%2F__http%3A%2F%2Fwww.dissensoftware.com__%3B!!I6-MEf >> EZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_Z >> uA%24data=02%7C01%7Callan.staller%40HCL.COM%7C815695bad7c4430c0e >> 0e08d7fdc08e1f%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637256875 >> 802443954sdata=NSfQ%2FMbui1Nb9ExxAsuil0npRskyp%2BoKBhBN%2BCsq8j8 >> %3Dreserved=0 >> >> Director, Dissen Software, Bar & Grill - Israel >> >> >> Should you use the mailblocks package and expect a response from me, >> you should preauthorize the dissensoftware.com domain. >> >> I very rarely bother responding to challenge/response systems, >> especially those from irresponsible companies. >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to
Re: Where do started PROC errors go?
I don't know whether he is doing anyhing that requires authorization. What I do know is that he won't see his output unless he changes or overrides his OUTDISP. OTOH, it's certainly cleaner to assign an appropriate userid to every started task. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Wayne Bickerdike [wayn...@gmail.com] Sent: Thursday, May 21, 2020 3:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Two things, no definition for the STC in RACF. If I have difficulty diagnosing STC problems, I run them as a job in JCL to capture error messages. On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > He posted messages showing that the STC ran normally. His primary problem > is OUTDISP; once he fixes that we can see whether the userid is causing > other problems. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Christopher Y. Blaicher [cblaic...@syncsort.com] > Sent: Thursday, May 21, 2020 2:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > Generally the job name is the name of the PROC you issued the start for. > Have you tried using the ST option of SDSF? Also, some errors get put on > the bottom of the queue. Also, did you look in the SYSLOG? You should see > the start and end messages > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Binyamin Dissen > Sent: Thursday, May 21, 2020 2:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [ External - This message originated Externally. Use proper judgement and > caution with attachments, links, or responses. ] > > Try running the PROC in a batch job. > > You do realize that without proper setup the STC is probably using a > different userid. > > On Thu, 21 May 2020 09:11:10 -0700 Charles Mills wrote: > > :>I have a program that runs successfully in a job. I just cloned the JCL > :>appropriately into a PROC. When I issue a START for the PROC I get a > started :>message and an ended message but no clue as to why it failed. (It > is :>supposed to be long-running, so ending is a failure.) I don't think it > is a :>JCL error because I get a JCL error message in that case, and I have > :>evidence that it actually ran "some." > :> > :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have > strong :>evidence that the program is getting far enough that it would have > written :>several lines to SYSTSPRT. > :> > :>I see nothing in SDSF, even with PREFIX * and OWNER *. > :> > :>Where is my output going? How do I determine that? How do I view it? > :> > :>There is nothing in the PROC statement: //procname PROC and no operands > on :>the START other than the PROC name. The program is IKJEFT01 and a Rexx > EXEC :>FWIW. Again, it works in a job. > :> > :>Thanks, > :>Charles > > -- > Binyamin Dissen > https://urldefense.com/v3/__http://www.dissensoftware.com__;!!I6-MEfEZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_ZuA$ > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, you > should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, especially > those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- 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: Where do started PROC errors go?
Charles did your setup include something like this? RDEFINE STARTED MYSTC.* OWNER(SYS1) AUDIT(FAILURES(READ)) UACC(NONE) PERMIT MYSTC.* CLASS(STARTED) GENERIC ID(WAYNE) ACCESS(ALTER) RALTER STARTED MYSTC.* STDATA(USER(STCOPER) GROUP(GROUPZ)) SETROPTS REFRESH RACLIST(STARTED) On Fri, May 22, 2020 at 5:33 AM Wayne Bickerdike wrote: > Two things, no definition for the STC in RACF. > > If I have difficulty diagnosing STC problems, I run them as a job in JCL > to capture error messages. > > > > On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > >> He posted messages showing that the STC ran normally. His primary problem >> is OUTDISP; once he fixes that we can see whether the userid is causing >> other problems. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Christopher Y. Blaicher [cblaic...@syncsort.com] >> Sent: Thursday, May 21, 2020 2:48 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Where do started PROC errors go? >> >> Generally the job name is the name of the PROC you issued the start for. >> Have you tried using the ST option of SDSF? Also, some errors get put on >> the bottom of the queue. Also, did you look in the SYSLOG? You should see >> the start and end messages >> >> Chris Blaicher >> Technical Architect >> Syncsort, Inc. >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Binyamin Dissen >> Sent: Thursday, May 21, 2020 2:38 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Where do started PROC errors go? >> >> [ External - This message originated Externally. Use proper judgement >> and caution with attachments, links, or responses. ] >> >> Try running the PROC in a batch job. >> >> You do realize that without proper setup the STC is probably using a >> different userid. >> >> On Thu, 21 May 2020 09:11:10 -0700 Charles Mills >> wrote: >> >> :>I have a program that runs successfully in a job. I just cloned the JCL >> :>appropriately into a PROC. When I issue a START for the PROC I get a >> started :>message and an ended message but no clue as to why it failed. (It >> is :>supposed to be long-running, so ending is a failure.) I don't think it >> is a :>JCL error because I get a JCL error message in that case, and I have >> :>evidence that it actually ran "some." >> :> >> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have >> strong :>evidence that the program is getting far enough that it would have >> written :>several lines to SYSTSPRT. >> :> >> :>I see nothing in SDSF, even with PREFIX * and OWNER *. >> :> >> :>Where is my output going? How do I determine that? How do I view it? >> :> >> :>There is nothing in the PROC statement: //procname PROC and no operands >> on :>the START other than the PROC name. The program is IKJEFT01 and a Rexx >> EXEC :>FWIW. Again, it works in a job. >> :> >> :>Thanks, >> :>Charles >> >> -- >> Binyamin Dissen >> https://urldefense.com/v3/__http://www.dissensoftware.com__;!!I6-MEfEZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_ZuA$ >> >> Director, Dissen Software, Bar & Grill - Israel >> >> >> Should you use the mailblocks package and expect a response from me, you >> should preauthorize the dissensoftware.com domain. >> >> I very rarely bother responding to challenge/response systems, especially >> those from irresponsible companies. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > -- > Wayne V. Bickerdike > > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
Two things, no definition for the STC in RACF. If I have difficulty diagnosing STC problems, I run them as a job in JCL to capture error messages. On Fri, May 22, 2020 at 5:14 AM Seymour J Metz wrote: > He posted messages showing that the STC ran normally. His primary problem > is OUTDISP; once he fixes that we can see whether the userid is causing > other problems. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Christopher Y. Blaicher [cblaic...@syncsort.com] > Sent: Thursday, May 21, 2020 2:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > Generally the job name is the name of the PROC you issued the start for. > Have you tried using the ST option of SDSF? Also, some errors get put on > the bottom of the queue. Also, did you look in the SYSLOG? You should see > the start and end messages > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Binyamin Dissen > Sent: Thursday, May 21, 2020 2:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where do started PROC errors go? > > [ External - This message originated Externally. Use proper judgement and > caution with attachments, links, or responses. ] > > Try running the PROC in a batch job. > > You do realize that without proper setup the STC is probably using a > different userid. > > On Thu, 21 May 2020 09:11:10 -0700 Charles Mills wrote: > > :>I have a program that runs successfully in a job. I just cloned the JCL > :>appropriately into a PROC. When I issue a START for the PROC I get a > started :>message and an ended message but no clue as to why it failed. (It > is :>supposed to be long-running, so ending is a failure.) I don't think it > is a :>JCL error because I get a JCL error message in that case, and I have > :>evidence that it actually ran "some." > :> > :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have > strong :>evidence that the program is getting far enough that it would have > written :>several lines to SYSTSPRT. > :> > :>I see nothing in SDSF, even with PREFIX * and OWNER *. > :> > :>Where is my output going? How do I determine that? How do I view it? > :> > :>There is nothing in the PROC statement: //procname PROC and no operands > on :>the START other than the PROC name. The program is IKJEFT01 and a Rexx > EXEC :>FWIW. Again, it works in a job. > :> > :>Thanks, > :>Charles > > -- > Binyamin Dissen > https://urldefense.com/v3/__http://www.dissensoftware.com__;!!I6-MEfEZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_ZuA$ > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, you > should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, especially > those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
He posted messages showing that the STC ran normally. His primary problem is OUTDISP; once he fixes that we can see whether the userid is causing other problems. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Christopher Y. Blaicher [cblaic...@syncsort.com] Sent: Thursday, May 21, 2020 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? Generally the job name is the name of the PROC you issued the start for. Have you tried using the ST option of SDSF? Also, some errors get put on the bottom of the queue. Also, did you look in the SYSLOG? You should see the start and end messages Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Thursday, May 21, 2020 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [ External - This message originated Externally. Use proper judgement and caution with attachments, links, or responses. ] Try running the PROC in a batch job. You do realize that without proper setup the STC is probably using a different userid. On Thu, 21 May 2020 09:11:10 -0700 Charles Mills wrote: :>I have a program that runs successfully in a job. I just cloned the JCL :>appropriately into a PROC. When I issue a START for the PROC I get a started :>message and an ended message but no clue as to why it failed. (It is :>supposed to be long-running, so ending is a failure.) I don't think it is a :>JCL error because I get a JCL error message in that case, and I have :>evidence that it actually ran "some." :> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong :>evidence that the program is getting far enough that it would have written :>several lines to SYSTSPRT. :> :>I see nothing in SDSF, even with PREFIX * and OWNER *. :> :>Where is my output going? How do I determine that? How do I view it? :> :>There is nothing in the PROC statement: //procname PROC and no operands on :>the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC :>FWIW. Again, it works in a job. :> :>Thanks, :>Charles -- Binyamin Dissen https://urldefense.com/v3/__http://www.dissensoftware.com__;!!I6-MEfEZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_ZuA$ Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
Check the JES2 INIT Deck for the STCCLAS and see what it has for DISP. Next, if there is a SYSOUT Repository ($avers for example) maybe all output from the STC will be in there If you have a JCL Scan utility (Like JCLPLUS) then scan the JCS All else, slap a job card on it with TYPRUN=SCAN and see what that says. Sometimes in SDSF a ST function can find the output you cannot see Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- 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: IODF Activation Question - Followup
Thanks all. Sounds like good plan to me. 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 Thursday, May 21, 2020 2:55 PM, Chuck Kreiter wrote: > I used to manage 4 monoplexes on the same CEC. That's how I did my updates. > Activate on one monoplex and copy the IODF to the others and activate soft. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mark Jacobs > Sent: Thursday, May 21, 2020 2:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IODF Activation Question - Followup > > I have a followup question on this topic. In addition to the 8 z/OS systems > in the sysplex, we have several standalone monoplex z/OS systems on the same > CEC. If I perform the HCD work in the sysplex, then transfer the IODF file to > one of the standalone systems, perform a software and hardware activation > there, will the IODF tokens match between the hardware and software in the > members in the sysplex once they're all IPLed with the new IODF? > > My goal is to keep everything in sync without needing a POR of the processor. > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > -- > > 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: IODF Activation Question - Followup
I used to manage 4 monoplexes on the same CEC. That's how I did my updates. Activate on one monoplex and copy the IODF to the others and activate soft. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Thursday, May 21, 2020 2:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IODF Activation Question - Followup I have a followup question on this topic. In addition to the 8 z/OS systems in the sysplex, we have several standalone monoplex z/OS systems on the same CEC. If I perform the HCD work in the sysplex, then transfer the IODF file to one of the standalone systems, perform a software and hardware activation there, will the IODF tokens match between the hardware and software in the members in the sysplex once they're all IPLed with the new IODF? My goal is to keep everything in sync without needing a POR of the processor. Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- 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: Where do started PROC errors go?
Generally the job name is the name of the PROC you issued the start for. Have you tried using the ST option of SDSF? Also, some errors get put on the bottom of the queue. Also, did you look in the SYSLOG? You should see the start and end messages Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Thursday, May 21, 2020 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where do started PROC errors go? [ External - This message originated Externally. Use proper judgement and caution with attachments, links, or responses. ] Try running the PROC in a batch job. You do realize that without proper setup the STC is probably using a different userid. On Thu, 21 May 2020 09:11:10 -0700 Charles Mills wrote: :>I have a program that runs successfully in a job. I just cloned the JCL :>appropriately into a PROC. When I issue a START for the PROC I get a started :>message and an ended message but no clue as to why it failed. (It is :>supposed to be long-running, so ending is a failure.) I don't think it is a :>JCL error because I get a JCL error message in that case, and I have :>evidence that it actually ran "some." :> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong :>evidence that the program is getting far enough that it would have written :>several lines to SYSTSPRT. :> :>I see nothing in SDSF, even with PREFIX * and OWNER *. :> :>Where is my output going? How do I determine that? How do I view it? :> :>There is nothing in the PROC statement: //procname PROC and no operands on :>the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC :>FWIW. Again, it works in a job. :> :>Thanks, :>Charles -- Binyamin Dissen https://urldefense.com/v3/__http://www.dissensoftware.com__;!!I6-MEfEZPA!YOjsBluCmNaipeBYZjqxb7U9D_dMSn_ENJK4MNP5J_cc5ogXo4k6DoI05UXVcc_ZuA$ Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IODF Activation Question - Followup
that's sounds reasonable, I can't honestly say yes, my IODF contains the configuration for both the PROD CEC and the DR CEC, so I don't need to transfer it, via export,import. but since I have a rescue system I can IPL on the DR box, an IPL, then an activation works for me and both hw and sw are sync'd up. Carmen Vitullo - Original Message - From: "Mark Jacobs" <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 21, 2020 1:27:43 PM Subject: IODF Activation Question - Followup I have a followup question on this topic. In addition to the 8 z/OS systems in the sysplex, we have several standalone monoplex z/OS systems on the same CEC. If I perform the HCD work in the sysplex, then transfer the IODF file to one of the standalone systems, perform a software and hardware activation there, will the IODF tokens match between the hardware and software in the members in the sysplex once they're all IPLed with the new IODF? My goal is to keep everything in sync without needing a POR of the processor. Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- 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: Where do started PROC errors go?
Try running the PROC in a batch job. You do realize that without proper setup the STC is probably using a different userid. On Thu, 21 May 2020 09:11:10 -0700 Charles Mills wrote: :>I have a program that runs successfully in a job. I just cloned the JCL :>appropriately into a PROC. When I issue a START for the PROC I get a started :>message and an ended message but no clue as to why it failed. (It is :>supposed to be long-running, so ending is a failure.) I don't think it is a :>JCL error because I get a JCL error message in that case, and I have :>evidence that it actually ran "some." :> :>The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong :>evidence that the program is getting far enough that it would have written :>several lines to SYSTSPRT. :> :>I see nothing in SDSF, even with PREFIX * and OWNER *. :> :>Where is my output going? How do I determine that? How do I view it? :> :>There is nothing in the PROC statement: //procname PROC and no operands on :>the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC :>FWIW. Again, it works in a job. :> :>Thanks, :>Charles -- 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
IODF Activation Question - Followup
I have a followup question on this topic. In addition to the 8 z/OS systems in the sysplex, we have several standalone monoplex z/OS systems on the same CEC. If I perform the HCD work in the sysplex, then transfer the IODF file to one of the standalone systems, perform a software and hardware activation there, will the IODF tokens match between the hardware and software in the members in the sysplex once they're all IPLed with the new IODF? My goal is to keep everything in sync without needing a POR of the processor. Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Where do started PROC errors go?
Whoops! I didn't notice the OUTDISP. Yes, with (PURGE,HOLD) he will not see output from a normal termination. He can override that with a JESDS on an OUTPUT statement. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Carmen Vitullo [cvitu...@hughes.net] Sent: Thursday, May 21, 2020 12:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? depending on your defined started task table ( ICHRIN03) that could be an issue and just purge immediately. try SDSF ST with prefix set for myproc, just grasping ++ is the default no id assigned, IIRC OUTDISP=(PURGE,HOLD), <- purge on a good completion I believe , then HOLD if there's a failure Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 21, 2020 11:46:45 AM Subject: Re: [External] Where do started PROC errors go? All that is in SYSLOG is S myproc,MSGCLASS=H IRR813I NO PROFILE WAS FOUND IN THE STARTED CLASS FOR 446 myproc WITH JOBNAME myproc. RACF WILL USE ICHRIN03. $HASP100 myproc ON STCINRDR IEF695I START myproc WITH JOBNAME myproc IS ASSIGNED TO USER $HASP373 myproc STARTED $HASP395 myproc ENDED Is that USER a problem? I'm not getting any RACF messages. Here is JES2PARM JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE, /* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgs e WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /* WS*/ LOG=YES, /* Print JES2 JOB LOG LOG WS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000, /* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ (I have "ALL CLASSES" in SDSF.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 systems show OPI=YES
the solution to the OPI using the default rather than what was specific has been resolved... apparently if you concatenate IEASYSxx members, and you want to ensure OPI=NO you MUST specify OPI=NO in the last member NIP is reads, I added OPI=NO to all three members I specify and now get OMVS=(00,23,SC), IEASYSSC OPI=NO, IEASYS20 OPT=02, IEASYS00 OSPROTECT=SYSTEM, Default Carmen Vitullo - Original Message - From: "Carmen Vitullo" To: "IBM Mainframe Discussion List" Sent: Wednesday, April 22, 2020 12:03:51 PM Subject: Re: z/OS 2.3 systems show OPI=YES Thanks Michael, I've tried different options, removed added parmlibs no difference. my shared parmlib has IEASYS00,SA,SC, and SA, the other members contain only parameters that are not common to the entire plex SYS1.PARMLIB is added dynamically and has an IEASYS00 member that only contains CLPA. the response from IBM support seems to elude to the fact that they see the same as I am, I was curious if anyone is setting OPI=NO and seeing YES thanks again Carmen Vitullo - Original Message - From: "Michael Babcock" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, April 22, 2020 11:27:48 AM Subject: Re: z/OS 2.3 systems show OPI=YES My Zelden IPLINFO shows OPI=YES and set by IEASYSD0. Do a D PARMLIB and ensure you are pulling the correct IEASYS00 member and have coded OPI=NO. My D IPLINFO shows the same as yours with respect to (OP) being shown and we don’t prompt either (M1 coded in Load parm). On Wed, Apr 22, 2020 at 11:06 AM Carmen Vitullo wrote: > I'm working an audit issue which has been identified as a system exposure. > I have in a shared parmlib IEASYS00 member OPI=NO, my IPLPARMS are set as > 220100M1, but the D IPLINFO shows > > SYSTEM IPLED AT 23.20.28 ON 04/01/2020 > RELEASE z/OS 02.03.00 LICENSE = z/OS > USED LOAD00 IN SYS1.IPLPARM ON 02201 > ARCHLVL = 2 MTLSHARE = N > IEASYM LIST = (00,L) > IEASYS LIST = (00,SA,20) (OP) > Marks IPLINFO rexx shows > > OPI=YES, Default > SYSP=(00,SA,20), Operator > we are setting OPI=NO > and are not prompting or setting SYSP parameters via an operator request. > I have an open PMR with IBM but I wonder if anyone else sees the same > displays ? > thanks > Carmen > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- 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: [External] Where do started PROC errors go?
Carmen also brought up a good point, you may be running with a started task table ICHRIN03 instead of the STARTED class. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Yes, the may be a problem, because that means you're most likely running with an undefined user which means RACF is most likely stopping the task from running unless every dataset it is hitting has a UACC allowing access. You need to define a security profile in the STARTED class with your proc name to grant access. The other thing is the OUTDISP=(PURGE) in jes2parm. That's telling JES2 to purge the output when the task completes. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? All that is in SYSLOG is S myproc,MSGCLASS=H IRR813I NO PROFILE WAS FOUND IN THE STARTED CLASS FOR 446 myproc WITH JOBNAME myproc. RACF WILL USE ICHRIN03. $HASP100 myproc ON STCINRDR IEF695I START myproc WITH JOBNAME myproc IS ASSIGNED TO USER $HASP373 myproc STARTED $HASP395 myproc ENDED Is that USER a problem? I'm not getting any RACF messages. Here is JES2PARM JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ (I have "ALL CLASSES" in SDSF.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent
Re: [External] Where do started PROC errors go?
The $HASP messages say that the started task did run and complete. Is your userid authorized to view output from ICHRIN03? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? All that is in SYSLOG is S myproc,MSGCLASS=H IRR813I NO PROFILE WAS FOUND IN THE STARTED CLASS FOR 446 myproc WITH JOBNAME myproc. RACF WILL USE ICHRIN03. $HASP100 myproc ON STCINRDR IEF695I START myproc WITH JOBNAME myproc IS ASSIGNED TO USER $HASP373 myproc STARTED $HASP395 myproc ENDED Is that USER a problem? I'm not getting any RACF messages. Here is JES2PARM JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ (I have "ALL CLASSES" in SDSF.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu
Re: [External] Where do started PROC errors go?
Yes, the may be a problem, because that means you're most likely running with an undefined user which means RACF is most likely stopping the task from running unless every dataset it is hitting has a UACC allowing access. You need to define a security profile in the STARTED class with your proc name to grant access. The other thing is the OUTDISP=(PURGE) in jes2parm. That's telling JES2 to purge the output when the task completes. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? All that is in SYSLOG is S myproc,MSGCLASS=H IRR813I NO PROFILE WAS FOUND IN THE STARTED CLASS FOR 446 myproc WITH JOBNAME myproc. RACF WILL USE ICHRIN03. $HASP100 myproc ON STCINRDR IEF695I START myproc WITH JOBNAME myproc IS ASSIGNED TO USER $HASP373 myproc STARTED $HASP395 myproc ENDED Is that USER a problem? I'm not getting any RACF messages. Here is JES2PARM JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ (I have "ALL CLASSES" in SDSF.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this
Re: [External] Where do started PROC errors go?
depending on your defined started task table ( ICHRIN03) that could be an issue and just purge immediately. try SDSF ST with prefix set for myproc, just grasping ++ is the default no id assigned, IIRC OUTDISP=(PURGE,HOLD), <- purge on a good completion I believe , then HOLD if there's a failure Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 21, 2020 11:46:45 AM Subject: Re: [External] Where do started PROC errors go? All that is in SYSLOG is S myproc,MSGCLASS=H IRR813I NO PROFILE WAS FOUND IN THE STARTED CLASS FOR 446 myproc WITH JOBNAME myproc. RACF WILL USE ICHRIN03. $HASP100 myproc ON STCINRDR IEF695I START myproc WITH JOBNAME myproc IS ASSIGNED TO USER $HASP373 myproc STARTED $HASP395 myproc ENDED Is that USER a problem? I'm not getting any RACF messages. Here is JES2PARM JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE, /* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgs e WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /* WS*/ LOG=YES, /* Print JES2 JOB LOG LOG WS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000, /* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ (I have "ALL CLASSES" in SDSF.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: REXX and BPXWUNIX()
That looks like your original code, e.g., unnecessary address, call bpxwunix 'host ',ipaddr.i,out. Teh first parameter should be 'host' ipaddr.i, the second parameter should be omitted and the third parameter should be quoted, although unquoted will work as long as you never assign a value to the out. stem. call bpxwunix 'host' ipaddr.i, /* no stdin parameter */, 'out.' -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of J Ellis [020d5fbe36e0-dmarc-requ...@listserv.ua.edu] Sent: Thursday, May 21, 2020 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX and BPXWUNIX() thanks, I'll give the shell a try and let you know, i've attached a jcl run -- 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: [External] Where do started PROC errors go?
All that is in SYSLOG is S myproc,MSGCLASS=H IRR813I NO PROFILE WAS FOUND IN THE STARTED CLASS FOR 446 myproc WITH JOBNAME myproc. RACF WILL USE ICHRIN03. $HASP100 myproc ON STCINRDR IEF695I START myproc WITH JOBNAME myproc IS ASSIGNED TO USER $HASP373 myproc STARTED $HASP395 myproc ENDED Is that USER a problem? I'm not getting any RACF messages. Here is JES2PARM JOBCLASS(STC) TIME=(1440,00), /* Job Step Time ...ss... WS*/ COMMAND=EXECUTE,/* Execute Commands ..r.. WS*/ BLP=NO, /* Ignore BLP parm ...l. WS*/ AUTH=ALL, /* Allow all Cmds . WS*/ MSGLEVEL=(1,1), /* Job, All Msgse WS*/ IEFUJP=YES, /* Take SMF Job Purge Exit IEFUJP WS*/ IEFUSO=YES, /* Take SYSOUT Excess Exit IEFUSO WS*/ OUTDISP=(PURGE,HOLD), /*WS*/ LOG=YES,/* Print JES2 JOB LOG LOGWS*/ OUTPUT=YES, /* Produce Output for Job OUTPUT WS*/ PERFORM=000,/* SRM Performance Group 0 PERFORM hwnc*/ PROCLIB=00, /* Use //PROC00 DD hwnc*/ REGION=0K, /* Region Size hwnc*/ /* (format changed SP410) */ TYPE6=YES, /* Produce SMF 6 Records TYPE6 WS*/ TYPE26=YES, /* Produce SMF 26 Records TYPE26 WS*/ MSGCLASS=K /* Default Message Class STCMCLAS WS*/ (I have "ALL CLASSES" in SDSF.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, May 21, 2020 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Where do started PROC errors go? Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to configure LOADxx in DR
More precisely, when ADRDSSU, initializes a volume, it writes IPL text whose only purpose is to load a 00F wait state. So if you do not replace that with IPL text for another program, you get a 00F wait state when you IPL that volume. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 05/21/2020 09:50:59 AM: > From: "Jordi Bornay" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/21/2020 12:37 PM > Subject: Re: How to configure LOADxx in DR > Sent by: "IBM Mainframe Discussion List" > > yes, but the error that comments (00F) is because it cannot find theIPL text. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where do started PROC errors go?
Is your proc in the IEFJOBS or IEFPDSI concatenation? Does it have a JOB statement? What messages did you get after the START? Is the MSGCLASS a purge class? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 21, 2020 12:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- 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: [External] Where do started PROC errors go?
Charles, A couple things to check. Is there anything in the SYSLOG showing what happened to the task? Check your JES2PARM member of parmlib. In there, you should find a JOBCLASS(STC) stanza. What does that show for LOG, MSGCLASS, MSGLEVEL, OUTDISP and OUTPUT? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, May 21, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Where do started PROC errors go? I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Where do started PROC errors go?
I have a program that runs successfully in a job. I just cloned the JCL appropriately into a PROC. When I issue a START for the PROC I get a started message and an ended message but no clue as to why it failed. (It is supposed to be long-running, so ending is a failure.) I don't think it is a JCL error because I get a JCL error message in that case, and I have evidence that it actually ran "some." The PROC includes //SYSTSPRT DD SYSOUT=H. (H is a held class.) I have strong evidence that the program is getting far enough that it would have written several lines to SYSTSPRT. I see nothing in SDSF, even with PREFIX * and OWNER *. Where is my output going? How do I determine that? How do I view it? There is nothing in the PROC statement: //procname PROC and no operands on the START other than the PROC name. The program is IKJEFT01 and a Rexx EXEC FWIW. Again, it works in a job. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS/Rocket find and xargs
I figured this out myself. Something really stupid. I wasn't putting
'{}' at the end of the tar command. Jeez.
On 5/21/2020 8:47 AM, Michael Babcock wrote:
I have Rocket’s bash, git, findutils, xargs, vim, etc installed on my
z/OS 2.4 system and can't seem to make something work.
I have a directory /u/xx35/test that contains directories with names
like 20200512, 20200513, 20200514, etc (year, month, day). These
directories have other directories and files under them. I want to
tar (but not feather!) each directory over 3 days old. I only want to
archive the directories (which should get everything in that directory
and below).
So after archiving it should look like the following (as long as each
directory is over 3 days old):
Under /u/xx35/test:
20200512
20200512.tar
20200513
20200513.tar
20200514
20200514.tar
I have a batch job executing the following:
//STEPNAME EXEC PGM=BPXBATSL
//STDPARM DD DISP=SHR,DSN=XX35.ARCHIVE.FOLDERS
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
The STDPARM contains:
SH /rsusr/ported/bin/bash -l
/u/xx35/ArchiveDelete.sh /u/xx35/test
ArchiveDelete.sh contains:
#!/rsusr/ported/bin/bash
StartFolder=$1
find $StartFolder -mindepth 1 -maxdepth 1 -type d -mtime +3 | xargs echo
When I run the batch job, it’s output is as it should be no matter
which directory I’m in.
IEF375I JOB/XX35REXX/START 2020140.1451
IEF033I JOB/XX35REXX/STOP 2020140.1451
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
/u/xx35/test/20200512 /u/xx35/test/20200513 /u/xx35/test/20200514
But when I change "xargs echo" to "xargs -I '{}' tar -cvzf '{}'.tar"
(full command below).
find $StartFolder -mindepth 1 -maxdepth 1 -type d -mtime +3 | xargs -I
'{}' tar -cvzf '{}'.tar
It doesn’t execute as I expect it to. If I do it manually in a VT320
session and am in the /u/xx35/test directory, it works as expected,
but if I’m in the directory /u/xx35, it tries to archive everything in
that directory and stick it in the /u/xx35/test directory as
20200512.tar. I’ve looked at numerous examples on the net and mine
should work so I don’t understand where I’m going wrong. I know this
is a convoluted way of doing it, but can anyone help? Need more info?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM Extended Format Record Layout
Does anyone have a simple document of the above that uses DFSORT's ICETOOL? According to one coworker's effort, the first volser is in Column 9 for a length of 6. Does that sound right? I tried IEHIBALL on a browse of the extract file and quickly got confused with seeing column mismatches. We are converting all VTS tapes into a VE using TTO (Tivoli Tape Optimizer) and are looking to find all non-SCRATCH tape volsers beginning with a "B" or a "C" and see if the last used program *is not* GTOCOPY. That would produce a list of tapes remaining to be copied or excluded for other reasons. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and BPXWUNIX()
turns out it was something silly/overlooked, missing comma ... I had: call bpxwunix 'host ' ipaddr.i,out. should have been call bpxwunix 'host ' ipaddr.i,,out. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and BPXWUNIX()
thanks, I'll give the shell a try and let you know, i've attached a jcl run -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 1 J E S 2 J O B L O G -- S Y S T E M S Y S A -- N O D E H O M E J E S 2 0 06.19.34 JOB28457 THURSDAY, 21 MAY 2020 06.19.34 JOB28457 $HASP373 CDPJJEIP STARTED - WLM INIT - SRVCLASS SCBATEXP - SYS SYSB 06.19.34 JOB28457 ACF9CCCD USERID CDPJJE IS ASSIGNED TO THIS JOB - CDPJJEIP 06.19.34 JOB28457 IEF196I ACF9CCCD USERID CDPJJE IS ASSIGNED TO THIS JOB - CDPJJEIP 06.19.34 JOB28457 IEF403I CDPJJEIP - STARTED - TIME=06.19.34 06.19.34 JOB28457 BPXF274I FILE SYSTEM OMV.TST.USER.CDPJJE 892 892 FAILED TO MOUNT. 892 RETURN CODE = 0072, REASON CODE = EF186058 06.19.34 JOB28457 - -TIMINGS (MINS.)-- V08/01/11 06.19.34 JOB28457 IEF196I - -TIMINGS 06.19.34 JOB28457 IEF196I (MINS.)-- V08/01/11 06.19.34 JOB28457 -JOBNAME STEPNAME PROCSTEP PROGNAMERC EXCP TCB SRB CLOCK S/U SRVCLASS 06.19.34 JOB28457 IEF196I -JOBNAME STEPNAME PROCSTEP PROGNAMERC EXCP TCB 06.19.34 JOB28457 IEF196I SRB CLOCK S/U SRVCLASS 06.19.34 JOB28457 -CDPJJEIP @TSOSYSP IKJEFT0100447 .00 .00 .0 1729 SCBATEXP 06.19.34 JOB28457 IEF196I -CDPJJEIP @TSOSYSP IKJEFT0100447 .00 06.19.34 JOB28457 IEF196I .00 .0 1729 SCBATEXP 06.19.34 JOB28457 IEF404I CDPJJEIP - ENDED - TIME=06.19.34 06.19.34 JOB28457 -CDPJJEIP ENDED. NAME-SNT6460P PRINT TOTAL TCB CPU TIME= .00 TOTAL ELAPSED TIME=.0 06.19.34 JOB28457 IEF196I -CDPJJEIP ENDED. NAME-SNT6460P PRINT TOTAL TCB CPU TIME= 06.19.34 JOB28457 IEF196I .00 TOTAL ELAPSED TIME=.0 06.19.34 JOB28457 $HASP395 CDPJJEIP ENDED - RC= 0-- JES2 JOB STATISTICS -- - 21 MAY 2020 JOB EXECUTION DATE - 11 CARDS READ - 285 SYSOUT PRINT RECORDS -0 SYSOUT PUNCH RECORDS - 15 SYSOUT SPOOL KBYTES - 0.00 MINUTES EXECUTION TIME 1 //CDPJJEIP JOB 10,'SNT6460P PRINT',CLASS=9,MSGCLASS=Q,NOTIFY=CDPJJE JOB28457 //* $ACFJ219 ACF2 ACTIVE HOMEJES2 ACF2 //* $ACFJ219 ACF2 ACTIVE HOMEJES2 ACF2 2 //@TSOSYSP EXEC PGM=IKJEFT01,REGION=8M, // PARM='HOSTNAME' 3 //SYSEXEC DD DISP=SHR,DSN=CDPJJE.SYSEXEC 4 //SYSTSPRT DD SYSOUT=* 5 //SYSTSINDD DUMMY,LRECL=80 6 //STDOUT DD SYSOUT=* 7 //STDERR DD SYSOUT=* 8 //DDOUT DD SYSOUT=* 9 //INPUT DD DISP=SHR,DSN=CDPJJE.MYOMVS.PDSE(STDIN) IEF043I Actions taken by SMFLIMxx parmlib policy for CDPJJEIP @TSOSYSP Step system reserved below set to 512K by policy - SMFLIMSB 0001 Step system reserved above set to50M by policy - SMFLIMSB 0001 Step MEMLIMIT set to32G by policy - SMFLIMSB 0001 IEFA111I CDPJJEIP IS USING THE FOLLOWING JOB RELATED SETTINGS: SWA=ABOVE,TIOT SIZE=48K,DSENQSHR=DISALLOW,GDGBIAS=JOB IEF236I ALLOC. FOR CDPJJEIP @TSOSYSP IEF237I AA77 ALLOCATED TO SYSEXEC IEF237I JES2 ALLOCATED TO SYSTSPRT IEF237I DMY ALLOCATED TO SYSTSIN IEF237I JES2 ALLOCATED TO STDOUT IEF237I JES2 ALLOCATED TO STDERR IEF237I JES2 ALLOCATED TO DDOUT IGD103I SMS ALLOCATED TO DDNAME INPUT IEF142I CDPJJEIP @TSOSYSP - STEP WAS EXECUTED - COND CODE IEF285I CDPJJE.SYSEXEC KEPT IEF285I VOL SER NOS= DPS507. IEF285I CDPJJE.CDPJJEIP.JOB28457.D101.? SYSOUT IEF285I CDPJJE.CDPJJEIP.JOB28457.D102.? SYSOUT IEF285I CDPJJE.CDPJJEIP.JOB28457.D103.? SYSOUT IEF285I CDPJJE.CDPJJEIP.JOB28457.D104.? SYSOUT IGD104I CDPJJE.MYOMVS.PDSE RETAINED, DDNAME=INPUT SMFEXCP SYSEXEC = 16 INPUT = 9 SMFSTEP*DUR 0MIN 0.24SEC %CPU 20.8 SRB 0MIN 0.00SEC REGN 8756K DPRTY 00,00
Re: REXX and BPXWUNIX()
On Thu, 21 May 2020 07:45:59 -0500, J Ellis wrote: >I have been using the link provided from the start. as noted in the link: >stdin.0 must contain the number of lines that are to be redirected to the >command. stdin.1, stdin.2, ... contain the lines. > Which link? The one I posted?: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxb600/wunix.htm >that is why on STDIN i coded the ipaddr.I, and that works. > I'm surprised. In what sense does it "work" It doesn't ABEND? >I am just not getting anything back in the output position: >If stdout is not specified, your current stdout file is passed to the shell >for stdout " >... >When I try and 'say' the output, all that is in there is the text >OUT.1,OUT.2,OUT.3 etc > Is that with the code you posted earlier? Please show the code and the exact output. This could be much simplified by letting shell rather than Rexx handle the looping: /* Rexx */ signal on novalue /* Just to irritate Shmuel */ call BPXWUNIX , 'while read IP; do host "$IP"; done', , 'DD:INPUT', "DD:OUTPUT", "DD:STDERR" exit On Wed, 20 May 2020 14:56:39 -0500, J Ellis wrote: >i would like to use the bpxwunix function to run, either HOST or DIG or >nslookup commands, seems pretty straightforward ... > >//@TSOSYSP EXEC PGM=IKJEFT01,REGION=8M, >// PARM='HOSTNAME' >//SYSEXEC DD DISP=SHR,DSN=SYSEXEC >//SYSTSPRT DD SYSOUT=* >//SYSTSINDD DUMMY,LRECL=80 >//STDOUT DD SYSOUT=* >//STDERR DD SYSOUT=* >//DDOUT DD SYSOUT=* >//INPUT DD DISP=SHR,DSN=MYOMVS.PDSE(STDIN) Say "Hello" to the emu for me, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to configure LOADxx in DR
yes, but the error that comments (00F) is because it cannot find the IPL text. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS/Rocket find and xargs
I have Rocket’s bash, git, findutils, xargs, vim, etc installed on my
z/OS 2.4 system and can't seem to make something work.
I have a directory /u/xx35/test that contains directories with names
like 20200512, 20200513, 20200514, etc (year, month, day). These
directories have other directories and files under them. I want to tar
(but not feather!) each directory over 3 days old. I only want to
archive the directories (which should get everything in that directory
and below).
So after archiving it should look like the following (as long as each
directory is over 3 days old):
Under /u/xx35/test:
20200512
20200512.tar
20200513
20200513.tar
20200514
20200514.tar
I have a batch job executing the following:
//STEPNAME EXEC PGM=BPXBATSL
//STDPARM DD DISP=SHR,DSN=XX35.ARCHIVE.FOLDERS
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
The STDPARM contains:
SH /rsusr/ported/bin/bash -l
/u/xx35/ArchiveDelete.sh /u/xx35/test
ArchiveDelete.sh contains:
#!/rsusr/ported/bin/bash
StartFolder=$1
find $StartFolder -mindepth 1 -maxdepth 1 -type d -mtime +3 | xargs echo
When I run the batch job, it’s output is as it should be no matter which
directory I’m in.
IEF375I JOB/XX35REXX/START 2020140.1451
IEF033I JOB/XX35REXX/STOP 2020140.1451
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
/u/xx35/test/20200512 /u/xx35/test/20200513 /u/xx35/test/20200514
But when I change "xargs echo" to "xargs -I '{}' tar -cvzf '{}'.tar"
(full command below).
find $StartFolder -mindepth 1 -maxdepth 1 -type d -mtime +3 | xargs -I
'{}' tar -cvzf '{}'.tar
It doesn’t execute as I expect it to. If I do it manually in a VT320
session and am in the /u/xx35/test directory, it works as expected, but
if I’m in the directory /u/xx35, it tries to archive everything in that
directory and stick it in the /u/xx35/test directory as 20200512.tar.
I’ve looked at numerous examples on the net and mine should work so I
don’t understand where I’m going wrong. I know this is a convoluted way
of doing it, but can anyone help? Need more info?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Creating new SMS environment in a monoplex
Your Welcome Bob, so glad I could help someone here :) I didn't start doing storage, SMS till I left Boeing, lets see that was 1998 - wow Carmen Vitullo - Original Message - From: "Robert B. Richards" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 21, 2020 5:24:10 AM Subject: Re: Creating new SMS environment in a monoplex > Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. As long as the CATALOGs are shared for what you are trying to manage, yes. BTDT, 20+ years ago. Thanks to both of you, Skip, and Carmen for the confirmation of taking a copy of a SCDS and matching ACDS from a sysplex environment and making it work in a single system monoplex. It has been 20+ years since I did everyday storage management for a living. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, May 21, 2020 6:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: > SMSPLEX=SYSPLEX: no, you can't. > GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have > separate SMS plexes. > > If you mean: an SMSplex cannot cross Sysplexes: that is true. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: 20 May 2020 17:14 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > To complement: there is strict requirement to have SMSplex = Sysplex. > > SMS, as many other system components does support multihost configurations. > Multihost could mean several monoplex systems and shared CDS datasets on > shared volume. > Multihost could also mean SMSplex which covers some sysplex and few > monoplexes together. > SMSplex could also cover part of sysplex, so different sysplex member > may have different SMS settings. > > As usually IBM recommend to keep SMSplex = sysplex. > > Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. > > However each system component may have it's own specifics/restrictions. > AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is > impossible - JES MAS is available only within sysplex boundaries. > However it is possible to have more than one MAS within sysplex. > Sometimes sysplex=*plex give some advantages, especially sysplex > communication and CF structures. > == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- 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
Re: [External] Re: What crashing COBOL systems reveal about applications maintenance -- GCN
OPT(0) burns that much more CPU? Is this on all compiles or many or just a few of them? If compiles are that bad using OPT(0), what will an OPT(2) do? We're just starting our install of 6.3, going from 4.2 and this sounds like something we need to be aware of. Thanks, Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of ste...@copper.net Sent: Wednesday, May 20, 2020 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: What crashing COBOL systems reveal about applications maintenance -- GCN We setup for OPT(1) because IBM said that was the thing to do initially. We’ve only recently been told to go OPT(2). We’ve also run into an interesting issue of COBOL 6.2 compiles using OPT(0) taking > 10x CPU of same compile with 4.2. I don’t recall being told that we would see that level of CPU burn for planning for capacity for migrating to 6.2. Regards Steve Thompson --- frank.swarbr...@outlook.com wrote: From: Frank Swarbrick To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] What crashing COBOL systems reveal about applications maintenance -- GCN Date: Wed, 20 May 2020 21:28:33 + We use OPT(1). Probably for no good reason. (And it was my decision, meaning its easy enough to change!) From: IBM Mainframe Discussion List on behalf of Tom Ross Sent: Wednesday, May 20, 2020 3:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What crashing COBOL systems reveal about applications maintenance -- GCN >Suppose that they took a group of programmers and got the production >online= programs to all compile with COBOL 6.2 and OPT(1). Would they >see a signif= icant reduction in MSUs? Assuming they are running on z14s >minimally? I sure hope no one is using OPT(1) with 3rd generation COBOL! IBM expects all users to compile with OPT(2) for production performance. I am honestly not sure why we shipped OPT(1). Users should use OPT(0) if they want more straight-forward debugging (no optimizations) and then after unit test compile with OPT(2) for performance, and and never use OPT(1). Alternatively, they could compile with OPT(2) for debugging and get used to odd things like statements getting moved or deleted while debugging. Cheers, TomR >> COBOL is the Language of the Future! << -- 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX and BPXWUNIX()
I have been using the link provided from the start. as noted in the link: stdin.0 must contain the number of lines that are to be redirected to the command. stdin.1, stdin.2, ... contain the lines. that is why on STDIN i coded the ipaddr.I, and that works. I am just not getting anything back in the output position: "stdout An optional argument, stdout is the name of a compound variable (stem) that, upon return, contains the normal output from the command. stdout.0 is the number of lines output by the command. stdout.1, stdout.2, ... contain the output lines. stdout can also be specified as: The string STACK, if the output is to be returned on the stack DD:ddname, if the output is to be written to an allocated DD If stdout is not specified, your current stdout file is passed to the shell for stdout " When I try and 'say' the output, all that is in there is the text OUT.1,OUT.2,OUT.3 etc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to configure LOADxx in DR
I use the same LOAD member in SYS1.IPLPARM and use LPARNAME to set the correct parameters , I use the IEASYM member to do the rest - just a snip of what I have, there's more to it but it works well all I do is shutdown and deactivate the LPAR's on one CEC and ACTIVATE and IPL the DR images on the other CEC only difference is the UCB's they are replicated using hyperswap + PPRC volumes so my IPL profile is 3xxx not 2xxx for the sysres and iodf volume LOADxx IEASYM (00,L) NUCLEUS 1 NUCLST 00 INITSQA 0020K 0001M SYSPLEX PLEX1 * prod --- LPARNAME APROD1 PARMLIB SYS1.user.PARMLIB IODF ** HCD SYSA00 FOR DR LPARNAME KPROD1 IODF ** HCD SYSK00 PARMLIB SYS1.user.PARMLIB HWNAME to decide what parms to use. IEASYMxx SYSDEF HWNAME(CWY1) LPARNAME(APROD1) set the normal prod parms SYSDEF HWNAME(Z13K) LPARNAME(KPROD1) set the DR parms and options Carmen Vitullo - Original Message - From: "Gilson Cesar de Oliveira" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 21, 2020 3:59:28 AM Subject: How to configure LOADxx in DR Hello: We have the following situation when trying to activate and IPL 3 lpars from site A into site B. Both sites are distant about 450 Km and the storage replication is made by Global Metro Mirror. The issue we have faced last weekend is related to match the IODF we have received from the team which is responsible for the box in site B. We have the SYS1.IODFE0 with all the definitions for the box in site B where they have more lpars than just our 3 defined there. In site A where my team is responsible for the SYS1.IODFxx we have pointed in LOADxx with **. When trying to IPL the same lpars in site B we are configuring in LOADyy with IODF = E0. There was something wrong with this configuration because in the VOLUME where the SYS1.IODFE0 is located, it didn't match with the configuration in HSA. Perhaps someone from the site B have validated new IODF for other lpars than the 3 we have defined and the IPL didn't came up returning an error which wait state code is 0F indicating a mismatch in the volume or with the dataset (it looks like it didn't found the dataset or the configuration). Does anyone here could give us tips on how to have the configuration working for both sites without worrying about changes in terms of IO configuration not related to our lpars ?? Thanks in advance for any help. Regards, Gilson -- 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: Creating new SMS environment in a monoplex
> Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. As long as the CATALOGs are shared for what you are trying to manage, yes. BTDT, 20+ years ago. Thanks to both of you, Skip, and Carmen for the confirmation of taking a copy of a SCDS and matching ACDS from a sysplex environment and making it work in a single system monoplex. It has been 20+ years since I did everyday storage management for a living. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Thursday, May 21, 2020 6:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: > SMSPLEX=SYSPLEX: no, you can't. > GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have > separate SMS plexes. > > If you mean: an SMSplex cannot cross Sysplexes: that is true. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: 20 May 2020 17:14 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Creating new SMS environment in a monoplex > > To complement: there is strict requirement to have SMSplex = Sysplex. > > SMS, as many other system components does support multihost configurations. > Multihost could mean several monoplex systems and shared CDS datasets on > shared volume. > Multihost could also mean SMSplex which covers some sysplex and few > monoplexes together. > SMSplex could also cover part of sysplex, so different sysplex member > may have different SMS settings. > > As usually IBM recommend to keep SMSplex = sysplex. > > Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. > > However each system component may have it's own specifics/restrictions. > AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is > impossible - JES MAS is available only within sysplex boundaries. > However it is possible to have more than one MAS within sysplex. > Sometimes sysplex=*plex give some advantages, especially sysplex > communication and CF structures. > == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- 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: Creating new SMS environment in a monoplex
No, not exactly. First, I meant "regular" sysplex. In that case it is possible and recommended to have SMSplex=sysplex. However it is also possible to have multiple SMSplexes within a sysplex, and within GDPS. And I mean SMSplex can be cross-plex - yes, it is possible. Multiple non-sysplexed systems can share SMS. Correct me if I'm wrong. -- Radoslaw Skorupka Lodz, Poland W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze: SMSPLEX=SYSPLEX: no, you can't. GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have separate SMS plexes. If you mean: an SMSplex cannot cross Sysplexes: that is true. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 20 May 2020 17:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Creating new SMS environment in a monoplex To complement: there is strict requirement to have SMSplex = Sysplex. SMS, as many other system components does support multihost configurations. Multihost could mean several monoplex systems and shared CDS datasets on shared volume. Multihost could also mean SMSplex which covers some sysplex and few monoplexes together. SMSplex could also cover part of sysplex, so different sysplex member may have different SMS settings. As usually IBM recommend to keep SMSplex = sysplex. Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc. However each system component may have it's own specifics/restrictions. AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is impossible - JES MAS is available only within sysplex boundaries. However it is possible to have more than one MAS within sysplex. Sometimes sysplex=*plex give some advantages, especially sysplex communication and CF structures. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to configure LOADxx in DR
hello have you put the IPL text in the volume .. ?? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to configure LOADxx in DR
Hello: We have the following situation when trying to activate and IPL 3 lpars from site A into site B. Both sites are distant about 450 Km and the storage replication is made by Global Metro Mirror. The issue we have faced last weekend is related to match the IODF we have received from the team which is responsible for the box in site B. We have the SYS1.IODFE0 with all the definitions for the box in site B where they have more lpars than just our 3 defined there. In site A where my team is responsible for the SYS1.IODFxx we have pointed in LOADxx with **. When trying to IPL the same lpars in site B we are configuring in LOADyy with IODF = E0. There was something wrong with this configuration because in the VOLUME where the SYS1.IODFE0 is located, it didn't match with the configuration in HSA. Perhaps someone from the site B have validated new IODF for other lpars than the 3 we have defined and the IPL didn't came up returning an error which wait state code is 0F indicating a mismatch in the volume or with the dataset (it looks like it didn't found the dataset or the configuration). Does anyone here could give us tips on how to have the configuration working for both sites without worrying about changes in terms of IO configuration not related to our lpars ?? Thanks in advance for any help. Regards, Gilson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
