Re: USS Continuation (Was Coptying Unix Files)
Like this with the + sign: oshell cp -p /usr/lpp/cics_test/utill/ + /usr/lpp/cics_prod/utill/ _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Monday, August 19, 2013 8:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: USS Continuation (Was Coptying Unix Files) Last week there was a thread that discussed copying USS files in batch mode. One of the examples posted was: //OSHELL JOB CLASS=A,MSGCLASS=A //UNIXIVP EXEC PGM=IKJEFT1B,DYNAMNBR=20 //SYSPROC DD DISP=SHR,DSN=SYS1.CLIST //SYSTSIN DD DATA,DLM=$$ oshell cp -p /service1/ABC* /service2/testdir/ $$ //SYSTSPRT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSINDD DUMMY // My question is what is the proper method to continue a command across input lines when hhe command itself exceeds the physical length of the input If I specify oshell cp -p /usr/lpp/cics_test/utill/ /usr/lpp/cics_prod/utill/ How do I properly continue the copy statement when it wraps the length of the 80 position input ? Is there a continuation character ? Paul D'Angelo * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MGET ERROR
The ftp commands provided by IBM below once worked with zos1.11 but now on zos1.13 it does not, can't be 100% sure but I believe that's when it stopped working. I did the upgrade from 1.11 to 1.13 so I know there were no changes made to the TCPIP config files. I tried adding in keyword SITE LISTSUBDIR but I got the same error. What I have to do to get the files is modify the commands to cd into SMPPTFIN and SMPHOLD and do a get on the file in each folder. What am I missing here? tks Matt cd 2013081959238/PROD lcd /u/st1mat/IBM/ binary lmkdir U01302168 lmkdir U01302168/SMPPTFIN lmkdir U01302168/SMPHOLD lcd U01302168 mget * (REPLACE lcd SMPPTFIN mget SMPPTFIN/* (REPLACE lcd ../SMPHOLD mget SMPHOLD/* (REPLACE quit /* EZA1736I cd 2013081959238/PROD EZA1701I CWD 2013081959238/PROD 250 CWD command successful. EZA1460I Command: EZA1736I lcd /u/st1mat/IBM/ EZA2581I HFS directory /u/st1mat/IBM/ is the current working directory. EZA1460I Command: EZA1736I binary EZA1701I TYPE I 200 Type set to I. EZA1460I Command: EZA1736I lmkdir U01302168 EZA2593I HFS directory /u/st1mat/IBM/U01302168 created. EZA1460I Command: EZA1736I lmkdir U01302168/SMPPTFIN EZA2593I HFS directory /u/st1mat/IBM/U01302168/SMPPTFIN created. EZA1460I Command: EZA1736I lmkdir U01302168/SMPHOLD EZA2593I HFS directory /u/st1mat/IBM/U01302168/SMPHOLD created. EZA1460I Command: EZA1736I lcd U01302168 EZA2581I HFS directory /u/st1mat/IBM/U01302168 is the current working directory. EZA1460I Command: EZA1736I mget * (REPLACE EZA1701I TYPE A 200 Type set to A. EZA1701I PORT 27,1,39,74,4,141 200 PORT command successful. EZA1701I NLST * 150 Opening ASCII mode data connection for file list. 226 Transfer complete. EZA1701I TYPE I 200 Type set to I. EZA1701I PORT 27,1,39,74,4,142 200 PORT command successful. EZA1701I RETR GIMPAF.XML 150 Opening BINARY mode data connection for GIMPAF.XML. 226 Transfer complete. EZA1617I 2720 bytes transferred in 0.270 seconds. Transfer rate 10.07 Kbytes/se EZA1701I PORT 27,1,39,74,4,143 200 PORT command successful. EZA1701I RETR GIMPAF.XSL 150 Opening BINARY mode data connection for GIMPAF.XSL. 226 Transfer complete. EZA1617I 4800 bytes transferred in 0.320 seconds. Transfer rate 15.00 Kbytes/se EZA2554W Get fails: /u/st1mat/IBM/U01302168/SMPHOLD is a directory. EZA1735I Std Return Code = 22000, Error Code = 00018 EZA1701I QUIT 221 Goodbye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
pax and autoconversion (was: MGET ERROR)
On Tue, 20 Aug 2013 08:20:43 -0500, Paul Gilmartin (yes, I) wrote: ... Does your waystation system support pax, or equivalently, tar? I've done things similar to (from memory; not verbatim tested): ssh waystation tar -cf - U01302168 | iconv -f IBM-1047 -t ISO8859-1 |# I hate EBCDIC! tar -xvf - Could this be done relying on autoconversion, omitting the explicit iconv, with either pax or tar? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
Only IBM would see the wisdom in running TSO in batch in order to run a z/OS Unix shell :-) The rational way would be where the z/OS shell input was read its stdin from a DD just like it works interactively: // EXEC PGM=?? //STDIN DD * cp -p -R /usr/lpp/cics_test/utill/ \ /usr/lpp/cics_prod/utill/ // Kirk Wolf Dovetailed Technologies http://dovetail.com PS Co:Z Batch is just a utility. It is part of the Co:Z Toolkit and is free to use under our Community License; Enterprise License and Support agreements are also available. http://www.dovetail.com/products/cozbatch.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MGET ERROR
I dispense with making individual directories. lcd /u/mydir binary mget * (REPLACE mget SMPPTFIN/* (REPLACE mget SMPHOLD/* (REPLACE quit After the FTP is complete I rename the files to: SMPHOLD.pax.Z SMPMCS.pax.Z Then I run the unzip. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
UK GSE Conference 2013 - Registration is open
All, I am pleased to announce that the agenda for the Large Systems Stream at this years GSE conference is now finalised. Details can be found here: http://tyc.gse.org.uk/gse/presentation/view-all Registration is open and details can be found here: http://tyc.gse.org.uk/gse/presentation/view-all You need to scroll to the bottom of the page and select the Click Here To Register icon. Look forward to seeing many of you in Whittlebury. Regards, Mark __ This message was delivered by EPA Hosted Exchange and has been certified virus-free. For more information please visit http://www.epacloud.com/exchange __ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
On Tue, 20 Aug 2013 08:19:20 -0500, Kirk Wolf wrote: Only IBM would see the wisdom in running TSO in batch in order to run a z/OS Unix shell :-) (Yah, but who other than IBM would have conceived of a z/OS Unix shell, EBCDIC based even, in the first place?) The rational way would be where the z/OS shell input was read its stdin from a DD just like it works interactively: // EXEC PGM=?? //STDIN DD * cp -p -R /usr/lpp/cics_test/utill/ \ /usr/lpp/cics_prod/utill/ // I suspect there's a third-party utility available, at a very attractive price, that does something like that. Of course that particular command will fit in a 100-character PARM to BPXBATCH. And when 2.1 becomes available, PARMDD will support enormous PARMs. And I believe I can do something similar with BPXWUNIX. But only IBM (and I) would see the wisdom in running IRXJCL in batch in order to run a z/OS Unix shell. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
If I'm doing UNIX only work, I use Co:Z. But if I need to intermix TSO and UNIX, then I use the TMP and OSHELL. And I often use OSHELL examples here simply because many shops are restricted from installing unapproved software. I am blessed in that I can install most anything so long as I don't spend money or introduce reliability issues. I would love it if IBM would adopt Co:Z like it did your JZOS. On Tue, Aug 20, 2013 at 8:19 AM, Kirk Wolf k...@dovetail.com wrote: Only IBM would see the wisdom in running TSO in batch in order to run a z/OS Unix shell :-) The rational way would be where the z/OS shell input was read its stdin from a DD just like it works interactively: // EXEC PGM=?? //STDIN DD * cp -p -R /usr/lpp/cics_test/utill/ \ /usr/lpp/cics_prod/utill/ // Kirk Wolf Dovetailed Technologies http://dovetail.com PS Co:Z Batch is just a utility. It is part of the Co:Z Toolkit and is free to use under our Community License; Enterprise License and Support agreements are also available. http://www.dovetail.com/products/cozbatch.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MGET ERROR
On 2013-08-20, at 07:35, Bob Shannon wrote: I dispense with making individual directories. lcd /u/mydir binary mget * (REPLACE mget SMPPTFIN/* (REPLACE mget SMPHOLD/* (REPLACE quit After the FTP is complete I rename the files to: SMPHOLD.pax.Z SMPMCS.pax.Z Then I run the unzip. Hmmm. Does SMP/E understand that envelope if those files aren't in those particular individual directories? I thought the GIMPAF manifests expect them there. Is there any advantage of unzip (I assume GIMUNZIP) over a direct RECEIVE FROMNTS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Continuation (Was Coptying Unix Files)
On 20/08/2013, at 10:10 PM, John McKown john.archie.mck...@gmail.com wrote: If I'm doing UNIX only work, I use Co:Z. But if I need to intermix TSO and UNIX, then I use the TMP and OSHELL. And I often use OSHELL examples here simply because many shops are restricted from installing unapproved software. I am blessed in that I can install most anything so long as I don't spend money or introduce reliability issues. I would love it if IBM would adopt Co:Z like it did your JZOS. Me too! It's a joy to use. On Tue, Aug 20, 2013 at 8:19 AM, Kirk Wolf k...@dovetail.com wrote: Only IBM would see the wisdom in running TSO in batch in order to run a z/OS Unix shell :-) The rational way would be where the z/OS shell input was read its stdin from a DD just like it works interactively: // EXEC PGM=?? //STDIN DD * cp -p -R /usr/lpp/cics_test/utill/ \ /usr/lpp/cics_prod/utill/ // Kirk Wolf Dovetailed Technologies http://dovetail.com PS Co:Z Batch is just a utility. It is part of the Co:Z Toolkit and is free to use under our Community License; Enterprise License and Support agreements are also available. http://www.dovetail.com/products/cozbatch.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISFPARMs to SAF security
Hello great Lizette, thanks for the reply :) We are using z/OS 1.12 and SDSF=HQX7770. We are also using ACF2. Operator authority is not a problem, team specific access is; The problem is that some prod jobs have a NOTIFY of, let's say, NOTIFY=ABCD001 and we have a GPLEN(4) on isfparms, so all users that start with ABCD would have access over that job. The jobname itself doesn’t start with ABCD. Also, users have access to all jobs that start with the 4 first characters of their userid, and I couldn't find an easy way to do that though JESSPOOL that would not include defining tons of SAF profiles (one for each prefix). Any insight? Thanks! Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 19, 2013 10:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security What version of z/OS and/or SDSF? Which SAF are you going to? RACF, TSS, ACF2 The section on Security to SAF in SDSF manual SDSF Operation and Customization SA22-7670 should be helpful You can give operators access to jobs, output groups, or SYSIN/SYSOUT data sets for a particular destination, without authorizing the operators to those jobs, output groups, or SYSIN/SYSOUT data sets through the JESSPOOL class. This destination operator authority is the equivalent of specifying DEST for CMDAUTH and ADEST for DSPAUTH in ISFPARMS. This is also used for authorizing destinations as described in “Destination names” on page 182. To provide destination operator authority you: 1. Give the user READ authority to the ISFOPER.DEST.jesx profile in the SDSF class. This identifies a user as a destination operator for the SDSF session. 2. Give the user authorization for the profiles that protect destinations for jobs, Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Monday, August 19, 2013 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF ISFPARMs to SAF security Hello list, We are willing to migrate from ISFPARM to SAF for our SDSF security, the thing that is preventing us is that there is no direct replacement for NOTIFY or GROUP in the CMDAUTH and DSPAUTH parameters. Any of you had a problem with this and could manage a workaround? Regards, Leonardo Vaz -- 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: SDSF ISFPARMs to SAF security
Hello Efinell15, Unfortunatelly we use ACF2, and that rexx doesn't even create the RACF commands since it tries to issue some racf commands to create the list, also, since there is no one-to-one relation for the GROUP and NOTIFY, I wonder what that would generate. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of efinnell15 Sent: Tuesday, August 20, 2013 1:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security ISFACR will convert the ISFPARMS member to RACF commands? In a message dated 08/19/13 21:30:29 Central Daylight Time, stars...@mindspring.com writes: What version of z/OS and/or SDSF? -- 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: Man Pages for Ported Tools?
On my system I do:
export MANPATH=${MANPATH}:/usr/lpp/ported/man/%L
I can then do a man ... for things like curl, bzip2, sudo
On Tue, Aug 20, 2013 at 11:05 AM, Paul Gilmartin paulgboul...@aim.comwrote:
Should the man pages for Ported Tools be there (where?) if
the Tools have been installed properly?
Thanks,
gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
As of next week, passwords will be entered in Morse code.
Maranatha!
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISFPARMs to SAF security
Leonardo, You might, if you have not done so, join the RACF newsgroup. Even though you will be doing this for ACF2, they have a good knowledge of the JESSPOOL process and might be able to provide some suggestions. Racf newsgroup http://www.listserv.uga.edu/archives/racf-l.html There is also an ACF2 newsgroup you might want to join as well if you have not done so It is on Yahoo groups acf...@yahoogroups.com Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Tuesday, August 20, 2013 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Hello great Lizette, thanks for the reply :) We are using z/OS 1.12 and SDSF=HQX7770. We are also using ACF2. Operator authority is not a problem, team specific access is; The problem is that some prod jobs have a NOTIFY of, let's say, NOTIFY=ABCD001 and we have a GPLEN(4) on isfparms, so all users that start with ABCD would have access over that job. The jobname itself doesn’t start with ABCD. Also, users have access to all jobs that start with the 4 first characters of their userid, and I couldn't find an easy way to do that though JESSPOOL that would not include defining tons of SAF profiles (one for each prefix). Any insight? Thanks! Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 19, 2013 10:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security What version of z/OS and/or SDSF? Which SAF are you going to? RACF, TSS, ACF2 The section on Security to SAF in SDSF manual SDSF Operation and Customization SA22-7670 should be helpful You can give operators access to jobs, output groups, or SYSIN/SYSOUT data sets for a particular destination, without authorizing the operators to those jobs, output groups, or SYSIN/SYSOUT data sets through the JESSPOOL class. This destination operator authority is the equivalent of specifying DEST for CMDAUTH and ADEST for DSPAUTH in ISFPARMS. This is also used for authorizing destinations as described in “Destination names” on page 182. To provide destination operator authority you: 1. Give the user READ authority to the ISFOPER.DEST.jesx profile in the SDSF class. This identifies a user as a destination operator for the SDSF session. 2. Give the user authorization for the profiles that protect destinations for jobs, Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Monday, August 19, 2013 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF ISFPARMs to SAF security Hello list, We are willing to migrate from ISFPARM to SAF for our SDSF security, the thing that is preventing us is that there is no direct replacement for NOTIFY or GROUP in the CMDAUTH and DSPAUTH parameters. Any of you had a problem with this and could manage a workaround? Regards, Leonardo Vaz -- 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: SDSF ISFPARMs to SAF security
Leonardo- You may consider opening a Problem Ticket with CA with the ACF2 team. They have done this setup many times before. No need to re-invent the wheel. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, August 20, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Leonardo, You might, if you have not done so, join the RACF newsgroup. Even though you will be doing this for ACF2, they have a good knowledge of the JESSPOOL process and might be able to provide some suggestions. Racf newsgroup http://www.listserv.uga.edu/archives/racf-l.html There is also an ACF2 newsgroup you might want to join as well if you have not done so It is on Yahoo groups acf...@yahoogroups.com Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Tuesday, August 20, 2013 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Hello great Lizette, thanks for the reply :) We are using z/OS 1.12 and SDSF=HQX7770. We are also using ACF2. Operator authority is not a problem, team specific access is; The problem is that some prod jobs have a NOTIFY of, let's say, NOTIFY=ABCD001 and we have a GPLEN(4) on isfparms, so all users that start with ABCD would have access over that job. The jobname itself doesn’t start with ABCD. Also, users have access to all jobs that start with the 4 first characters of their userid, and I couldn't find an easy way to do that though JESSPOOL that would not include defining tons of SAF profiles (one for each prefix). Any insight? Thanks! Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 19, 2013 10:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security What version of z/OS and/or SDSF? Which SAF are you going to? RACF, TSS, ACF2 The section on Security to SAF in SDSF manual SDSF Operation and Customization SA22-7670 should be helpful You can give operators access to jobs, output groups, or SYSIN/SYSOUT data sets for a particular destination, without authorizing the operators to those jobs, output groups, or SYSIN/SYSOUT data sets through the JESSPOOL class. This destination operator authority is the equivalent of specifying DEST for CMDAUTH and ADEST for DSPAUTH in ISFPARMS. This is also used for authorizing destinations as described in “Destination names” on page 182. To provide destination operator authority you: 1. Give the user READ authority to the ISFOPER.DEST.jesx profile in the SDSF class. This identifies a user as a destination operator for the SDSF session. 2. Give the user authorization for the profiles that protect destinations for jobs, Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Monday, August 19, 2013 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF ISFPARMs to SAF security Hello list, We are willing to migrate from ISFPARM to SAF for our SDSF security, the thing that is preventing us is that there is no direct replacement for NOTIFY or GROUP in the CMDAUTH and DSPAUTH parameters. Any of you had a problem with this and could manage a workaround? Regards, Leonardo Vaz -- 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: SHARE Proceedings
My SF disc just came the during the week of Share. You can find last week's sessions At www.SHARE.org. They will be generally available until the next conference. There may be updates in BOS that were not included in the SF sessions. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 19, 2013 7:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SHARE Proceedings I did not attend in Boston. However, the last one in San Fran did have DVDs of the presentations. It did take many weeks before it showed up. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, August 19, 2013 7:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SHARE Proceedings Is there a way to go to the website and download *all* available proceeding handouts/presentations without selecting them one by one? My boss went to Boston and said there is no longer a SHARE CD. When did that stop (senior moment)? Bob -- 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: SDSF ISFPARMs to SAF security
Hello Norman, thank you for the tip. I will do this right away! Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norman.Hollander Sent: Tuesday, August 20, 2013 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Leonardo- You may consider opening a Problem Ticket with CA with the ACF2 team. They have done this setup many times before. No need to re-invent the wheel. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, August 20, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Leonardo, You might, if you have not done so, join the RACF newsgroup. Even though you will be doing this for ACF2, they have a good knowledge of the JESSPOOL process and might be able to provide some suggestions. Racf newsgroup http://www.listserv.uga.edu/archives/racf-l.html There is also an ACF2 newsgroup you might want to join as well if you have not done so It is on Yahoo groups acf...@yahoogroups.com Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Tuesday, August 20, 2013 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Hello great Lizette, thanks for the reply :) We are using z/OS 1.12 and SDSF=HQX7770. We are also using ACF2. Operator authority is not a problem, team specific access is; The problem is that some prod jobs have a NOTIFY of, let's say, NOTIFY=ABCD001 and we have a GPLEN(4) on isfparms, so all users that start with ABCD would have access over that job. The jobname itself doesn’t start with ABCD. Also, users have access to all jobs that start with the 4 first characters of their userid, and I couldn't find an easy way to do that though JESSPOOL that would not include defining tons of SAF profiles (one for each prefix). Any insight? Thanks! Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 19, 2013 10:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security What version of z/OS and/or SDSF? Which SAF are you going to? RACF, TSS, ACF2 The section on Security to SAF in SDSF manual SDSF Operation and Customization SA22-7670 should be helpful You can give operators access to jobs, output groups, or SYSIN/SYSOUT data sets for a particular destination, without authorizing the operators to those jobs, output groups, or SYSIN/SYSOUT data sets through the JESSPOOL class. This destination operator authority is the equivalent of specifying DEST for CMDAUTH and ADEST for DSPAUTH in ISFPARMS. This is also used for authorizing destinations as described in “Destination names” on page 182. To provide destination operator authority you: 1. Give the user READ authority to the ISFOPER.DEST.jesx profile in the SDSF class. This identifies a user as a destination operator for the SDSF session. 2. Give the user authorization for the profiles that protect destinations for jobs, Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Monday, August 19, 2013 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF ISFPARMs to SAF security Hello list, We are willing to migrate from ISFPARM to SAF for our SDSF security, the thing that is preventing us is that there is no direct replacement for NOTIFY or GROUP in the CMDAUTH and DSPAUTH parameters. Any of you had a problem with this and could manage a workaround? Regards, Leonardo Vaz -- 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: SDSF ISFPARMs to SAF security
Sure- glad to help. Tip of the day: never be afraid to open problem tickets with your vendors. That's what your maintenance dollars go to (well some of them)... zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Tuesday, August 20, 2013 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Hello Norman, thank you for the tip. I will do this right away! Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norman.Hollander Sent: Tuesday, August 20, 2013 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Leonardo- You may consider opening a Problem Ticket with CA with the ACF2 team. They have done this setup many times before. No need to re-invent the wheel. zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, August 20, 2013 9:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Leonardo, You might, if you have not done so, join the RACF newsgroup. Even though you will be doing this for ACF2, they have a good knowledge of the JESSPOOL process and might be able to provide some suggestions. Racf newsgroup http://www.listserv.uga.edu/archives/racf-l.html There is also an ACF2 newsgroup you might want to join as well if you have not done so It is on Yahoo groups acf...@yahoogroups.com Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Tuesday, August 20, 2013 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security Hello great Lizette, thanks for the reply :) We are using z/OS 1.12 and SDSF=HQX7770. We are also using ACF2. Operator authority is not a problem, team specific access is; The problem is that some prod jobs have a NOTIFY of, let's say, NOTIFY=ABCD001 and we have a GPLEN(4) on isfparms, so all users that start with ABCD would have access over that job. The jobname itself doesn’t start with ABCD. Also, users have access to all jobs that start with the 4 first characters of their userid, and I couldn't find an easy way to do that though JESSPOOL that would not include defining tons of SAF profiles (one for each prefix). Any insight? Thanks! Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, August 19, 2013 10:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISFPARMs to SAF security What version of z/OS and/or SDSF? Which SAF are you going to? RACF, TSS, ACF2 The section on Security to SAF in SDSF manual SDSF Operation and Customization SA22-7670 should be helpful You can give operators access to jobs, output groups, or SYSIN/SYSOUT data sets for a particular destination, without authorizing the operators to those jobs, output groups, or SYSIN/SYSOUT data sets through the JESSPOOL class. This destination operator authority is the equivalent of specifying DEST for CMDAUTH and ADEST for DSPAUTH in ISFPARMS. This is also used for authorizing destinations as described in “Destination names” on page 182. To provide destination operator authority you: 1. Give the user READ authority to the ISFOPER.DEST.jesx profile in the SDSF class. This identifies a user as a destination operator for the SDSF session. 2. Give the user authorization for the profiles that protect destinations for jobs, Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Monday, August 19, 2013 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF ISFPARMs to SAF security Hello list, We are willing to migrate from ISFPARM to SAF for our SDSF security, the thing that is preventing us is that there is no direct replacement for NOTIFY or GROUP in the CMDAUTH and DSPAUTH parameters. Any of you had a problem with this and could manage a workaround? Regards, Leonardo Vaz -- 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
Re: Man Pages for Ported Tools?
On Tue, 20 Aug 2013 11:16:35 -0500, John McKown wrote:
export MANPATH=${MANPATH}:/usr/lpp/ported/man/%L
Works for me, too. Thanks.
Fairly Mysterious; I see:
SPPG@MVS3:134$ ( cd /usr/lpp/ported/man amp; find . -ls )
241 drwxr-xr-x 3 SSSV OMVS 288 Oct 2 2011 .
251 drwxr-xr-x 3 SSSV OMVS 288 Oct 2 2011 ./C
261 drwxr-xr-x 2 SSSV OMVS 288 Oct 2 2011 ./C/man1
27 324 -rw-r--r-- 2 SSSV OMVS 655360 Oct 2 2011
./C/man1/hpuza200.book
How dey do dat? Is the big thing some sorta archive?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
