COPY commands under JCL vs. under Unix System Services
Hi Henrique, Why don´t you try with the IEBGENER? I use this one to copy files from OMVS to Z/os. //JOB1 JOB 999,'ME',NOTIFY=SYSUID,CLASS=A,MSGCLASS=H, //MSGLEVEL=(1,1) //CREAFICH EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSINDD DUMMY //SYSUT1 DD PATHOPTS=(ORDONLY),RECFM=FB,LRECL=80,BLKSIZE=800, //PATH='/u/userid/testcopydataset' //SYSUT2 DD DSN=USERID.TEMP.TESTCOPY.DATASET, //DISP=(,CATLG,DELETE), //UNIT=3390, //SPACE=(CYL,(1,1)), //RECFM=FB,LRECL=80 Remember the OMVS datasets are case sensitive. Enrique Montero -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COPY commands under JCL vs. under Unix System Services
On Thu, 25 Aug 2011 13:45:12 -0500, Henrique Seganfredo henrique.seganfr...@bcb.gov.br wrote: Hello, I am trying to run a job that calls BPXBATCH do execute a Unix script. Far easier to use Co:Z batch... The Unix script tries to copy the file from the Unix environment to a MVS dataset. I have tried these two approaches. The filename is variable. 1) cp -P RECFM=FB,SPACE=(CYL,(1,1)),LRECL=96,BLKSIZE=0 $myfilevar.ebcdic //'PSTR.TEMP' I have tested this with exactly your JCL. Works like a charm... JCL: //XXX JOB YY,TIME=1 //COPY EXEC PGM=BPXBATCH,REGION=8M,COND=(0,NE) //STDINDD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * sh /spb/bin/Copy.sh //* Why the dataset appears to be in use ?? It DOES NOT EVEN exists! I suggest you look again. It must exist... Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COPY commands under JCL vs. under Unix System Services
Folks, The suggestion made by Mark did work here fine. I just added a new DD cards that sets some environment variables that control the way new processes are started under BPXBATCH. //STDENV DD * _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES This made the JCL run fine. One thing to note, I tried to set this variables inside of my Unix script Copy.sh (export _BPX_SHAREAS=YES...) and it did not work. Thanks for the feedback folks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COPY commands under JCL vs. under Unix System Services
Hello, I have been dealing with some strange behaviour. I am trying to run a job that calls BPXBATCH do execute a Unix script. The Unix script tries to copy the file from the Unix environment to a MVS dataset. I have tried these two approaches. The filename is variable. 1) cp -P RECFM=FB,SPACE=(CYL,(1,1)),LRECL=96,BLKSIZE=0 $myfilevar.ebcdic //'PSTR.TEMP' 2) tso -t OGET '$myfilevar.ebcdic' 'PSTR.TEMP' Both approaches work fine when interactively I type them on a telnet session or on a TSO OMVS session, BUT FAIL when I call the script containing these commands using BPXBATCH on a JOB: JCL: //XXX JOB YY,TIME=1 //COPY EXEC PGM=BPXBATCH,REGION=8M,COND=(0,NE) //STDINDD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * sh /spb/bin/Copy.sh //* SYSOUT: OGET '/spb/tmp/ABMA014_57D18317.33555264.D.ebcdic' 'PSTR.TEMP' IKJ56225I DATA SET PSTR.TEMP ALREADY IN USE, TRY LATER+ IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER RC(12) Why the dataset appears to be in use ?? It DOES NOT EVEN exists! I get this message whenever my script uses 'cp' or 'oget'... Regards, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COPY commands under JCL vs. under Unix System Services
On Thu, 25 Aug 2011 13:45:12 -0500, Henrique Seganfredo henrique.seganfr...@bcb.gov.br wrote: Hello, I have been dealing with some strange behaviour. I am trying to run a job that calls BPXBATCH do execute a Unix script. The Unix script tries to copy the file from the Unix environment to a MVS dataset. I have tried these two approaches. The filename is variable. 1) cp -P RECFM=FB,SPACE=(CYL,(1,1)),LRECL=96,BLKSIZE=0 $myfilevar.ebcdic //'PSTR.TEMP' 2) tso -t OGET '$myfilevar.ebcdic' 'PSTR.TEMP' Both approaches work fine when interactively I type them on a telnet session or on a TSO OMVS session, BUT FAIL when I call the script containing these commands using BPXBATCH on a JOB: JCL: //XXX JOB YY,TIME=1 //COPY EXEC PGM=BPXBATCH,REGION=8M,COND=(0,NE) //STDINDD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * sh /spb/bin/Copy.sh //* SYSOUT: OGET '/spb/tmp/ABMA014_57D18317.33555264.D.ebcdic' 'PSTR.TEMP' IKJ56225I DATA SET PSTR.TEMP ALREADY IN USE, TRY LATER+ IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER RC(12) Why the dataset appears to be in use ?? It DOES NOT EVEN exists! I get this message whenever my script uses 'cp' or 'oget'... Are you sure something isn't allocated to your TSO session still? Try logging off from TSO and back on and then try it in batch. Ways to check would include TSO ISRDDN (DDLIST) with the ENQ command, or a GRS display command - D GRS,RES=(SYSDSN,PSTR.TEMP) -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COPY commands under JCL vs. under Unix System Services
Hello Henrique, There appear to be two threads, both describing a similar issue. BPXBATCH can be a real can of worms. I believe that your problem stems from the fact that executables may be invoked in multiple address spaces having different jobnames, which screws up ENQueue something fierce. Without going into long-winded explanations, I suggest you try the following using the script that issues cp; do not use OGET because it complicates things. I believe that the two environment variables may coax spawn() into doing everything in a single address space, thus eliminating the ENQueue issue. Note that this example may not work as expected if your script (executable) file is flagged with setuid or setgid. //XXX JOB YY,TIME=1 //COPYEXEC PGM=BPXBATCH,REGION=8M,COND=(0,NE), // PARM='SH /spb/bin/Copy.sh' //STDOUT DD SYSOUT=* //STDENV DD * _BPX_SHAREAS=YES _BPX_SPAWN_SCRIPT=YES If the above doesn't work (I don't have time to test - sorry), try changing the program name to BPXBATSL (spawn locally); I'm 97% sure that will work but, if it doesn't, let me know and I'll give you a third alternative. Cheers, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Henrique Seganfredo Sent: Thursday, August 25, 2011 11:45 AM To: IBM-MAIN@bama.ua.edu Subject: COPY commands under JCL vs. under Unix System Services Hello, I have been dealing with some strange behaviour. I am trying to run a job that calls BPXBATCH do execute a Unix script. The Unix script tries to copy the file from the Unix environment to a MVS dataset. I have tried these two approaches. The filename is variable. 1) cp -P RECFM=FB,SPACE=(CYL,(1,1)),LRECL=96,BLKSIZE=0 $myfilevar.ebcdic //'PSTR.TEMP' 2) tso -t OGET '$myfilevar.ebcdic' 'PSTR.TEMP' Both approaches work fine when interactively I type them on a telnet session or on a TSO OMVS session, BUT FAIL when I call the script containing these commands using BPXBATCH on a JOB: JCL: //XXX JOB YY,TIME=1 //COPY EXEC PGM=BPXBATCH,REGION=8M,COND=(0,NE) //STDINDD SYSOUT=* //STDOUT DD SYSOUT=* //STDPARM DD * sh /spb/bin/Copy.sh //* SYSOUT: OGET '/spb/tmp/ABMA014_57D18317.33555264.D.ebcdic' 'PSTR.TEMP' IKJ56225I DATA SET PSTR.TEMP ALREADY IN USE, TRY LATER+ IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER RC(12) Why the dataset appears to be in use ?? It DOES NOT EVEN exists! I get this message whenever my script uses 'cp' or 'oget'... Regards, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COPY commands under JCL vs. under Unix System Services
Mark, This is what I got. The other commands you suggested may show anything different? /D GRS,RES=(SYSDSN,PSTR.TEMP) RESPONSE=HOMO ISG343I 16.34.00 GRS STATUS 894 NO REQUESTORS FOR RESOURCE SYSDSN PSTR.TEMP One correction: The use of the oget under JCL produces: Command: tso -t OGET '$myvar.ebcdic' 'PSTR.TEMP' Sysout: IKJ56225I DATA SET PSTR.TEMP ALREADY IN USE, TRY LATER+ IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER RC(12) The use of the cp under JCL produces: Command: cp -P RECFM=FB,SPACE=(CYL,(1,1)),LRECL=96,BLKSIZE=0 $myvar.ebcdic //'PSTR.TEMP' Sysout: cp: FSUM6258 cannot open file //'PSTR.TEMP': EDC5061I An error occurred when attempting to define a file to the system. Like I said before, these commands entered interactively under USS work w/o problems. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
You're right. If you have a string of commands, it REDUCES the operator intervention to one command, assuming you can tolerate a one-minute security exposure. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Wednesday, December 07, 2005 6:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Commands in JCL In a recent note, Charles Mills said: Date: Wed, 7 Dec 2005 18:13:10 -0500 No, no, if the current setting is verify, then the $T command has to be verified. No (fundamental) logical flaw there. Good. But doesn't this, then, fail Steve's requirement (as I perceived it) that he be able to avoid operator intervention? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
On Wed, 7 Dec 2005 15:18:55 -0700, Steve Comstock [EMAIL PROTECTED] wrote: $tjobclass(*),command=execute Then update JES2PARM. No need to recycle JES or IPL or anything at all Thanks, John. But some of the other experiments worked without even changing JESPARMS. I'm good to go. Steve, I believe the JESPARMS reminder was to ensure your change is remembered across a warm start, not to effect the change. -Rob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Subject: Commands in JCL
There is an old Macro called MGCR that we setup in the 70's and it still works with z/OS 1.4. Here is the reference to the book from MVS/XA. It is a very small program and easy to compile and use. Let me know if you would like the source code and the old ENTER MACRO to compile it with. MORE INFORMATION CAN BE FOUND UNDER THE 'MGCR' MACRO IN: MVS/XA SPL: SYSTEM MACROS AND FACILITIES VOL. 2 (GC28-1151) Here is a sample of JCL to run the macro. //xx JOB ... //*MAIN CLASS=1 //* //*** SUBMIT COMMAND *** //* //DRCOMMND EXEC PGM=DRCOMMND,PARM='D T' Runs on both JES2/3 systems. Leif Rundberget Operating Systems Programmer/Analyst III State of Colorado Department of Personnel Administration (DPA) Division of Information Technologies (DoIT) 690 Kipling Street, Room 2060 Lakewood, CO 80215-5844 Phone: (303) 239-4357 Fax: (303) 239-4383 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Wednesday, December 07, 2005 4:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Commands in JCL Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
On Thu, 8 Dec 2005 08:48:26 -0600, Rob Wunderlich [EMAIL PROTECTED] wrote: On Wed, 7 Dec 2005 15:18:55 -0700, Steve Comstock [EMAIL PROTECTED] wrote: $tjobclass(*),command=execute Then update JES2PARM. No need to recycle JES or IPL or anything at all Thanks, John. But some of the other experiments worked without even changing JESPARMS. I'm good to go. Steve, I believe the JESPARMS reminder was to ensure your change is remembered across a warm start, not to effect the change. -Rob Good advise (to keep the parms in sync), but WARM start / IPL won't change it back. JOBCLASS() parms are only modified by operator command or JES2 cold start since OS/390 2.4 with an $ACTIVATEd spool. Also note that they are MAS in scope since the same time. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America and Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
In [EMAIL PROTECTED], on 12/07/2005 at 02:13 PM, Steve Comstock [EMAIL PROTECTED] said: Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? At your shop or in general? There are several ways to issue commands, and each has its own security requirements. My guess is that you are more likely to get authorization to use a facility like CONSOLE than to get authorization to do it from JCL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Commands in JCL
Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
The COMMAND= parameter in the JES2 JOBCLASS(..) statement. I don't know how or whether JES3 does it. Bob Steve Comstock wrote: Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
Steve, I used the JCL below to issue operator commands to all our lpars in the sysplex. You could probably substitute your commands .. Not sure if you will run into RACF issues at your site. gabe //FACGTCMD JOB '2',TORRES,MSGCLASS=Z //SUBMITEXEC PGM=IEBEDIT //SYSUT2DD SYSOUT=(B,INTRDR),DCB=BLKSIZE=80 //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT1DD DATA,DLM='$$' /*$VS,'RO *ALL,D U,,,940,64' /*$VS,'RO *ALL,D GRS,C' /*$VS,'RO *ALL,D R,L' $$ --- Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
Steve Comstock wrote: Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Yes. It depends on JES2 settings. (I assumed JES2, because JES3 is less popular). See JOBCLASS(n) parameter: COMMAND=DISPLAY|EXECUTE|IGNORE|VERIFY verify is default. Note, the commands are subject to RACF OPERCMDS class checking, so there is no big hole to use EXECUTE ...with small exception to DB2, which doea not protect -dsn STOP DB2 command. HTH -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
Bob Rutledge wrote: The COMMAND= parameter in the JES2 JOBCLASS(..) statement. I don't know how or whether JES3 does it. Bob Hmmm. Good thought. I find COMMAND=VERIFY, so I'll try COMMAND=EXECUTE I'll have to re-cycle JES then, right? Or even re-ipl? [I don't care about JES3, since I am running JES2.] Kind regards, -Steve Comstock Steve Comstock wrote: Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Wednesday, December 07, 2005 4:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Commands in JCL Bob Rutledge wrote: The COMMAND= parameter in the JES2 JOBCLASS(..) statement. I don't know how or whether JES3 does it. Bob Hmmm. Good thought. I find COMMAND=VERIFY, so I'll try COMMAND=EXECUTE I'll have to re-cycle JES then, right? Or even re-ipl? [I don't care about JES3, since I am running JES2.] Kind regards, -Steve Comstock NO! $tjobclass(*),command=execute Then update JES2PARM. No need to recycle JES or IPL or anything at all John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
Gabe Torres wrote: Steve, I used the JCL below to issue operator commands to all our lpars in the sysplex. You could probably substitute your commands .. Not sure if you will run into RACF issues at your site. gabe //FACGTCMD JOB '2',TORRES,MSGCLASS=Z //SUBMITEXEC PGM=IEBEDIT //SYSUT2DD SYSOUT=(B,INTRDR),DCB=BLKSIZE=80 //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT1DD DATA,DLM='$$' /*$VS,'RO *ALL,D U,,,940,64' /*$VS,'RO *ALL,D GRS,C' /*$VS,'RO *ALL,D R,L' $$ Worked like a champ! Thanks. -Steve Comstock --- Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FW: Commands in JCL
Cox, Dave wrote: Steve, Curious: Why JCL ? Do you have any automation such as Control-O on your system ? If not, sometimes I will submit commands using a BR14 with $VS commands like so through Control-M scheduler: /*$VS,'F CONTROLO,O=OPER.CNTLO.PRD1.V5.RULES(DB2CICUP)' //DB2PCHK JOB (99),MSGCLASS=X,CLASS=A,NOTIFY=CONTREA //STEP001 EXEC PGM=IEFBR14 //SYSPRINT DD SYSOUT=* //SYSUT1 DD DUMMY //SYSUT2 DD DUMMY //SYSIN DD DUMMY /* May not be exactly what you were looking for, but you can control the start, submit, and stop through the use of time settings or conditions being written to a conditions table within the IOA Control-M software. Also, automatic commands ( $TA ). Depends on if this is very repetitive or one-off occurrence. Dave Excellent! Even better than the other solution. Thanks, -Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Wednesday, December 07, 2005 4:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Commands in JCL Bob Rutledge wrote: The COMMAND= parameter in the JES2 JOBCLASS(..) statement. I don't know how or whether JES3 does it. Bob Hmmm. Good thought. I find COMMAND=VERIFY, so I'll try COMMAND=EXECUTE I'll have to re-cycle JES then, right? Or even re-ipl? [I don't care about JES3, since I am running JES2.] Kind regards, -Steve Comstock NO! $tjobclass(*),command=execute Then update JES2PARM. No need to recycle JES or IPL or anything at all Thanks, John. But some of the other experiments worked without even changing JESPARMS. I'm good to go. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
On Wed, 7 Dec 2005 22:31:59 +0100, R.S. [EMAIL PROTECTED] wrote: Steve Comstock wrote: Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? Yes. It depends on JES2 settings. (I assumed JES2, because JES3 is less popular). See JOBCLASS(n) parameter: COMMAND=DISPLAY|EXECUTE|IGNORE|VERIFY verify is default. Note, the commands are subject to RACF OPERCMDS class checking, so there is no big hole to use EXECUTE ...with small exception to DB2, which doea not protect -dsn STOP DB2 command. Small. LOL!! I guess if Steve is running his own flex, p390, vm lpar, etc. it doesn't matter since he is the only user. I always use COMMAND=IGNORE for anything but STCs - which are trusted. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America and Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
Or with a command, $T JOBCLASS(E),COMMAND=DISPLAY with COMMAND=VERIFY to set it back. In my experience, it does not work to put this command as the first command of a string of JCL commands because apparently it takes effect too late. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, December 07, 2005 4:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Commands in JCL Steve Comstock wrote: Is there a way to issue an operator command such as Start in a JCL COMMAND statement without causing the system to ask the console operator to allow it or not? I want to issue a series of commands, one to start SMTP, another to submit an email via IEBGENER and the internal reader, and another to stop SMTP. Yes. It depends on JES2 settings. (I assumed JES2, because JES3 is less popular). See JOBCLASS(n) parameter: COMMAND=DISPLAY|EXECUTE|IGNORE|VERIFY verify is default. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
In a recent note, Charles Mills said: Date: Wed, 7 Dec 2005 17:39:43 -0500 Or with a command, $T JOBCLASS(E),COMMAND=DISPLAY with COMMAND=VERIFY to set it back. In my experience, it does not work to put this command as the first command of a string of JCL commands because apparently it takes effect too late. This whole discussion mystifies me. Isn't it a security hole to allow a user to override command verification without requiring verification of the override? All the effective suggested alternatives should be considered security flaws, and APARed. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
Charles Mills wrote: Or with a command, $T JOBCLASS(E),COMMAND=DISPLAY with COMMAND=VERIFY to set it back. In my experience, it does not work to put this command as the first command of a string of JCL commands because apparently it takes effect too late. Charles My strategy is: submit start smtp wait n seconds submit send email wait n seconds submit stop smtp as the only user on the system, it should work ok. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Commands in JCL
In a recent note, Charles Mills said: Date: Wed, 7 Dec 2005 18:13:10 -0500 No, no, if the current setting is verify, then the $T command has to be verified. No (fundamental) logical flaw there. Good. But doesn't this, then, fail Steve's requirement (as I perceived it) that he be able to avoid operator intervention? StorageTek INFORMATION made POWERFUL -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
