Re: Gwyn's Maxim (was: FSUM7197 pax ...)
IBM fixed IEBGENER to not clobber the SYSUT2 directory. Changing the behavior of OPEN would have broken a lot of code. The decision that file globbing should be in the shell makes it much more fragile than it would otherwise have been. I prefer the TSO approach of proving services and letting the command invoke, e.g., IKJPARSE with parameters describing what input is valid. -- 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, November 5, 2020 6:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Gwyn's Maxim (was: FSUM7197 pax ...) > Probably there's a "dusty deck" somewhere whose inexcusably clever > author relied on the behavior Well, you can certainly see some JCL somewhere where there is for example // SET DSN1=SOME.PDS(FOO) And there are a bunch of references to DSN=&DSN1, most of which really "want" the member qualification, but one of which is a DISP=(OLD,DELETE) that is in fact working as the coder intended. If I had coded that I don't think I would consider it inexcusably clever. IIRC they did fix another trap for the unwary. A program opens DD1 as an output SAM dataset. Someone executes the program and codes //DD1 DD DSN=SOME.PDS, when what they really meant was SOME.PDS(FOO). IIRC back in the good old days MVS would overwrite the directory of SOME.PDS, with the obvious negative consequences. I think they fixed that and the described scenario now fails. I will leave testing it as an exercise for the reader. > Shell doesn't know what's a file and what's a switch. Well, if it is expanding pax * to pax file file file file could it not recognize that one such file looked a heck of a lot like a switch? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, November 5, 2020 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Gwyn's Maxim (was: FSUM7197 pax ...) https://secure-web.cisco.com/1kA1nzS5bWbEveUQu96rFIxSd-w35tunHkOaalpolTZTe2jBLFVW0vP7ZSrQnnGIPgpSe3Vpiv3vsfh6sedWX9btx5QaEIrGhx-I3TYvh8O5--QIceF1_5Lh9ebdxX22YlACn5vu2Y_sePOvVjgOJg6I3kiY798_Uz_ic0IB2su6__oEc3fBsnVGbBlJGncN4VIphgY8-Hcpx6kvbsJDT7Kg-QPwF8Rt-F5zG1Eh3mFxiXV_ECxxdNt3YJQJ572-x_QQfUvKh-KUwl4VzKMKk3JKeUDrpyI5czZzEnCZl_AEGrNXTNpe7J4pt-cEo-ObAjs9t1Jgax9aqK1C4eOtfClC9SKiWl19riXAjKlT3fRgTTBMCGKUcK3MPIXT-9UtyTBfvasrhhCINL0Gnc_WCKnuHnpYMOMMig83J1pN7iE0NeEq5dx28VJSRIk6E8kCh/https%3A%2F%2Fopensource.com%2Fbusiness%2F14%2F12%2Flinux-philosophy On Thu, 5 Nov 2020 06:46:15 -0800, Charles Mills wrote: >What the heck were the UNIX designers thinking when they allowed the casual >creation of a filename of -x? There may be a legitimate reason why someone >would want to create a file named -x but if so, then *they* should be made to >jump through some small hoop and "escape" the name in some way. The innocent >victim who stumbles into this situation should not be the one made to jump >through hoops. Will UNIX allow the creation of a file named "rm *"? That could >have some interesting side effects. > Even worse, a file named "-rf *". This resembles the plaint of a JCL novice who has just encountered, painfully, the astonishing behavior of: //SYSUT1 DD DSN=&SYSUID..PDS(MEMBER),DISP=(OLD,DELETE) That should be fixed for DYNALLOC, JCL, TSO, globally by making the TU for member mutex with the TU for delete. Who volunteers to bell the RFE cat? Probably there's a "dusty deck" somewhere whose inexcusably clever author relied on the behavior and whose heirs haven't access to the source. >How did I inadvertently create a file named -x? I had a pax command > >pax -wzvf /my/archive.pax * > >I had an error that I thought might be solved by -x os390. Looking at the >above command I forgot that /my/archive.pax "went with" the -f and coded > >pax -wzvf -x os390 /my/archive.pax * >... >Heck, if the shell is going to expand the * then it could generate a warning >"hey, did you know that one of your files has a name that looks just like a >switch?" > Shell doesn't know what's a file and what's a switch. That's the responsibility of the utility, even as JCL shouldn't know what PARM means: //STEP EXEC PGM=BPXBATCH,PARM='sudo rm -rf /' -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Gwyn's Maxim (was: FSUM7197 pax ...)
> Probably there's a "dusty deck" somewhere whose inexcusably clever > author relied on the behavior Well, you can certainly see some JCL somewhere where there is for example // SET DSN1=SOME.PDS(FOO) And there are a bunch of references to DSN=&DSN1, most of which really "want" the member qualification, but one of which is a DISP=(OLD,DELETE) that is in fact working as the coder intended. If I had coded that I don't think I would consider it inexcusably clever. IIRC they did fix another trap for the unwary. A program opens DD1 as an output SAM dataset. Someone executes the program and codes //DD1 DD DSN=SOME.PDS, when what they really meant was SOME.PDS(FOO). IIRC back in the good old days MVS would overwrite the directory of SOME.PDS, with the obvious negative consequences. I think they fixed that and the described scenario now fails. I will leave testing it as an exercise for the reader. > Shell doesn't know what's a file and what's a switch. Well, if it is expanding pax * to pax file file file file could it not recognize that one such file looked a heck of a lot like a switch? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, November 5, 2020 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Gwyn's Maxim (was: FSUM7197 pax ...) https://opensource.com/business/14/12/linux-philosophy On Thu, 5 Nov 2020 06:46:15 -0800, Charles Mills wrote: >What the heck were the UNIX designers thinking when they allowed the casual >creation of a filename of -x? There may be a legitimate reason why someone >would want to create a file named -x but if so, then *they* should be made to >jump through some small hoop and "escape" the name in some way. The innocent >victim who stumbles into this situation should not be the one made to jump >through hoops. Will UNIX allow the creation of a file named "rm *"? That could >have some interesting side effects. > Even worse, a file named "-rf *". This resembles the plaint of a JCL novice who has just encountered, painfully, the astonishing behavior of: //SYSUT1 DD DSN=&SYSUID..PDS(MEMBER),DISP=(OLD,DELETE) That should be fixed for DYNALLOC, JCL, TSO, globally by making the TU for member mutex with the TU for delete. Who volunteers to bell the RFE cat? Probably there's a "dusty deck" somewhere whose inexcusably clever author relied on the behavior and whose heirs haven't access to the source. >How did I inadvertently create a file named -x? I had a pax command > >pax -wzvf /my/archive.pax * > >I had an error that I thought might be solved by -x os390. Looking at the >above command I forgot that /my/archive.pax "went with" the -f and coded > >pax -wzvf -x os390 /my/archive.pax * >... >Heck, if the shell is going to expand the * then it could generate a warning >"hey, did you know that one of your files has a name that looks just like a >switch?" > Shell doesn't know what's a file and what's a switch. That's the responsibility of the utility, even as JCL shouldn't know what PARM means: //STEP EXEC PGM=BPXBATCH,PARM='sudo rm -rf /' -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Gwyn's Maxim (was: FSUM7197 pax ...)
"When the only tool you have is a pipe, everything looks like a filter." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Thursday, November 5, 2020 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Gwyn's Maxim (was: FSUM7197 pax ...) https://secure-web.cisco.com/1A7riZAPpr7boeK8ALMZCZTcsWrAD-ueyShFiA0hGSb0JnXAB9iXit1YkpYeISqRcMkVid4NR0HzMd_kBWzPx2KH9Yox8M1rB0s3QuED6mXI_nXCeF9vkG6TE2i3TzaPjgoX1Agsr613PPvZr-vZNu64QzEOC8OfkrTBUkN_jdqrLS-KIkF8E8deFrT-ThadFUD-Xj-sYa4i_AJOZ9wLAbO-ta5AA8TQO0Cp_v8FnfQ0RayCU8b5rIYCBniyHGkj4l188oyX_cSAGJf2UUEmsmO6lzD_QlKgc3Q60vQaBG11euFAtWhpN76k074Pwm9ZBjuP5QJ_Kk3UpURu1B6pbGw-deceq7EmXEiJIrOtnSQH_Gj_O8ixdhCo2MxYd5Qtm3J7uBgMTNObxNxCds-ecj-cjG27DUCfiRLQoQ7UYUnnoTXk7gjGXHubqPZulogpQ/https%3A%2F%2Fopensource.com%2Fbusiness%2F14%2F12%2Flinux-philosophy On Thu, 5 Nov 2020 06:46:15 -0800, Charles Mills wrote: >What the heck were the UNIX designers thinking when they allowed the casual >creation of a filename of -x? There may be a legitimate reason why someone >would want to create a file named -x but if so, then *they* should be made to >jump through some small hoop and "escape" the name in some way. The innocent >victim who stumbles into this situation should not be the one made to jump >through hoops. Will UNIX allow the creation of a file named "rm *"? That could >have some interesting side effects. > Even worse, a file named "-rf *". This resembles the plaint of a JCL novice who has just encountered, painfully, the astonishing behavior of: //SYSUT1 DD DSN=&SYSUID..PDS(MEMBER),DISP=(OLD,DELETE) That should be fixed for DYNALLOC, JCL, TSO, globally by making the TU for member mutex with the TU for delete. Who volunteers to bell the RFE cat? Probably there's a "dusty deck" somewhere whose inexcusably clever author relied on the behavior and whose heirs haven't access to the source. >How did I inadvertently create a file named -x? I had a pax command > >pax -wzvf /my/archive.pax * > >I had an error that I thought might be solved by -x os390. Looking at the >above command I forgot that /my/archive.pax "went with" the -f and coded > >pax -wzvf -x os390 /my/archive.pax * >... >Heck, if the shell is going to expand the * then it could generate a warning >"hey, did you know that one of your files has a name that looks just like a >switch?" > Shell doesn't know what's a file and what's a switch. That's the responsibility of the utility, even as JCL shouldn't know what PARM means: //STEP EXEC PGM=BPXBATCH,PARM='sudo rm -rf /' -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Gwyn's Maxim (was: FSUM7197 pax ...)
https://opensource.com/business/14/12/linux-philosophy On Thu, 5 Nov 2020 06:46:15 -0800, Charles Mills wrote: >What the heck were the UNIX designers thinking when they allowed the casual >creation of a filename of -x? There may be a legitimate reason why someone >would want to create a file named -x but if so, then *they* should be made to >jump through some small hoop and "escape" the name in some way. The innocent >victim who stumbles into this situation should not be the one made to jump >through hoops. Will UNIX allow the creation of a file named "rm *"? That could >have some interesting side effects. > Even worse, a file named "-rf *". This resembles the plaint of a JCL novice who has just encountered, painfully, the astonishing behavior of: //SYSUT1 DD DSN=&SYSUID..PDS(MEMBER),DISP=(OLD,DELETE) That should be fixed for DYNALLOC, JCL, TSO, globally by making the TU for member mutex with the TU for delete. Who volunteers to bell the RFE cat? Probably there's a "dusty deck" somewhere whose inexcusably clever author relied on the behavior and whose heirs haven't access to the source. >How did I inadvertently create a file named -x? I had a pax command > >pax -wzvf /my/archive.pax * > >I had an error that I thought might be solved by -x os390. Looking at the >above command I forgot that /my/archive.pax "went with" the -f and coded > >pax -wzvf -x os390 /my/archive.pax * >... >Heck, if the shell is going to expand the * then it could generate a warning >"hey, did you know that one of your files has a name that looks just like a >switch?" > Shell doesn't know what's a file and what's a switch. That's the responsibility of the utility, even as JCL shouldn't know what PARM means: //STEP EXEC PGM=BPXBATCH,PARM='sudo rm -rf /' -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DS8870 Non Encrypted Disk Drives
According to here: https://www.ibm.com/support/knowledgecenter/HW213_7.2.0/com.ibm.storage.ssic.help.doc/f2c_drivesets.html You might need feature code 1754 to deactivate encryption... Joe On Thu, Nov 5, 2020 at 10:39 AM Sonny Gupta wrote: > Hello All, I have run into a unique problem with a DS8870 that I recently > acquired. > > The DS8870 is not using encryption and when we try to replace the drives, > we are receiving following error: The DS8700 is not under IBM Maintenance. > > 2107-104 Error from Action applicationLevelActivateRepair. > Error Num is 0x102 > Error Msg is 2107-346 IBM.essSADevicesRMD:: Cryptographic erase failed on > FDE Drive Due to internal microcode errors. nRC=258 > > Recovery Action: > 1. Review the error message above, and take notes on the recommended > action if provided > 2. Do one of the following: > a. Perform the recommended action if provided > b. Retry the service action unless the error message stated > otherwise > c. Contact the next level support for assistance > > I am unable to find any information on non-encrypted disks. All the > replacement drives that I have purchased are SED (Self Encrypted Drives) > and unable to find non-SED drives. > > Any help would be appreciated. > > Regards, > Sonny Gupta > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
> -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of R.S. > Sent: Thursday, November 05, 2020 4:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > Joe, > > And I'm pretty sure no business department is interested in ACCNT field > and its content. Believe me or not: IT is a tool to achieve business > goal, but the details, guts, fields, commas are NOT in the scope of > business focus. They want working application, it is up to IT how to do > it. Changing ACCNT or classes are not strategic. > BTW: Gadi's further explanation sched more light on that. > That's why I proposed solution for real need. Not just abstract > excercise to solve. > > -- > Radoslaw Skorupka > Lodz, Poland Why would you think that? When I was working, our office had several different contracts active simultaneously. Many were "cost plus" rather than "fixed fee." It was not unusual to spend a portion of each day on different ones. We were required to daily document our time on each to the nearest tenth of an hour. Similarly, when we logged on to TSO or submitted a batch job, we were required to specify the account field that corresponded to that contract. We had an exit (IEFACTRT?) that captured this along with job statistics, such as CPU time, I/O counts, etc and cut appropriate SMF records. These formed the basis for billing the customers. It was also used by management to determine how accurate initial estimates were and then refine our process for estimating future bids. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FSUM7197 pax: invalid archive format selected
Eunix was designed for a PDP-7, and we are suffering from some of the design decisions made then. But the myth of windows being user friendly is just a myth; the reality is quite different. So, yes, z/OS suffers from some really bad decisions made decades ago, but so do the other systems. The prevalence of windows has as much to do with the monopolistic practices of ms as with anything else. BTW, to what extent has z/VSE overcome the ghastly syntax of DOS JCL? -- 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, November 5, 2020 12:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FSUM7197 pax: invalid archive format selected It's fine that UNIX is designed for professionals but (a.) some of us are professionals at many things but have to use UNIX only occasionally; and (b.) no one is born a professional. If you make it hard for folks to get started as non-professionals, then they will gravitate elsewhere and become professionals there. That may be why Windows is a lot more common choice for desktops than is UNIX. (And why z/OS is not exactly storming the marketplace. Your COND= plaint is of course legendary.) Good software design would be newbie-friendly by default, and accommodating of professionals if one so chose. The link is amusing. Thanks. I don't hate UNIX. I am not a computer religious zealot. People pay me to use computers, and I enjoy doing so for the most part, so I do. This feature of UNIX wasted an hour of my client's time. And some of your time and Gil's. And others who read the post, shook their heads, and moved on. > IBM really goofed up by not using the GNU libraries IBM does not share their thinking with me but I suspect they wanted "real" UNIX, and GNU is of course ... Not UNIX. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, November 5, 2020 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FSUM7197 pax: invalid archive format selected Caution -- tacky in-line comment. On Thu, Nov 5, 2020 at 8:46 AM Charles Mills wrote: > What the heck were the UNIX designers thinking when they allowed the > casual creation of a filename of -x? They were thinking that UNIX is for professionals who know what they're doing and didn't want to be "molly coddled" and protected from themselves. That's for Windows users. And, really, this is more an artifact of the Bourne shell, not the UNIX kernel. In fact, UNIX allows a file to have any characters in it other than 0x00. Mainly because it is written in C. That's freedom, which requires responsibility. Well, actually, UNIX probably allowed it because it was developed, I think, on a PDP-7 which was very memory constrained and so they didn't do a whole lot of coding to validate "reasonableness". You might enjoy this: https://secure-web.cisco.com/1-dM3BmUBAUH2sYYhQ2RsAvGkVtVKvvlmn3hdBcYfcSknMrTzVTPbBJFXPAESy6rTdpzcZacofe__Dg3GxMaZHSw_of1qimWxUcoewgghJarztW2FVxbiAdANmeTIfBI7nluNfkbyqgBMm5IamPVQQPiWFvvzDFDZHlurgt0gilfOoKRJdzjYkCtuej7AS_bid4n8H4E8jC4NV8RhuSBJze3KrS3qtoQqb1Lc8t1ZVyRSSBmB15KX5cdZ2TUKLeI78r-BWaEkfZWky7Sg7-yeQvjbW2YzZ9yDHOam26YNo8CIOVFPGeJgshgrw8XDVpZH2JmROkcuQBbWS4n9HSp-AQIQe2B3p3AywEmsrVL4dAmIeTQ_9oEj_p-v4ozuWJPILEiqw3BefiNi_i251bOEFFBBoo5NDhy5I5DlvHNGuG0ybZO8TwBBl_7mSxLIR2jQ/https%3A%2F%2Fweb.mit.edu%2F%7Esimsong%2Fwww%2Fugh.pdf The UNIX Haters Handbook. > There may be a legitimate reason why someone would want to create a file > named -x but if so, then *they* should be made to jump through some small > hoop and "escape" the name in some way. The innocent victim who stumbles > into this situation should not be the one made to jump through hoops. Will > UNIX allow the creation of a file named "rm *"? That could have some > interesting side effects. > Simple to do that: touch 'rm *' More "difficult" touch rm\ \* > > How did I inadvertently create a file named -x? I had a pax command > > pax -wzvf /my/archive.pax * > > I had an error that I thought might be solved by -x os390. Looking at the > above command I forgot that /my/archive.pax "went with" the -f and coded > > pax -wzvf -x os390 /my/archive.pax * > > That has the effect of creating an archive named -x. UNIX did not complain > or warn about that at all. (It complained about some unnamed file not being > found, presumably os390.) That is poor design IMHO. > Perhaps. But, then again, WAD. Or perhaps BAD. But the command did exactly what it was documented to do. Might as well complain, as I have, about the backwardness of COND= in JCL. I now only use // IF and it's friends for condition checking. > > Heck, if the shell is going to expand the * then it could generate a > warning "hey, did you know that one of your files has a name that looks > just like a switch?" > Hum, now that
Re: FSUM7197 pax: invalid archive format selected
It's fine that UNIX is designed for professionals but (a.) some of us are professionals at many things but have to use UNIX only occasionally; and (b.) no one is born a professional. If you make it hard for folks to get started as non-professionals, then they will gravitate elsewhere and become professionals there. That may be why Windows is a lot more common choice for desktops than is UNIX. (And why z/OS is not exactly storming the marketplace. Your COND= plaint is of course legendary.) Good software design would be newbie-friendly by default, and accommodating of professionals if one so chose. The link is amusing. Thanks. I don't hate UNIX. I am not a computer religious zealot. People pay me to use computers, and I enjoy doing so for the most part, so I do. This feature of UNIX wasted an hour of my client's time. And some of your time and Gil's. And others who read the post, shook their heads, and moved on. > IBM really goofed up by not using the GNU libraries IBM does not share their thinking with me but I suspect they wanted "real" UNIX, and GNU is of course ... Not UNIX. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, November 5, 2020 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FSUM7197 pax: invalid archive format selected Caution -- tacky in-line comment. On Thu, Nov 5, 2020 at 8:46 AM Charles Mills wrote: > What the heck were the UNIX designers thinking when they allowed the > casual creation of a filename of -x? They were thinking that UNIX is for professionals who know what they're doing and didn't want to be "molly coddled" and protected from themselves. That's for Windows users. And, really, this is more an artifact of the Bourne shell, not the UNIX kernel. In fact, UNIX allows a file to have any characters in it other than 0x00. Mainly because it is written in C. That's freedom, which requires responsibility. Well, actually, UNIX probably allowed it because it was developed, I think, on a PDP-7 which was very memory constrained and so they didn't do a whole lot of coding to validate "reasonableness". You might enjoy this: https://web.mit.edu/~simsong/www/ugh.pdf The UNIX Haters Handbook. > There may be a legitimate reason why someone would want to create a file > named -x but if so, then *they* should be made to jump through some small > hoop and "escape" the name in some way. The innocent victim who stumbles > into this situation should not be the one made to jump through hoops. Will > UNIX allow the creation of a file named "rm *"? That could have some > interesting side effects. > Simple to do that: touch 'rm *' More "difficult" touch rm\ \* > > How did I inadvertently create a file named -x? I had a pax command > > pax -wzvf /my/archive.pax * > > I had an error that I thought might be solved by -x os390. Looking at the > above command I forgot that /my/archive.pax "went with" the -f and coded > > pax -wzvf -x os390 /my/archive.pax * > > That has the effect of creating an archive named -x. UNIX did not complain > or warn about that at all. (It complained about some unnamed file not being > found, presumably os390.) That is poor design IMHO. > Perhaps. But, then again, WAD. Or perhaps BAD. But the command did exactly what it was documented to do. Might as well complain, as I have, about the backwardness of COND= in JCL. I now only use // IF and it's friends for condition checking. > > Heck, if the shell is going to expand the * then it could generate a > warning "hey, did you know that one of your files has a name that looks > just like a switch?" > Hum, now that might be an interesting thing to be able to do! The BASH shell has a "shopts" builtin command to set some shell options. The GNU utilities, well most of them, have a -- options which says anything which has a leading dash after the double dash is _not_ to be interpreted as an option. But that is not the shell itself. I think it is really an artifact of the GNU version of "getopt()" https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html IBM really goofed up by not using the GNU libraries, or at least their design, in z/OS UNIX. I am thinking they used base AIX. Which is hilarious because AIX has GNU ported to it and I am fairly sure every programmer uses it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FSUM7197 pax: invalid archive format selected
Let me update this a little. When I said "professional", I should have said something like "power user" in today's vernacular. The shell is a field full of mines for those who are not familiar with it. I've been using Linux for about 20 years, and I still get tripped up at times with BASH. I didn't mean to disparage Mr. Mills. He know z/OS well. But the UNIX side is hard to get used to. Like when I went from a Xerox Sigma 7 using BPM to MVT using JCL. I said many nasty things about JCL. I finally, mainly, learned it. On Thu, Nov 5, 2020 at 11:21 AM John McKown wrote: > Caution -- tacky in-line comment. > > On Thu, Nov 5, 2020 at 8:46 AM Charles Mills wrote: > >> What the heck were the UNIX designers thinking when they allowed the >> casual creation of a filename of -x? > > > They were thinking that UNIX is for professionals who know what they're > doing and didn't want to be "molly coddled" and protected from themselves. > That's for Windows users. And, really, this is more an artifact of the > Bourne shell, not the UNIX kernel. In fact, UNIX allows a file to have any > characters in it other than 0x00. Mainly because it is written in C. That's > freedom, which requires responsibility. > > Well, actually, UNIX probably allowed it because it was developed, I > think, on a PDP-7 which was very memory constrained and so they didn't do a > whole lot of coding to validate "reasonableness". > > You might enjoy this: https://web.mit.edu/~simsong/www/ugh.pdf The UNIX > Haters Handbook. > > > >> There may be a legitimate reason why someone would want to create a file >> named -x but if so, then *they* should be made to jump through some small >> hoop and "escape" the name in some way. The innocent victim who stumbles >> into this situation should not be the one made to jump through hoops. Will >> UNIX allow the creation of a file named "rm *"? That could have some >> interesting side effects. >> > > Simple to do that: > > touch 'rm *' > > More "difficult" > > touch rm\ \* > > >> >> How did I inadvertently create a file named -x? I had a pax command >> >> pax -wzvf /my/archive.pax * >> >> I had an error that I thought might be solved by -x os390. Looking at the >> above command I forgot that /my/archive.pax "went with" the -f and coded >> >> pax -wzvf -x os390 /my/archive.pax * >> >> That has the effect of creating an archive named -x. UNIX did not >> complain or warn about that at all. (It complained about some unnamed file >> not being found, presumably os390.) That is poor design IMHO. >> > > Perhaps. But, then again, WAD. Or perhaps BAD. But the command did exactly > what it was documented to do. Might as well complain, as I have, about the > backwardness of COND= in JCL. I now only use // IF and it's friends for > condition checking. > > > >> >> Heck, if the shell is going to expand the * then it could generate a >> warning "hey, did you know that one of your files has a name that looks >> just like a switch?" >> > > Hum, now that might be an interesting thing to be able to do! The BASH > shell has a "shopts" builtin command to set some shell options. The GNU > utilities, well most of them, have a -- options which says anything which > has a leading dash after the double dash is _not_ to be interpreted as an > option. But that is not the shell itself. I think it is really an artifact > of the GNU version of "getopt()" > https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html > > IBM really goofed up by not using the GNU libraries, or at least their > design, in z/OS UNIX. I am thinking they used base AIX. Which is > hilarious because AIX has GNU ported to it and I am fairly sure every > programmer uses it. > > >> >> Charles >> >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FSUM7197 pax: invalid archive format selected
Caution -- tacky in-line comment. On Thu, Nov 5, 2020 at 8:46 AM Charles Mills wrote: > What the heck were the UNIX designers thinking when they allowed the > casual creation of a filename of -x? They were thinking that UNIX is for professionals who know what they're doing and didn't want to be "molly coddled" and protected from themselves. That's for Windows users. And, really, this is more an artifact of the Bourne shell, not the UNIX kernel. In fact, UNIX allows a file to have any characters in it other than 0x00. Mainly because it is written in C. That's freedom, which requires responsibility. Well, actually, UNIX probably allowed it because it was developed, I think, on a PDP-7 which was very memory constrained and so they didn't do a whole lot of coding to validate "reasonableness". You might enjoy this: https://web.mit.edu/~simsong/www/ugh.pdf The UNIX Haters Handbook. > There may be a legitimate reason why someone would want to create a file > named -x but if so, then *they* should be made to jump through some small > hoop and "escape" the name in some way. The innocent victim who stumbles > into this situation should not be the one made to jump through hoops. Will > UNIX allow the creation of a file named "rm *"? That could have some > interesting side effects. > Simple to do that: touch 'rm *' More "difficult" touch rm\ \* > > How did I inadvertently create a file named -x? I had a pax command > > pax -wzvf /my/archive.pax * > > I had an error that I thought might be solved by -x os390. Looking at the > above command I forgot that /my/archive.pax "went with" the -f and coded > > pax -wzvf -x os390 /my/archive.pax * > > That has the effect of creating an archive named -x. UNIX did not complain > or warn about that at all. (It complained about some unnamed file not being > found, presumably os390.) That is poor design IMHO. > Perhaps. But, then again, WAD. Or perhaps BAD. But the command did exactly what it was documented to do. Might as well complain, as I have, about the backwardness of COND= in JCL. I now only use // IF and it's friends for condition checking. > > Heck, if the shell is going to expand the * then it could generate a > warning "hey, did you know that one of your files has a name that looks > just like a switch?" > Hum, now that might be an interesting thing to be able to do! The BASH shell has a "shopts" builtin command to set some shell options. The GNU utilities, well most of them, have a -- options which says anything which has a leading dash after the double dash is _not_ to be interpreted as an option. But that is not the shell itself. I think it is really an artifact of the GNU version of "getopt()" https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html IBM really goofed up by not using the GNU libraries, or at least their design, in z/OS UNIX. I am thinking they used base AIX. Which is hilarious because AIX has GNU ported to it and I am fairly sure every programmer uses it. > > Charles > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DS8870 Non Encrypted Disk Drives
Hello All, I have run into a unique problem with a DS8870 that I recently acquired. The DS8870 is not using encryption and when we try to replace the drives, we are receiving following error: The DS8700 is not under IBM Maintenance. 2107-104 Error from Action applicationLevelActivateRepair. Error Num is 0x102 Error Msg is 2107-346 IBM.essSADevicesRMD:: Cryptographic erase failed on FDE Drive Due to internal microcode errors. nRC=258 Recovery Action: 1. Review the error message above, and take notes on the recommended action if provided 2. Do one of the following: a. Perform the recommended action if provided b. Retry the service action unless the error message stated otherwise c. Contact the next level support for assistance I am unable to find any information on non-encrypted disks. All the replacement drives that I have purchased are SED (Self Encrypted Drives) and unable to find non-SED drives. Any help would be appreciated. Regards, Sonny Gupta -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
Step 1 I would put the default CLASS= in every job. Easier to change the default than add a new line. On Thu, Nov 5, 2020 at 6:09 AM R.S. wrote: > > Now we know more. Maybe still not enough ;-) > However we may assume: > a) there is finite number of the jobs > b) you know all the jobs - that means all PDS/PDSE's with the jobs. No > secret libraries, no forgotten user libraries, etc. > c) the jobs are not generated dynamically by some "black box" tool, so > all the jobs are known. > d) jobs have accnt field with some known/documented format and its > content clearly tell you which class to use (let's simplify it to just > jobclasses A, B, C - good, better, the best) > > In such scenario I would think about mass change. > Simply, for any job with ACCNT containing GOOD place CLASS=A. For any > job with ACCNT containing BTTR place CLASS=B, and for each job with BEST > place CLASS=C. > > Note: it doesn't matter whether you have 100, 1000 or 1 jobs. > OK, for 100 jobs it is still feasible to change it manually. ;-) > > Note2: Since the jobs are already in production, with NO classes, there > is no big problem to change it gradually. Even "forgotten" libraries can > be changed later, when detected. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 05.11.2020 o 06:21, Gadi Ben-Avi pisze: > > Hi Everone. > > Thanks for responding. > > > > We 'purchased' a system from another site. > > The jobs that came with the system do not have a CLASS parameter specified. > > They do have specific values in the accounting fields that are supposed to > > assign the job to specific classes. > > I assume they had an exit that did all of this. > > > > Up until now, all of the jobs ran in the same class, with the same service > > class. > > I've been asked to assign a lower service class to jobs that have a > > specific (not specified as yet) value in the accounting data. > > > > The simplest way would have been to tell the job owners to code a CLASS > > parameter on the JOB card, but they say that that is too much work. > > > > I looked at doing this using WLM definitions. > > It works if the value in the accounting data is in the first 8 bytes. > > Otherwise, it get complicated to write, debug, and read. > > > > I read about JES2 Policies, so I looked it up in the documentation. > > > > Gadi > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > Jesse 1 Robinson > > Sent: Wednesday, November 4, 2020 10:05 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: JES2 Policies > > > > In a previous life at the late great Security Pacific, we an *elaborate* > > scheme based on account numbers. Even the job name was generated from > > account number. To control all this, we had a VSAM file containing all > > valid account numbers along with indications of who could submit jobs with > > each number. An array of JES2 and SMF exits were employed to make all this > > work. At the end of the year, account numbers were used for chargeback to > > respective departments for resource usage. > > > > There is no way in h*ll I would recommend this complex scheme for a modern > > shop. But yes, with enough time and $$, it can be done. > > > > . > > . > > 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 > > Lizette Koehler > > Sent: Wednesday, November 4, 2020 10:53 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: JES2 Policies > > > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > > > Initial Request: > > The current goal is to change a job's class or service class depending on > > certain values in the accounting information. > > > > It also seems to me that a JCL tool, Like JCLPLUS could put rules into JCL > > Scanning and force users to adhere to a standard. But that would mean you > > have a Source management system that is used to deploy Jobs to various > > systems. > > > > It could have rules that say, if Account Code is this, then the job should > > have Service Class STCLOW and CLASS X > > > > > > Lizette > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > Allan Staller > > Sent: Wednesday, November 4, 2020 11:35 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: JES2 Policies > > > > Wouldn't RACF jobclass controls be more appropriate? > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > Joe Monk > > Sent: Wednesday, November 4, 2020 10:31 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: JES2 Policies > > > > [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 I
Re: FSUM7197 pax: invalid archive format selected
What the heck were the UNIX designers thinking when they allowed the casual creation of a filename of -x? There may be a legitimate reason why someone would want to create a file named -x but if so, then *they* should be made to jump through some small hoop and "escape" the name in some way. The innocent victim who stumbles into this situation should not be the one made to jump through hoops. Will UNIX allow the creation of a file named "rm *"? That could have some interesting side effects. How did I inadvertently create a file named -x? I had a pax command pax -wzvf /my/archive.pax * I had an error that I thought might be solved by -x os390. Looking at the above command I forgot that /my/archive.pax "went with" the -f and coded pax -wzvf -x os390 /my/archive.pax * That has the effect of creating an archive named -x. UNIX did not complain or warn about that at all. (It complained about some unnamed file not being found, presumably os390.) That is poor design IMHO. Heck, if the shell is going to expand the * then it could generate a warning "hey, did you know that one of your files has a name that looks just like a switch?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, November 4, 2020 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FSUM7197 pax: invalid archive format selected On Wed, 4 Nov 2020 16:30:35 -0800, Charles Mills wrote: >No, I was trying to archive the current directory, and it contained a file >named -x (created accidentally) and the next folder is named 'foldername' (per >my original post). > >John is saying that the shell expands the folders recursively, so pax sees pax >blah blah -x foldername ... > >And says foldername is an invalid operand for -x. > >Comprende? > I understand; I'm merely astonished that pax uses shell filename expansion to build a command line which is passed to pax as a list of individual filenames. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: gskkyman & public key
Skippy, a number of misapprehensions in there. A certificate never "consists of a public and private key." A certificate contains a public key, and somewhere there is a corresponding private key. A PKCS12 package may contain both the certificate and the private key, but a certificate itself never contains a private key. No, the "public key" per se is not installed anywhere. If the FTP server will be presenting a server certificate, then the root certificate of the CA that signed that certificate must be installed and trusted on the client machine. (If the server certificate is self-signed, then it is its own CA, and it must be pre-installed and trusted on the client.) "When looking at a directory of certs, how can I find the public one?" is not a question that has an answer. "Public cert" is not a generally recognized concept. There are many, many ways that one might create a certificate, but the most common sort of approach would be (1) using gskkyman or RACF to create a certificate signing request, and then having (a.) a public CA who will charge you money; or (b.) PKI services run by your shop to sign it and issue a certificate; or (2) using RACF or gskkyman to create a self-signed certificate. Self-signed certificates are a whole topic of their own, but briefly, the plus is that they are free and easy; the minus is that they enjoy a certain amount of ill repute and will not be suitable in many scenarios. If you are going to be your own certificate expert then I think you need to start with some general education on how the certificate process works, and then proceed from there to specific, detailed questions on this list. There are a number of SHARE presentations that would be a starting point, or the RACF Sec Admin Guide, or perhaps one of the Redbooks. Otherwise you will need to retain the services of such an expert. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skippy the Ancient Sent: Thursday, November 5, 2020 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: gskkyman & public key I am asking in regards to FTPS. I know gskkyman can create/import/export certs. The cert consists of a public and private key. I'm asking because it's my understanding that the public key should be loaded up and installed on a client computer. Is that correct? When looking at a directory full of certs, how can I find the public one? Or how do I create it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: gskkyman & public key
Sorry FTPS - x.509 certs need to be exchanged and loaded onto the RACF keyring specified in the TLS rule in PAGENT and if you have client auth enabled the cert will need to be on the client PC/Device also -Original Message- From: IBM Mainframe Discussion List On Behalf Of Marshall Stone Sent: Thursday, November 5, 2020 9:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: gskkyman & public key Public keys need to be exchanged between partners - client stores it usually in a file called /etc/ssh/known_hosts - server stores public key in /u/userid/.ssh/authorized_keys MS -Original Message- From: IBM Mainframe Discussion List On Behalf Of Skippy the Ancient Sent: Thursday, November 5, 2020 9:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: gskkyman & public key I am asking in regards to FTPS. I know gskkyman can create/import/export certs. The cert consists of a public and private key. I'm asking because it's my understanding that the public key should be loaded up and installed on a client computer. Is that correct? When looking at a directory full of certs, how can I find the public one? Or how do I create it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: gskkyman & public key
Public keys need to be exchanged between partners - client stores it usually in a file called /etc/ssh/known_hosts - server stores public key in /u/userid/.ssh/authorized_keys MS -Original Message- From: IBM Mainframe Discussion List On Behalf Of Skippy the Ancient Sent: Thursday, November 5, 2020 9:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: gskkyman & public key I am asking in regards to FTPS. I know gskkyman can create/import/export certs. The cert consists of a public and private key. I'm asking because it's my understanding that the public key should be loaded up and installed on a client computer. Is that correct? When looking at a directory full of certs, how can I find the public one? Or how do I create it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: gskkyman & public key
I am asking in regards to FTPS. I know gskkyman can create/import/export certs. The cert consists of a public and private key. I'm asking because it's my understanding that the public key should be loaded up and installed on a client computer. Is that correct? When looking at a directory full of certs, how can I find the public one? Or how do I create it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE holddata comparing 2 different CSIs
On 11/4/2020 12:35 PM, Bill Giannelli wrote: We have software at 2 different maintenance levels, with separate CSIs and zones. Is there a report I can run to compare the maintenance levels and get the holddata needed for the "higher level" maintenance? I hope my question makes sense. thanks Bill The SMP/E REPORT SYSMODS command is what you want (watch the wrap): https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.gim1000/rptsys.htm This command produces two reports: 1. SYSMOD Comparison report, identifying SYSMODs in the input zone but not in the comparison zone. 2. SYSMOD Comparison HOLDDATA report, identifying the SYSTEM and USER HOLDs for the SYSMODs identified in the other report. These are the HOLDs you need to review and resolve when upgrading the comparison zone with the input zone. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Documentation for environment of EXCP appendages
That was the first place I looked. It mentions key 0 and supervisor mode, but no more. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Myers [m...@mentor-services.com] Sent: Thursday, November 5, 2020 3:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Documentation for environment of EXCP appendages Seymour: I found there is documentation online. I searched for: IBM z/OS EXCP appendage and came back with a hit: EXCP and EXCPVR Appendages in z/OS DFSMSdfp Advanced Services It has been several years, but I have explored use of the appendages dating back to OS/360, where I used to teach the internals of ISAM and BDAM to PSRs. The neatest use was PCI, where the interrupt coming from a specific CCW in a channel program notified the appendage of the point where the channel program was executing and the appendage could make changes to the channel program in response. In general, the appendage could choose to let the channel program end or could add more CCWs to the channel program to continue the I/O operation in response to new information obtained in data read or in response to new related requests from system activity. The main usage was "self modifying channel programs" as in ISAM and BDAM and in "seldom ending channel programs" more recently in ASM, where a channel program already running and performing paging I/O could add new page I/O to the running channel program as more page in or page out requests occurred. Mike Myers On 11/4/20 10:52 PM, Seymour J Metz wrote: > I'm editing the wiki article on EXCP, and I'd like to correct what it says > about appendages. I couldn't find any documentation on the environment in > which appendages run, although I'm fairly certain that it's PASN, SRB and all > the usual suspects. Wiki politics being what they are, it's a lot easier if I > provide a citation for everything. > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
Part of real need is complying with lawful management edicts, even when they are not wise. You have an obligation to point out the problems, but if management wants to do it regardless, then you must shut up and code. Of course, in that situation it is prudent to retain an audit trail showing that you did object. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of R.S. [r.skoru...@bremultibank.com.pl] Sent: Thursday, November 5, 2020 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Joe, This is not my call (honestly I don't know this idiom). This is not my dog, this is not my business. I can leave it with no answer, but my willing is to help. And part of the help is not to just code the exit, but discuss about solution. And I'm pretty sure no business department is interested in ACCNT field and its content. Believe me or not: IT is a tool to achieve business goal, but the details, guts, fields, commas are NOT in the scope of business focus. They want working application, it is up to IT how to do it. Changing ACCNT or classes are not strategic. BTW: Gadi's further explanation sched more light on that. That's why I proposed solution for real need. Not just abstract excercise to solve. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 13:05, Joe Monk pisze: > "However I think it not valid > requirement, there is no business need behind it." > > Thats not your call to make. They are entitled to run their business how > they see fit. > > Joe > > On Thu, Nov 5, 2020 at 5:53 AM R.S. wrote: > >> W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: >>> Can RACF see the account code and make a decision? >> Obviously not. RACF is also unable to see submitters trousers, check how >> many days left to nearest holiday, etc. >> >>> That is what (as I understand it) the initial requirement is. >> Yes, that requirement was presented to us. However I think it not valid >> requirement, there is no business need behind it. >> It is more complex: some reasonable business need led to use accnt. And >> this is worth to discuss IMHO. Or just go back to business need and >> discuss how to satisfy it. To avoid Rube Goldberg machinery. >> >> >> -- >> Radoslaw Skorupka >> Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,http://secure-web.cisco.com/1yUJH6CPVdYQVq1v6JcA0Qu8ySvxWpkIbN6z7Tlu1aYl5APLNz8vZBPxnDa839idcMCNIuAs3xGzchKO1lvL1WGWj2HiJ-i5fXxxBuV4fU8rAfJDBOMVbqBknEoKQKR6Xt5IFQgCiWhA4zIENjWrPFsrXStD1r7YrAMtxNh-1S3lU-pqBwrKxvoSQ2Ed1IHUen44QAPRg79znKQwYd-xz9LItjPRi4_KwhtWnUw90CGs5KDjrd9DKfcLG_xFzLhGj8khxj42aw8tI6CuFYmjyvsdOJeRqNL_DVJoY-sDntRa6SLX3Z3T4nxIin_G0n7Gs1jfohhkReYNyQ2whaEPePb_sB92872FuxoW1dDv27chJDrgnYPwWooRQKWbDsrwac_O5AZHwPezwr3TWzU8Gwz5shBs785GBHx2xRSBnHFK3U1JkLfqHKN-ZJ9rvCsuaXTy5y3P0u4c2NaFKuBKWJg/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.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,http://secure-web.cisco.com/1yUJH6CPVdYQVq1v6JcA0Qu8ySvxWpkIbN6z7Tlu1aYl5APLNz8vZBPxnDa839idcMCNIuAs3xGzchKO1lvL1WGWj2HiJ-i5fXxxBuV4fU8rAfJDBOMVbqBknEoKQKR6Xt5IFQgCiWhA4zIENjWrPFsrXStD1r7YrAMtxNh-1S3lU-pqBwrKxvoSQ2Ed1IHUen44QAPRg79znKQwYd-xz9LItjPRi4_KwhtWnUw90CGs5KDjrd9DKfcLG_xFzLhGj8khxj42aw8tI6CuFYmjyvsdOJeRqNL_DVJoY-sDntRa6SLX3Z3T4nxIin_G0n7Gs1jfohhkReYNyQ2whaEPePb_sB92872FuxoW1dDv27chJDrgnYPwWooRQKWbDsrwac_O5AZHwPezwr3TWzU8Gwz5shBs785GBHx2xRSBnHFK3U1JkLfqHKN-ZJ9rvCsuaXTy5y3P0u4c2NaFKuBKWJg/http%3A%2F%2Fwww.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
Re: JES2 Policies
Joe, This is not my call (honestly I don't know this idiom). This is not my dog, this is not my business. I can leave it with no answer, but my willing is to help. And part of the help is not to just code the exit, but discuss about solution. And I'm pretty sure no business department is interested in ACCNT field and its content. Believe me or not: IT is a tool to achieve business goal, but the details, guts, fields, commas are NOT in the scope of business focus. They want working application, it is up to IT how to do it. Changing ACCNT or classes are not strategic. BTW: Gadi's further explanation sched more light on that. That's why I proposed solution for real need. Not just abstract excercise to solve. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 13:05, Joe Monk pisze: "However I think it not valid requirement, there is no business need behind it." Thats not your call to make. They are entitled to run their business how they see fit. Joe On Thu, Nov 5, 2020 at 5:53 AM R.S. wrote: W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: Can RACF see the account code and make a decision? Obviously not. RACF is also unable to see submitters trousers, check how many days left to nearest holiday, etc. That is what (as I understand it) the initial requirement is. Yes, that requirement was presented to us. However I think it not valid requirement, there is no business need behind it. It is more complex: some reasonable business need led to use accnt. And this is worth to discuss IMHO. Or just go back to business need and discuss how to satisfy it. To avoid Rube Goldberg machinery. -- Radoslaw Skorupka Lodz, Poland == 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: JES2 Policies
Now we know more. Maybe still not enough ;-) However we may assume: a) there is finite number of the jobs b) you know all the jobs - that means all PDS/PDSE's with the jobs. No secret libraries, no forgotten user libraries, etc. c) the jobs are not generated dynamically by some "black box" tool, so all the jobs are known. d) jobs have accnt field with some known/documented format and its content clearly tell you which class to use (let's simplify it to just jobclasses A, B, C - good, better, the best) In such scenario I would think about mass change. Simply, for any job with ACCNT containing GOOD place CLASS=A. For any job with ACCNT containing BTTR place CLASS=B, and for each job with BEST place CLASS=C. Note: it doesn't matter whether you have 100, 1000 or 1 jobs. OK, for 100 jobs it is still feasible to change it manually. ;-) Note2: Since the jobs are already in production, with NO classes, there is no big problem to change it gradually. Even "forgotten" libraries can be changed later, when detected. -- Radoslaw Skorupka Lodz, Poland W dniu 05.11.2020 o 06:21, Gadi Ben-Avi pisze: Hi Everone. Thanks for responding. We 'purchased' a system from another site. The jobs that came with the system do not have a CLASS parameter specified. They do have specific values in the accounting fields that are supposed to assign the job to specific classes. I assume they had an exit that did all of this. Up until now, all of the jobs ran in the same class, with the same service class. I've been asked to assign a lower service class to jobs that have a specific (not specified as yet) value in the accounting data. The simplest way would have been to tell the job owners to code a CLASS parameter on the JOB card, but they say that that is too much work. I looked at doing this using WLM definitions. It works if the value in the accounting data is in the first 8 bytes. Otherwise, it get complicated to write, debug, and read. I read about JES2 Policies, so I looked it up in the documentation. Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Wednesday, November 4, 2020 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies In a previous life at the late great Security Pacific, we an *elaborate* scheme based on account numbers. Even the job name was generated from account number. To control all this, we had a VSAM file containing all valid account numbers along with indications of who could submit jobs with each number. An array of JES2 and SMF exits were employed to make all this work. At the end of the year, account numbers were used for chargeback to respective departments for resource usage. There is no way in h*ll I would recommend this complex scheme for a modern shop. But yes, with enough time and $$, it can be done. . . 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 Lizette Koehler Sent: Wednesday, November 4, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JES2 Policies *** EXTERNAL EMAIL - Use caution when opening links or attachments *** Initial Request: The current goal is to change a job's class or service class depending on certain values in the accounting information. It also seems to me that a JCL tool, Like JCLPLUS could put rules into JCL Scanning and force users to adhere to a standard. But that would mean you have a Source management system that is used to deploy Jobs to various systems. It could have rules that say, if Account Code is this, then the job should have Service Class STCLOW and CLASS X Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Wednesday, November 4, 2020 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Wouldn't RACF jobclass controls be more appropriate? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 4, 2020 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies [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.] Radoslaw, I think what the OP is really saying is that certain accounts should be restricted from certain jobclasses i.e. DEV cant use PROD jobclasses. So, if they code a CLASS=X, but the account info says that they dont have access to CLASS=X, then dump the job. OP: This has been around a long time, and is very mature... Joe On Wed, Nov 4, 2020 at 8:20 AM R.S. wrote: W dniu 04.11.2020 o 13:10, Gadi Ben-Avi pisze: Hi, I've started looking into JES2 Policies. The current goal is to change a job's class
Re: JES2 Policies
"However I think it not valid requirement, there is no business need behind it." Thats not your call to make. They are entitled to run their business how they see fit. Joe On Thu, Nov 5, 2020 at 5:53 AM R.S. wrote: > W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: > > Can RACF see the account code and make a decision? > Obviously not. RACF is also unable to see submitters trousers, check how > many days left to nearest holiday, etc. > > > That is what (as I understand it) the initial requirement is. > Yes, that requirement was presented to us. However I think it not valid > requirement, there is no business need behind it. > It is more complex: some reasonable business need led to use accnt. And > this is worth to discuss IMHO. Or just go back to business need and > discuss how to satisfy it. To avoid Rube Goldberg machinery. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > == > > 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: JES2 Policies
W dniu 04.11.2020 o 19:50, Lizette Koehler pisze: Can RACF see the account code and make a decision? Obviously not. RACF is also unable to see submitters trousers, check how many days left to nearest holiday, etc. That is what (as I understand it) the initial requirement is. Yes, that requirement was presented to us. However I think it not valid requirement, there is no business need behind it. It is more complex: some reasonable business need led to use accnt. And this is worth to discuss IMHO. Or just go back to business need and discuss how to satisfy it. To avoid Rube Goldberg machinery. -- Radoslaw Skorupka Lodz, Poland == 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: JES2 Policies
W dniu 04.11.2020 o 19:29, Lizette Koehler pisze: [...] I worked in a shop with over 500 exits in JES2/zOS/Vtam etc... Each upgrade took longer to do - basically do to validation of the code. One upgrade we decided to reduce that down and let the system perform its own functions. Went down to 30 exits and the systems worked just fine and upgrade times were faster. More than 500 exits? Well, I would have a problem to point where the exits are implemented. Not to explain the reasons. -- Radoslaw Skorupka Lodz, Poland == 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: Documentation for environment of EXCP appendages
Seymour: I found this also which shows an example of a seldom-ending channel program, used in a communications function. Channel program for HPDT MPC data transfer z/OS Communications Server: SNA Diagnosis Vol 1, Techniques and Procedures Pretty cool. Thanks for this jogging my memory regarding stuff I had not thought about recently. Mike Myers On 11/4/20 10:52 PM, Seymour J Metz wrote: I'm editing the wiki article on EXCP, and I'd like to correct what it says about appendages. I couldn't find any documentation on the environment in which appendages run, although I'm fairly certain that it's PASN, SRB and all the usual suspects. Wiki politics being what they are, it's a lot easier if I provide a citation for everything. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
Probably using an exit, or maybe more than one. -Original Message- From: IBM Mainframe Discussion List On Behalf Of kekronbekron Sent: Thursday, November 5, 2020 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Policies Is it an option to ask how they managed this in the source site? - KB ‐‐‐ Original Message ‐‐‐ On Thursday, November 5, 2020 10:51 AM, Gadi Ben-Avi wrote: > Hi Everone. > Thanks for responding. > > We 'purchased' a system from another site. > The jobs that came with the system do not have a CLASS parameter specified. > They do have specific values in the accounting fields that are supposed to > assign the job to specific classes. > I assume they had an exit that did all of this. > > Up until now, all of the jobs ran in the same class, with the same service > class. > I've been asked to assign a lower service class to jobs that have a specific > (not specified as yet) value in the accounting data. > > The simplest way would have been to tell the job owners to code a CLASS > parameter on the JOB card, but they say that that is too much work. > > I looked at doing this using WLM definitions. > It works if the value in the accounting data is in the first 8 bytes. > Otherwise, it get complicated to write, debug, and read. > > I read about JES2 Policies, so I looked it up in the documentation. > > Gadi > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Jesse 1 Robinson > Sent: Wednesday, November 4, 2020 10:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > In a previous life at the late great Security Pacific, we an elaborate scheme > based on account numbers. Even the job name was generated from account > number. To control all this, we had a VSAM file containing all valid account > numbers along with indications of who could submit jobs with each number. An > array of JES2 and SMF exits were employed to make all this work. At the end > of the year, account numbers were used for chargeback to respective > departments for resource usage. > > There is no way in h*ll I would recommend this complex scheme for a modern > shop. But yes, with enough time and $$, it can be done. > > . > . > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Lizette Koehler > Sent: Wednesday, November 4, 2020 10:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: JES2 Policies > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > Initial Request: > The current goal is to change a job's class or service class depending on > certain values in the accounting information. > > It also seems to me that a JCL tool, Like JCLPLUS could put rules into JCL > Scanning and force users to adhere to a standard. But that would mean you > have a Source management system that is used to deploy Jobs to various > systems. > > It could have rules that say, if Account Code is this, then the job > should have Service Class STCLOW and CLASS X > > Lizette > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Allan Staller > Sent: Wednesday, November 4, 2020 11:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > Wouldn't RACF jobclass controls be more appropriate? > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Joe Monk > Sent: Wednesday, November 4, 2020 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > [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.] > > Radoslaw, > > I think what the OP is really saying is that certain accounts should be > restricted from certain jobclasses i.e. DEV cant use PROD jobclasses. So, if > they code a CLASS=X, but the account info says that they dont have access to > CLASS=X, then dump the job. > > OP: This has been around a long time, and is very mature... > > Joe > > On Wed, Nov 4, 2020 at 8:20 AM R.S. r.skoru...@bremultibank.com.pl wrote: > > > W dniu 04.11.2020 o 13:10, Gadi Ben-Avi pisze: > > > > > Hi, > > > I've started looking into JES2 Policies. > > > The current goal is to change a job's class or service class > > > depending on certain values in the accounting information. > > > > > > > From reading the manual, it seems that this is possible. > > > > > > Has anyone done something like this? > > > Is there a way to debug these policies? > > > Is this feature mature enough to use? > > > > I dare to disagree ...with your goal. More precisely I disagree with > > your pres
Re: JES2 Policies
Is it an option to ask how they managed this in the source site? - KB ‐‐‐ Original Message ‐‐‐ On Thursday, November 5, 2020 10:51 AM, Gadi Ben-Avi wrote: > Hi Everone. > Thanks for responding. > > We 'purchased' a system from another site. > The jobs that came with the system do not have a CLASS parameter specified. > They do have specific values in the accounting fields that are supposed to > assign the job to specific classes. > I assume they had an exit that did all of this. > > Up until now, all of the jobs ran in the same class, with the same service > class. > I've been asked to assign a lower service class to jobs that have a specific > (not specified as yet) value in the accounting data. > > The simplest way would have been to tell the job owners to code a CLASS > parameter on the JOB card, but they say that that is too much work. > > I looked at doing this using WLM definitions. > It works if the value in the accounting data is in the first 8 bytes. > Otherwise, it get complicated to write, debug, and read. > > I read about JES2 Policies, so I looked it up in the documentation. > > Gadi > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Jesse 1 Robinson > Sent: Wednesday, November 4, 2020 10:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > In a previous life at the late great Security Pacific, we an elaborate scheme > based on account numbers. Even the job name was generated from account > number. To control all this, we had a VSAM file containing all valid account > numbers along with indications of who could submit jobs with each number. An > array of JES2 and SMF exits were employed to make all this work. At the end > of the year, account numbers were used for chargeback to respective > departments for resource usage. > > There is no way in h*ll I would recommend this complex scheme for a modern > shop. But yes, with enough time and $$, it can be done. > > . > . > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Lizette Koehler > Sent: Wednesday, November 4, 2020 10:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: JES2 Policies > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > Initial Request: > The current goal is to change a job's class or service class depending on > certain values in the accounting information. > > It also seems to me that a JCL tool, Like JCLPLUS could put rules into JCL > Scanning and force users to adhere to a standard. But that would mean you > have a Source management system that is used to deploy Jobs to various > systems. > > It could have rules that say, if Account Code is this, then the job should > have Service Class STCLOW and CLASS X > > Lizette > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Allan Staller > Sent: Wednesday, November 4, 2020 11:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > Wouldn't RACF jobclass controls be more appropriate? > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Joe > Monk > Sent: Wednesday, November 4, 2020 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: JES2 Policies > > [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.] > > Radoslaw, > > I think what the OP is really saying is that certain accounts should be > restricted from certain jobclasses i.e. DEV cant use PROD jobclasses. So, if > they code a CLASS=X, but the account info says that they dont have access to > CLASS=X, then dump the job. > > OP: This has been around a long time, and is very mature... > > Joe > > On Wed, Nov 4, 2020 at 8:20 AM R.S. r.skoru...@bremultibank.com.pl wrote: > > > W dniu 04.11.2020 o 13:10, Gadi Ben-Avi pisze: > > > > > Hi, > > > I've started looking into JES2 Policies. > > > The current goal is to change a job's class or service class > > > depending > > > on certain values in the accounting information. > > > > > > > From reading the manual, it seems that this is possible. > > > > > > Has anyone done something like this? > > > Is there a way to debug these policies? > > > Is this feature mature enough to use? > > > > I dare to disagree ...with your goal. More precisely I disagree with > > your presentation of the goal. > > Does it really have to depend on account information? Why? > > That means user has to code something in the jobcard, in the first > > positional. So he may code CLASS= keyword as well, can't he? > > Maybe your accn
Re: Documentation for environment of EXCP appendages
Seymour: I found there is documentation online. I searched for: IBM z/OS EXCP appendage and came back with a hit: EXCP and EXCPVR Appendages in z/OS DFSMSdfp Advanced Services It has been several years, but I have explored use of the appendages dating back to OS/360, where I used to teach the internals of ISAM and BDAM to PSRs. The neatest use was PCI, where the interrupt coming from a specific CCW in a channel program notified the appendage of the point where the channel program was executing and the appendage could make changes to the channel program in response. In general, the appendage could choose to let the channel program end or could add more CCWs to the channel program to continue the I/O operation in response to new information obtained in data read or in response to new related requests from system activity. The main usage was "self modifying channel programs" as in ISAM and BDAM and in "seldom ending channel programs" more recently in ASM, where a channel program already running and performing paging I/O could add new page I/O to the running channel program as more page in or page out requests occurred. Mike Myers On 11/4/20 10:52 PM, Seymour J Metz wrote: I'm editing the wiki article on EXCP, and I'd like to correct what it says about appendages. I couldn't find any documentation on the environment in which appendages run, although I'm fairly certain that it's PASN, SRB and all the usual suspects. Wiki politics being what they are, it's a lot easier if I provide a citation for everything. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- 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
