Re: Intrdr
In 6909F4D0560E4352A3978CC7BCC81F5F@X61, on 02/03/2012 at 01:30 PM, Jack Schudel j...@nersp.cns.ufl.edu said: As a result of this, console messages related to the submitted job now appear in the JESLOG of the submitting job. Actually, I thought that they were always in the JESLOG of the submitting job. However, by capturing them I meant putting them in STDERR. -- 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
In 4413868793325066.wa.paulgboulderaim@bama.ua.edu, on 02/01/2012 at 08:17 PM, Paul Gilmartin paulgboul...@aim.com said: that if I submit a job with address LINKMVS IEBGENER; SYSUT2=INTRDR, that JCL messages, including: 10.58.03 JOB00618 $HASP100 JOBCARD ON INTRDR Paul GilmartinFROM STC00548 user 10.58.03 JOB00618 IRR010I USERID user IS ASSIGNED TO THIS JOB. Those look like console messages, not JCL messages. I wonder who's capturing them, how and why? -- 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Thu, 2 Feb 2012 06:31:47 -0500, Shmuel Metz (Seymour J.) wrote: on 02/01/2012 at 08:17 PM, Paul Gilmartin said: that if I submit a job with address LINKMVS IEBGENER; SYSUT2=INTRDR, that JCL messages, including: 10.58.03 JOB00618 $HASP100 JOBCARD ON INTRDR PaulGilmartin FROM STC00548 user 10.58.03 JOB00618 IRR010I USERID user IS ASSIGNED TO THIS JOB. Those look like console messages, not JCL messages. I wonder who's capturing them, how and why? Me, too, which is why I merged this thread from MVS-OE: http://www2.marist.edu/htbin/wlvtype?MVS-OE.56917 hoping to find an expert opinion here. I get the same messages replacing IEBGENER with an EXECIO loop. I stand corrected on the terminology. I shied away from console because some (ambiguously) use it to mean the desktop terminal. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Way back in z/OS 1.7, when JES2 added support for NJE over TCP/IP, INTRDR processing changed from running in JES2's main task HASPRDR code to running in the user address space. As a result of this, console messages related to the submitted job now appear in the JESLOG of the submitting job. See Page 38 of http://proceedings.share.org/client_files/SHARE_in_Seattle/S2657CW162731.pdffor more details./jack- Original Message -From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.netNewsgroups: bit.listserv.ibm-mainTo: IBM-MAIN@bama.ua.eduSent: Thursday, February 02, 2012 6:31 AMSubject: Re: Intrdr In 4413868793325066.wa.paulgboulderaim@bama.ua.edu, on 02/01/2012 at 08:17 PM, Paul Gilmartin paulgboul...@aim.com said:that if I submit a job with address LINKMVS IEBGENER; SYSUT2=INTRDR,that JCL messages, including:10.58.03 JOB00618 $HASP100 JOBCARD ON INTRDR PaulGilmartinFROM STC00548 user 10.58.03 JOB00618 IRR010I USERID user IS ASSIGNED TO THISJOB. Those look like console messages, not JCL messages. I wonder who's capturing them, how and why? -- 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 Co! ngress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
AW: Intrdr
Scott First read z/OS MVS Programming: Assembler Services Guide, 25.1.3.1 Obtaining a job identifier. Using VSAM as the access method for the INTRDR file you can get the job identifier by means of the ENDREQ service after writing the last record to INTRDR. Then you can use jobname AND jobid as a filter to the Extended Status Function Call (SSI Function Code 80) using IEFSSREQ. Using both filters makes the use of this interface much easier because it should normally return only one job. It gives you all information you need (see fields STTRXIND and STTRPHAZ of macro IAZSSST). Re-issue IEFSSREQ after some time if STTRPHAZ indicates that the job has not yet ended. See z/OS MVS Using the Subsystem Interface, 3.1.11 Extended Status Function Call -- SSI Function Code 80. Hans -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Im Auftrag von Scott Ford Gesendet: Mittwoch, 1. Februar 2012 02:37 An: IBM-MAIN@bama.ua.edu Betreff: Intrdr All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? Thanks in advance Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Being a bit of a UNIX partisan, I'd do a fork()/exec() to run the application. You'd fork()/exec() /bin/sh -c to run a UNIX REXX script. This UNIX REXX script uses ADDRESS TSO to run a TSO REXX program (yes, it's getting complicated) to do what the JCL usually does. When the TSO REXX finishes, the UNIX REXX script continues, and subsequently finishes. When the UNIX REXX script finishes, the shell finishes and the originating program can be informed via a SIGCHLD signal. Or it can just hang itself in a UNIX wait(). If you're really good, you may not need the TSO REXX. I just think it's easier to convert JCL to TSO REXX than UNIX REXX. OK, this is likely going overboard. It would require a major rewrite of the STC's current code. But it does give an example of running another process asynchronously with the originator being informed of completion. Of course, depending on what the STC is doing in the mean time, the creation of the dataset can be eliminated by using a named pipe, or perhaps even an anonymous pipe. Have the asynchronous process write to the named pipe. Have the main STC read from it. The main STC will wait in the read of the pipe until the subprocess starts writing. And will get an EOF on the pipe when the subprocess does a CLOSE on it. Come to think of it, this will even work with a batch job submitted via the INTRDR, so long as you are running on the same system. If you really need the dataset for later, have the final step of the batch job use IEBGENER to copy the dataset contents to the named pipe. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hunkeler Peter (KIUP 4) Sent: Wednesday, February 01, 2012 1:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Why does it have to be a submitted job? Can't you just link to the program, or programs one after the other, that create the file? Knowing more about this requirement might trigger new ideas. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
All, As someone once said there are about a dozen ways to do something...I need to regroup and review. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 1, 2012, at 8:26 AM, McKown, John john.mck...@healthmarkets.com wrote: Being a bit of a UNIX partisan, I'd do a fork()/exec() to run the application. You'd fork()/exec() /bin/sh -c to run a UNIX REXX script. This UNIX REXX script uses ADDRESS TSO to run a TSO REXX program (yes, it's getting complicated) to do what the JCL usually does. When the TSO REXX finishes, the UNIX REXX script continues, and subsequently finishes. When the UNIX REXX script finishes, the shell finishes and the originating program can be informed via a SIGCHLD signal. Or it can just hang itself in a UNIX wait(). If you're really good, you may not need the TSO REXX. I just think it's easier to convert JCL to TSO REXX than UNIX REXX. OK, this is likely going overboard. It would require a major rewrite of the STC's current code. But it does give an example of running another process asynchronously with the originator being informed of completion. Of course, depending on what the STC is doing in the mean time, the creation of the dataset can be eliminated by using a named pipe, or perhaps even an anonymous pipe. Have the asynchronous process write to the named pipe. Have the main STC read from it. The main STC will wait in the read of the pipe until the subprocess starts writing. And will get an EOF on the pipe when the subprocess does a CLOSE on it. Come to think of it, this will even work with a batch job submitted via the INTRDR, so long as you are running on the same system. If you really need the dataset for later, have the final step of the batch job use IEBGENER to copy the dataset contents to the named pipe. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hunkeler Peter (KIUP 4) Sent: Wednesday, February 01, 2012 1:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Why does it have to be a submitted job? Can't you just link to the program, or programs one after the other, that create the file? Knowing more about this requirement might trigger new ideas. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Plenty of ways to skin a cat and plenty of cats to skin :-) KISS is important here. The more complex the solution, the more fragile. Why not use the FTP strategy? That is, the STC drives a FTP process to submit the job and retrieve the result. This is a snap in REXX. One concern, if the STC is single thread, then waiting for something may not be a good idea. But I think you have the right idea: regroup and take a hard look at the root business/technical problem you are trying to solve. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Wednesday, February 01, 2012 8:03 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr All, As someone once said there are about a dozen ways to do something...I need to regroup and review. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 1, 2012, at 8:26 AM, McKown, John john.mck...@healthmarkets.com wrote: Being a bit of a UNIX partisan, I'd do a fork()/exec() to run the application. You'd fork()/exec() /bin/sh -c to run a UNIX REXX script. This UNIX REXX script uses ADDRESS TSO to run a TSO REXX program (yes, it's getting complicated) to do what the JCL usually does. When the TSO REXX finishes, the UNIX REXX script continues, and subsequently finishes. When the UNIX REXX script finishes, the shell finishes and the originating program can be informed via a SIGCHLD signal. Or it can just hang itself in a UNIX wait(). If you're really good, you may not need the TSO REXX. I just think it's easier to convert JCL to TSO REXX than UNIX REXX. OK, this is likely going overboard. It would require a major rewrite of the STC's current code. But it does give an example of running another process asynchronously with the originator being informed of completion. Of course, depending on what the STC is doing in the mean time, the creation of the dataset can be eliminated by using a named pipe, or perhaps even an anonymous pipe. Have the asynchronous process write to the named pipe. Have the main STC read from it. The main STC will wait in the read of the pipe until the subprocess starts writing. And will get an EOF on the pipe when the subprocess does a CLOSE on it. Come to think of it, this will even work with a batch job submitted via the INTRDR, so long as you are running on the same system. If you really need the dataset for later, have the final step of the batch job use IEBGENER to copy the dataset contents to the named pipe. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hunkeler Peter (KIUP 4) Sent: Wednesday, February 01, 2012 1:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Why does it have to be a submitted job? Can't you just link to the program, or programs one after the other, that create the file? Knowing more about this requirement might trigger new ideas. -- Peter Hunkeler - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have
Re: Intrdr
Whatever the FTP server does, it handles all of those conditions. It handles (1) perfectly and (2) via a timeout (JESWAITTO). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sam Siegel Sent: Tuesday, January 31, 2012 8:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr On Tue, Jan 31, 2012 at 7:52 PM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, That's a interesting idea... Scott You also need to handle the case like: 1) The submitted job gets a JCL error prior to executing your code; STC is never posted. 2) The submitted job gets queued up on resource contention; STC is left waiting for a long time. 3) The submitted job is forced off the system in a way that precludes the ESTAE from being invoked; STC is never posted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On 31 January 2012 23:55, Tom Wasik wa...@us.ibm.com wrote: A couple thoughts come to mind. - Use NOTIFY= on the job card to get a TSO message when the job completes That's going to be hard to capture in a program, since it is done as a cross-memory TPUT. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
You could have the batch job issue a MODIFY command to tell the STC that the job has completed. (Using an appropriate ROUTE command if not running on the same LPAR.) /jack - Original Message - From: Scott Ford scott_j_f...@yahoo.com Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Tuesday, January 31, 2012 8:36 PM Subject: Intrdr All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? Thanks in advance Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Wed, 1 Feb 2012 08:11:48 +0100, Hunkeler Peter (KIUP 4) wrote: Why does it have to be a submitted job? Can't you just link to the program, or programs one after the other, that create the file? Knowing more about this requirement might trigger new ideas. There might be DDNAME conflicts or APF limitations. How about a combination of BPX1FRK; BPX1EXM; BPX1WAT to avoid those restrictions with no need to submit a job? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Wed, 1 Feb 2012 07:26:36 -0600, McKown, John wrote: If you're really good, you may not need the TSO REXX. I just think it's easier to convert JCL to TSO REXX than UNIX REXX. Why? ALLOCATE? There's BPXWDYN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Whatever happened to the PLMs when you need them Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 1, 2012, at 10:04 AM, Charles Mills charl...@mcn.org wrote: Whatever the FTP server does, it handles all of those conditions. It handles (1) perfectly and (2) via a timeout (JESWAITTO). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sam Siegel Sent: Tuesday, January 31, 2012 8:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr On Tue, Jan 31, 2012 at 7:52 PM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, That's a interesting idea... Scott You also need to handle the case like: 1) The submitted job gets a JCL error prior to executing your code; STC is never posted. 2) The submitted job gets queued up on resource contention; STC is left waiting for a long time. 3) The submitted job is forced off the system in a way that precludes the ESTAE from being invoked; STC is never posted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
In CAArMM9RAqzhBQTM1hHu9-GAVXaAK68WrDqxsBofB=60hHK3d=a...@mail.gmail.com, on 02/01/2012 at 10:20 AM, Tony Harminc t...@harminc.net said: That's going to be hard to capture in a program, Doesn't Session Manager capture cross-memory TPUT messages? -- 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Wed, 1 Feb 2012 20:16:03 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In CAArMM9RAqzhBQTM1hHu9-GAVXaAK68WrDqxsBofB=60hHK3d=a...@mail.gmail.com, on 02/01/2012 at 10:20 AM, Tony Harminc t...@harminc.net said: That's going to be hard to capture in a program, Doesn't Session Manager capture cross-memory TPUT messages? I discovered lately, and posted to MVS-OE, where Dave Gibney suggested a fix for a defect: http://www2.marist.edu/htbin/wlvtype?MVS-OE.56917 that if I submit a job with address LINKMVS IEBGENER; SYSUT2=INTRDR, that JCL messages, including: 10.58.03 JOB00618 $HASP100 JOBCARD ON INTRDR Paul Gilmartin FROM STC00548 user 10.58.03 JOB00618 IRR010I USERID user IS ASSIGNED TO THIS JOB. get written to stderr and I can capture them and use the Job ID as input to the Rexx SDSF API (theoretically). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Intrdr
All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? Thanks in advance Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? Thanks in advance How will you retrieve the information? If under TSO then the ST command could work. Or if you need another batch job and you use SDSF. Then There is a REXX SDSF interface where you could look until the job completes that then sends a notification. Or you could add a last step to the job that sends a TSO SEND command to notify you. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Tue, Jan 31, 2012 at 5:47 PM, Lizette Koehler stars...@mindspring.com wrote: All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? Thanks in advance How will you retrieve the information? If under TSO then the ST command could work. Or if you need another batch job and you use SDSF. Then There is a REXX SDSF interface where you could look until the job completes that then sends a notification. Or you could add a last step to the job that sends a TSO SEND command to notify you. Lizette I think the problem is more complex than that. How is he noticed if the job abends or is cancelled. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 8:51 PM, Sam Siegel s...@pscsi.net wrote: On Tue, Jan 31, 2012 at 5:47 PM, Lizette Koehler stars...@mindspring.com wrote: All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? Thanks in advance How will you retrieve the information? If under TSO then the ST command could work. Or if you need another batch job and you use SDSF. Then There is a REXX SDSF interface where you could look until the job completes that then sends a notification. Or you could add a last step to the job that sends a TSO SEND command to notify you. Lizette I think the problem is more complex than that. How is he noticed if the job abends or is cancelled. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
There is definitely a way to do it because FTP does it. You can submit a job and wait for it to complete with FTP. SITE FIELTYPE=JES GET jcl.file where.you.want.msgout.to.go is the syntax, from memory. I seem to recall something with using an ACB rather than a DCB to submit the job. Take a look into that. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Tuesday, January 31, 2012 5:37 PM To: IBM-MAIN@bama.ua.edu Subject: Intrdr All, I have a STC that submits a job via the Intrdr, unfortunately it's single thread. I need know when the submitted job completed. If I have the job and can I step through control blocks to find this jobs status? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
something with using an ACB Never mind. I think what I recall is that you get the job number back in the ACB. Still, might be something to look into. Charles -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Tuesday, January 31, 2012 6:23 PM To: 'IBM Mainframe Discussion List' Subject: RE: Intrdr There is definitely a way to do it because FTP does it. You can submit a job and wait for it to complete with FTP. SITE FIELTYPE=JES GET jcl.file where.you.want.msgout.to.go is the syntax, from memory. I seem to recall something with using an ACB rather than a DCB to submit the job. Take a look into that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Sam, As I just wrote. Scheduling packages do this. There may be a process on the CBTTAPE.ORG that is a minimum scheduler that could assist with this requirement. Such as File 332 or 388 or 798 But I was thinking COND=EVEN COND=ONLY And COND0 So not knowing the full scope, I can only provide limited options. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Liz, There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 9:18 PM, Lizette Koehler stars...@mindspring.com wrote: A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Scheduler is out of the question, we are self-contained within a STC. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 9:18 PM, Lizette Koehler stars...@mindspring.com wrote: A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Scott - Does the submitted job run authorized? If it does, you can use a combination of name token service and pause element service to coordinate tcb in different address spaces. You would need to code an estae or have a resmgr active to handle error situations and ensure that the STC is not left waiting. The submitted job would have to run on the same mvs image as the STC. Sam On Tue, Jan 31, 2012 at 6:37 PM, Scott Ford scott_j_f...@yahoo.com wrote: Scheduler is out of the question, we are self-contained within a STC. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 9:18 PM, Lizette Koehler stars...@mindspring.com wrote: A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Sam, That's a interesting idea... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 10:32 PM, Sam Siegel s...@pscsi.net wrote: Scott - Does the submitted job run authorized? If it does, you can use a combination of name token service and pause element service to coordinate tcb in different address spaces. You would need to code an estae or have a resmgr active to handle error situations and ensure that the STC is not left waiting. The submitted job would have to run on the same mvs image as the STC. Sam On Tue, Jan 31, 2012 at 6:37 PM, Scott Ford scott_j_f...@yahoo.com wrote: Scheduler is out of the question, we are self-contained within a STC. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 9:18 PM, Lizette Koehler stars...@mindspring.com wrote: A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Scott, After the job is submitted can you enqueue OLD on the QSAM file and wait for it to become available. This is timing dependent because the submitted job must start executing for the enqueue to work. Slightly out of the box can the job be run as a subtask. This means the STC will need to handle the dynamic file allocations for the job but will then know when completed. On 1/02/2012 13:34 PM, Scott Ford wrote: Liz, There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Tue, Jan 31, 2012 at 7:52 PM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, That's a interesting idea... Scott You also need to handle the case like: 1) The submitted job gets a JCL error prior to executing your code; STC is never posted. 2) The submitted job gets queued up on resource contention; STC is left waiting for a long time. 3) The submitted job is forced off the system in a way that precludes the ESTAE from being invoked; STC is never posted. I think these can be solved by attaching a sub-task in the STC to monitor/wait for the submitted job to complete. The sub-task would need a stimer to handle the case where the submitted job does not post back. After a certain period of time, it is assumed that the submitted job failed, and then recovery processing or corrective actions are taken. Sam Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 10:32 PM, Sam Siegel s...@pscsi.net wrote: Scott - Does the submitted job run authorized? If it does, you can use a combination of name token service and pause element service to coordinate tcb in different address spaces. You would need to code an estae or have a resmgr active to handle error situations and ensure that the STC is not left waiting. The submitted job would have to run on the same mvs image as the STC. Sam On Tue, Jan 31, 2012 at 6:37 PM, Scott Ford scott_j_f...@yahoo.com wrote: Scheduler is out of the question, we are self-contained within a STC. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 9:18 PM, Lizette Koehler stars...@mindspring.com wrote: A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
The submitted job would have to run on the same mvs image as the STC Right, Scott, that is a consideration. I job submitted via INTRDR might run on a different LPAR. Complicates the control block chaining. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sam Siegel Sent: Tuesday, January 31, 2012 7:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr Scott - Does the submitted job run authorized? If it does, you can use a combination of name token service and pause element service to coordinate tcb in different address spaces. You would need to code an estae or have a resmgr active to handle error situations and ensure that the STC is not left waiting. The submitted job would have to run on the same mvs image as the STC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
Guys, Yeah, I agree I have look at a subtask. This is a good idea, because of the different liars and error conditions. Long story for the question... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 11:07 PM, Sam Siegel s...@pscsi.net wrote: On Tue, Jan 31, 2012 at 7:52 PM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, That's a interesting idea... Scott You also need to handle the case like: 1) The submitted job gets a JCL error prior to executing your code; STC is never posted. 2) The submitted job gets queued up on resource contention; STC is left waiting for a long time. 3) The submitted job is forced off the system in a way that precludes the ESTAE from being invoked; STC is never posted. I think these can be solved by attaching a sub-task in the STC to monitor/wait for the submitted job to complete. The sub-task would need a stimer to handle the case where the submitted job does not post back. After a certain period of time, it is assumed that the submitted job failed, and then recovery processing or corrective actions are taken. Sam Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 10:32 PM, Sam Siegel s...@pscsi.net wrote: Scott - Does the submitted job run authorized? If it does, you can use a combination of name token service and pause element service to coordinate tcb in different address spaces. You would need to code an estae or have a resmgr active to handle error situations and ensure that the STC is not left waiting. The submitted job would have to run on the same mvs image as the STC. Sam On Tue, Jan 31, 2012 at 6:37 PM, Scott Ford scott_j_f...@yahoo.com wrote: Scheduler is out of the question, we are self-contained within a STC. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 31, 2012, at 9:18 PM, Lizette Koehler stars...@mindspring.com wrote: A timed approach is not great, how long do you wait, the submitted job creates a file... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com So the question becomes what are you trying to accomplish. Many scheduling packages have file triggers and dataset triggers that monitor the system (using SMF records) to see a dataset that is created. So are you trying t invent this type of process? If so, you should provide us with more details on what you are doing. A job that has a last step that does something may be a simpler process. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
On Tue, Jan 31, 2012 at 7:56 PM, Charles Mills charl...@mcn.org wrote: The submitted job would have to run on the same mvs image as the STC Right, Scott, that is a consideration. I job submitted via INTRDR might run on a different LPAR. Complicates the control block chaining. It can be control somewhat by using a /*ROUTE XEQ. However, there is the chance that this is overridden by an exit or automation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sam Siegel Sent: Tuesday, January 31, 2012 7:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr Scott - Does the submitted job run authorized? If it does, you can use a combination of name token service and pause element service to coordinate tcb in different address spaces. You would need to code an estae or have a resmgr active to handle error situations and ensure that the STC is not left waiting. The submitted job would have to run on the same mvs image as the STC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
A couple thoughts come to mind. - Use NOTIFY= on the job card to get a TSO message when the job completes - Code a simple SAPI application (SYSOUT API - See Using The Subsystem interface manual) that requests the output of the job. Provide an ECB so you will be posted when the output is available (when the job completes). Then just return the SYSOUT without processing it. - Code an ENF listen exit (ENFREQ macro) for ENF 70 and post your application when the desired job completes. Only the ENF listen exit requires you to be authorized. Tom Wasik JES2 Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
At 21:34 -0500 on 01/31/2012, Scott Ford wrote about Re: Intrdr: Liz, There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Try this: 1) Submit the Job 2) ENQ EXC TYPE=TEST on the dataset name. The RC will tell you if the job started yet. 3) Once you know it is running, do an ENQ SHR which will put you into a WAIT until the job ends. 4) SVC 99 allocate the dataset and run. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
At 20:47 -0500 on 01/31/2012, Lizette Koehler wrote about Re: Intrdr: Or you could add a last step to the job that sends a TSO SEND command to notify you. Or put NOTIFY= on the JOB CARD. Note: The Last Step method requires a COND=EVEN on its EXEC statement to insure that it runs even if a prior step ABENDs (and causes the rest of the steps to flush). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Intrdr
There is a STC running , similar in characteristics as CICS, runs all the time. Submits a job via Intrdr, job creates a Qsam file, STC must wait for job to complete, Because STC needs the data and it is single thread... Why does it have to be a submitted job? Can't you just link to the program, or programs one after the other, that create the file? Knowing more about this requirement might trigger new ideas. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
On Tue, 24 Jan 2012 15:55:07 -0600, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Tue, 24 Jan 2012 10:47:37 -0600, Walt Farrell wrote: They're jobs, but they enter the system via stcinrdr not intrdr. Are you saying that a started job is more like a job than like a started task? If so, it surprises me. I would have thought that once it is running it looks about the same as any started task. No. I'm trying to say that most, but not all, jobs come in via intrdr, and that started jobs are one of the exceptions. If the OP wants to change all jobs that come in via intrdr from CLASS=A to CLASS=R then that is very close to saying that he doesn't want CLASS=A at all. If that's the case, it's probably just easier to treat class A identically to class R, rather than writing an exit to change the job class. If it's not the case, the OP needs to explain more about what he's trying to do, in my opinion. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
my apologies, Thruput Manager does those tricks, not WLM. --- On Tue, 1/24/12, Greg Shirey wgshi...@benekeith.com wrote: From: Greg Shirey wgshi...@benekeith.com Subject: Re: change job classes for ones submitted via intrdr To: IBM-MAIN@bama.ua.edu Date: Tuesday, January 24, 2012, 2:03 PM Really? We use SMS at my shop to override some JCL, but I'm not sure I'd know how to use WLM in the manner you describe. Could you elaborate? Thanks, Greg Shirey Ben E. Keith Co. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Cris Hernandez #9 Sent: Tuesday, January 24, 2012 12:38 PM my sysprogs use WLM to wreck all kinds of havoc on my JCL parameters and the otherwise normal (default) OS functionality. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
change job classes for ones submitted via intrdr
Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
Get the to JES2 Installation Exits On Tue, 24 Jan 2012 07:21:23 -0500 Tim Brown tbr...@cenhud.com wrote: :Is there a way to control job classes that get submitted via intrdr : :If a job comes through say CLASS=A , have it changed to different class say CLASS=R : : : :Thanks, : : : :Tim Brown :Systems Specialist - Project Leader :Central Hudson Gas Electric :284 South Ave :Poughkeepsie, NY 12601 :Email: tbr...@cenhud.com mailto:tbr...@cenhud.com :Phone: 845-486-5643 :Fax: 845-486-5921 :Cell: 845-235-4255 : : : : :This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. : : : : : : :-- :For IBM-MAIN subscribe / signoff / archive access instructions, :send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R What version of z/OS? Which JES? JES2 or JES3? This information will help to determine a more focused response. But basically - YES, either through exits or other methods. If you have a more specific request it will help. Do you have any scheduling software? JOBTRAC, CA-ESP, Tivoli Scheduler etc... Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
if i get your question correctly, you do have options via the INTDR program to change classes on a Job in JES Queue. need to pass sysin JES commands. the SUbmitter ID/user shld have JES write access. On Tue, Jan 24, 2012 at 5:51 PM, Tim Brown tbr...@cenhud.com wrote: Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
You can provide a default job class for the INTRDR, however, JCL will override any JES2 specified defaults. If the submitter codes CLASS= on the job card, that is what will be used. JES2 Exit 6. Possibly JES2 Exit 2 or 44 can be used to modify the submitted JCL. I do not believe there is a specific exit for the INTRDR (Ed. J. jump in here!) . You will need some additional criteria to determine which jobs need to be modified. HTH, snip Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
On Tue, 24 Jan 2012 07:21:23 -0500, Tim Brown tbr...@cenhud.com wrote: Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R That question seems a bit odd to me. Have you considered that almost all jobs are submitted via intrdr? The exceptions would be jobs coming from a physical card reader (if any) or via RJE or NJE. Or STCs that are really started jobs rather than started tasks because they have a JOB statement in them. But anything else that's running basically came in via an intrdr, even if it's a production job scheduled by your production job scheduling system. Did you really mean something else? In any case, as others have indicated, you'd use JES or system exits to accomplish that, but what you'd need to do in them may differ depending on what you really meant. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
In 7792164355560880.wa.wfarrellus.ibm@bama.ua.edu, on 01/24/2012 at 07:37 AM, Walt Farrell wfarr...@us.ibm.com said: Or STCs that are really started jobs rather than started tasks because they have a JOB statement in them. AFAIK the processing is the same whether there is a default JOB statement or one from a file. In fact, I believe that you can START a proc with a job statement under MSTR. -- 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
On Tue, 24 Jan 2012 11:13:36 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 7792164355560880.wa.wfarrellus.ibm@bama.ua.edu, on 01/24/2012 at 07:37 AM, Walt Farrell wfarr...@us.ibm.com said: Or STCs that are really started jobs rather than started tasks because they have a JOB statement in them. AFAIK the processing is the same whether there is a default JOB statement or one from a file. In fact, I believe that you can START a proc with a job statement under MSTR. I'm not sure that's really relevant, though. They still are not submitted via intrdr. They're jobs, but they enter the system via stcinrdr not intrdr. I was pointing out that asking about jobs submitted via intrdr is very close to the same as asking about all jobs. His question had more the feel of how do I stop my TSO users from doing x, but with the possible misunderstanding that only TSO users use intrdr. So I wanted to point out his possible misunderstanding and find out what he's really trying to do. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
my sysprogs use WLM to wreck all kinds of havoc on my JCL parameters and the otherwise normal (default) OS functionality. --- On Tue, 1/24/12, Tim Brown tbr...@cenhud.com wrote: From: Tim Brown tbr...@cenhud.com Subject: change job classes for ones submitted via intrdr To: IBM-MAIN@bama.ua.edu Date: Tuesday, January 24, 2012, 7:21 AM Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
Really? We use SMS at my shop to override some JCL, but I'm not sure I'd know how to use WLM in the manner you describe. Could you elaborate? Thanks, Greg Shirey Ben E. Keith Co. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Cris Hernandez #9 Sent: Tuesday, January 24, 2012 12:38 PM my sysprogs use WLM to wreck all kinds of havoc on my JCL parameters and the otherwise normal (default) OS functionality. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
In 1907516522791856.wa.wfarrellus.ibm@bama.ua.edu, on 01/24/2012 at 10:47 AM, Walt Farrell wfarr...@us.ibm.com said: I'm not sure that's really relevant, though. They still are not submitted via intrdr. Yes, but that doesn't depend on whether they are started jobs. BTW, commands like MOUNT have a similar path to START; the system generates a JOB statement and submits JCL to STCINRDR. -- 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R What version of z/OS? Which JES? JES2 or JES3? This information will help to determine a more focused response. But basically - YES, either through exits or other methods. If you have a more specific request it will help. Do you have any scheduling software? JOBTRAC, CA-ESP, Tivoli Scheduler etc... Lizette There are also products like Thruput Manager, O/ESM, and EASYEXIT (DTS Software) that can manipulate your JCL prior to it getting to run. So you need to let us know if you have any of those products as well. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
Yes indeed this question has popped up on often. You have the easiest answer and probably the best. In a JES2 exit it is reasonably easy but then it depends on why you are changing it. I went at it at a two pronged attack. I did the exit and then I figured out that that it was easy to get around. In my case we had a jobclass's set up for tape or notape and I figured if the submitters weren't going to be honest I would look at every mount and then look at the jobclass and if they were in the wrong jobclass I issued a cancel with an appropriate message. Ed On Jan 24, 2012, at 7:37 AM, Walt Farrell wrote: On Tue, 24 Jan 2012 07:21:23 -0500, Tim Brown tbr...@cenhud.com wrote: Is there a way to control job classes that get submitted via intrdr If a job comes through say CLASS=A , have it changed to different class say CLASS=R That question seems a bit odd to me. Have you considered that almost all jobs are submitted via intrdr? The exceptions would be jobs coming from a physical card reader (if any) or via RJE or NJE. Or STCs that are really started jobs rather than started tasks because they have a JOB statement in them. But anything else that's running basically came in via an intrdr, even if it's a production job scheduled by your production job scheduling system. Did you really mean something else? In any case, as others have indicated, you'd use JES or system exits to accomplish that, but what you'd need to do in them may differ depending on what you really meant. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: change job classes for ones submitted via intrdr
On Tue, 24 Jan 2012 10:47:37 -0600, Walt Farrell wrote: They're jobs, but they enter the system via stcinrdr not intrdr. Are you saying that a started job is more like a job than like a started task? If so, it surprises me. I would have thought that once it is running it looks about the same as any started task. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Doc of RECFM, LRECL, BLKSIZE for INTRDR and SYSIN?
Gil, I saw an IBM PowerPoint via google for z/os 1.7 indicating 32k leech for sysin was new in 1.7 , so that would lead to believe it is , I would think an IBMer has to step up and verify the actual Maxmium. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 21, 2012, at 1:58 PM, Paul Gilmartin paulgboul...@aim.com wrote: I'm trying to find documention on limits on RECFM, LRECL, and BLKSIZE for SYSIN data sets and SYSOUT data assigned to INTRDR. I find some terse description in: Title: z/OS V1R13 DFSMS Using Data Sets Document Number: SC26-7410-11 3.5.2 SYSIN Data Set Which states that the minimum LRECL for a SYSIN data set is 80. It gives no maximum. 32760? Perhaps an RCF is in order. If the information is not now available, which publication should supply it? But I get lost in control blocks. I shouldn't need to be a systems programmer to get the information I need. I find very little useful additional information in the JCL Reference, which mentions that LRECL is permitted on DD * statements, but gives no maximum. And experiment shows that while LRECL is syntactically allowed, it has little or no effect. At some point, max LRECL was probably 80, keypunch width. some time later it may have been 254 for JES3 (I tested it). In 1995, OW10527 attempted to relax this limit for JES2. It was such a failure that IBM chose to regress it with by OW16774. OA08145 (NF, 2003?) mentions Support handling of SYSIN data with an LRECL254, but gives no maximum. What publication would this appear in? Would there be an announcement letter? It seems there have been enough changes that the documents haven't kept up and now contradict each other. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Doc of RECFM, LRECL, BLKSIZE for INTRDR and SYSIN?
That should have been 32k lrecl sorry Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 22, 2012, at 9:06 PM, Scott Ford scott_j_f...@yahoo.com wrote: Gil, I saw an IBM PowerPoint via google for z/os 1.7 indicating 32k leech for sysin was new in 1.7 , so that would lead to believe it is , I would think an IBMer has to step up and verify the actual Maxmium. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 21, 2012, at 1:58 PM, Paul Gilmartin paulgboul...@aim.com wrote: I'm trying to find documention on limits on RECFM, LRECL, and BLKSIZE for SYSIN data sets and SYSOUT data assigned to INTRDR. I find some terse description in: Title: z/OS V1R13 DFSMS Using Data Sets Document Number: SC26-7410-11 3.5.2 SYSIN Data Set Which states that the minimum LRECL for a SYSIN data set is 80. It gives no maximum. 32760? Perhaps an RCF is in order. If the information is not now available, which publication should supply it? But I get lost in control blocks. I shouldn't need to be a systems programmer to get the information I need. I find very little useful additional information in the JCL Reference, which mentions that LRECL is permitted on DD * statements, but gives no maximum. And experiment shows that while LRECL is syntactically allowed, it has little or no effect. At some point, max LRECL was probably 80, keypunch width. some time later it may have been 254 for JES3 (I tested it). In 1995, OW10527 attempted to relax this limit for JES2. It was such a failure that IBM chose to regress it with by OW16774. OA08145 (NF, 2003?) mentions Support handling of SYSIN data with an LRECL254, but gives no maximum. What publication would this appear in? Would there be an announcement letter? It seems there have been enough changes that the documents haven't kept up and now contradict each other. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Doc of RECFM, LRECL, BLKSIZE for INTRDR and SYSIN?
I'm trying to find documention on limits on RECFM, LRECL, and BLKSIZE for SYSIN data sets and SYSOUT data assigned to INTRDR. I find some terse description in: Title: z/OS V1R13 DFSMS Using Data Sets Document Number: SC26-7410-11 3.5.2 SYSIN Data Set Which states that the minimum LRECL for a SYSIN data set is 80. It gives no maximum. 32760? Perhaps an RCF is in order. If the information is not now available, which publication should supply it? But I get lost in control blocks. I shouldn't need to be a systems programmer to get the information I need. I find very little useful additional information in the JCL Reference, which mentions that LRECL is permitted on DD * statements, but gives no maximum. And experiment shows that while LRECL is syntactically allowed, it has little or no effect. At some point, max LRECL was probably 80, keypunch width. some time later it may have been 254 for JES3 (I tested it). In 1995, OW10527 attempted to relax this limit for JES2. It was such a failure that IBM chose to regress it with by OW16774. OA08145 (NF, 2003?) mentions Support handling of SYSIN data with an LRECL254, but gives no maximum. What publication would this appear in? Would there be an announcement letter? It seems there have been enough changes that the documents haven't kept up and now contradict each other. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Doc of RECFM, LRECL, BLKSIZE for INTRDR and SYSIN?
Probably however big you want to define the lrecl of the PDS you submit the job from. Used to be you could not edit datasets with LRECL over 251, so that was the limit. 32760 is probably the limit nowdays. I know in the mid 80s I did 255 lrecl from ROSCOE. I needed a sequential dataset for a list of volume, and could not create a lrecl under 10 bytes. On Sat, Jan 21, 2012 at 12:58 PM, Paul Gilmartin paulgboul...@aim.com wrote: I'm trying to find documention on limits on RECFM, LRECL, and BLKSIZE for SYSIN data sets and SYSOUT data assigned to INTRDR. I find some terse description in: Title: z/OS V1R13 DFSMS Using Data Sets Document Number: SC26-7410-11 3.5.2 SYSIN Data Set Which states that the minimum LRECL for a SYSIN data set is 80. It gives no maximum. 32760? Perhaps an RCF is in order. If the information is not now available, which publication should supply it? But I get lost in control blocks. I shouldn't need to be a systems programmer to get the information I need. I find very little useful additional information in the JCL Reference, which mentions that LRECL is permitted on DD * statements, but gives no maximum. And experiment shows that while LRECL is syntactically allowed, it has little or no effect. At some point, max LRECL was probably 80, keypunch width. some time later it may have been 254 for JES3 (I tested it). In 1995, OW10527 attempted to relax this limit for JES2. It was such a failure that IBM chose to regress it with by OW16774. OA08145 (NF, 2003?) mentions Support handling of SYSIN data with an LRECL254, but gives no maximum. What publication would this appear in? Would there be an announcement letter? It seems there have been enough changes that the documents haven't kept up and now contradict each other. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Weird INTRDR with REXX JCL steps
I'm having a strange JCL/REXX issue that I am hoping someone can help with. I am running one job that does a listcat, and then depending on the RC from the listcat, it will run the final step of the first job which is a REXX exec that submits JCL to the internal reader. Here is the JCL for this last job step: //STEP2EXEC PGM=IKJEFT01,DYNAMNBR=240,COND=(0,LT,LISTCAT) //SYSTSPRT DD SYSOUT=* //SYSEXEC DD DISP=SHR,DSN=SYS2.TECH.REXX //INPUTFIL DD DISP=SHR,DSN=MISC.DATASET.LISTCAT //OUTFIL DD SYSOUT=(*,INTRDR) //SYSTSIN DD * MKPERM The problem is that this submits a second job that contains 4 steps, of which one is similar to this step (REXX exec with SYSTSIN). It appears that when I try to submit the second job through the INTRDR the SYSTSIN in my REXX step of the second job gets lost. I can submit the JCL manually and it works fine. Here's the JCL from the bad step of the second job: //MKALTER EXEC PGM=IKJEFT01,REGION=8M,DYNAMNBR=300 //SYSEXEC DD DSN=SYS2.TECH.REXX,DISP=SHR //INPUTFIL DD DSN=AB07.PERMMIG.LISTINGS(+1),DISP=SHR //OUTFIL DD DSN=AB07.PERMMIG.ALTERS(+1),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE),DISP=(,CATLG) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * MKPERMLC When I let the job go through the INTRDR the MKPERMLC REXX exec does not execute, but when I manually run the JCL this step works fine. Does anyone have any ideas about this one? Thanks Todd Burrell -- 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: Weird INTRDR with REXX JCL steps
Todd, In SDSF enter INPUT ON to see of the systsin is empty or not. But the best way is to enter the exec name as a parameter to IKJEFT01 (e.g. //stepx exec pgm=ikjeft01,parm=mkperm,...). ITschak On Tue, Nov 10, 2009 at 7:43 PM, Todd Burrell z...@cdc.gov wrote: I'm having a strange JCL/REXX issue that I am hoping someone can help with. I am running one job that does a listcat, and then depending on the RC from the listcat, it will run the final step of the first job which is a REXX exec that submits JCL to the internal reader. Here is the JCL for this last job step: //STEP2EXEC PGM=IKJEFT01,DYNAMNBR=240,COND=(0,LT,LISTCAT) //SYSTSPRT DD SYSOUT=* //SYSEXEC DD DISP=SHR,DSN=SYS2.TECH.REXX //INPUTFIL DD DISP=SHR,DSN=MISC.DATASET.LISTCAT //OUTFIL DD SYSOUT=(*,INTRDR) //SYSTSIN DD * MKPERM The problem is that this submits a second job that contains 4 steps, of which one is similar to this step (REXX exec with SYSTSIN). It appears that when I try to submit the second job through the INTRDR the SYSTSIN in my REXX step of the second job gets lost. I can submit the JCL manually and it works fine. Here's the JCL from the bad step of the second job: //MKALTER EXEC PGM=IKJEFT01,REGION=8M,DYNAMNBR=300 //SYSEXEC DD DSN=SYS2.TECH.REXX,DISP=SHR //INPUTFIL DD DSN=AB07.PERMMIG.LISTINGS(+1),DISP=SHR //OUTFIL DD DSN=AB07.PERMMIG.ALTERS(+1),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE),DISP=(,CATLG) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * MKPERMLC When I let the job go through the INTRDR the MKPERMLC REXX exec does not execute, but when I manually run the JCL this step works fine. Does anyone have any ideas about this one? Thanks Todd Burrell -- 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
SV: Weird INTRDR with REXX JCL steps
How do MKPERM looks like ? (If the JCL is not in MKPERM but read from somewhere we need to see that file.) Regards, Thomas Berg __ Thomas Berg Specialist IT-U SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Todd Burrell Skickat: den 10 november 2009 18:43 Till: IBM-MAIN@bama.ua.edu Ämne: Weird INTRDR with REXX JCL steps I'm having a strange JCL/REXX issue that I am hoping someone can help with. I am running one job that does a listcat, and then depending on the RC from the listcat, it will run the final step of the first job which is a REXX exec that submits JCL to the internal reader. Here is the JCL for this last job step: //STEP2EXEC PGM=IKJEFT01,DYNAMNBR=240,COND=(0,LT,LISTCAT) //SYSTSPRT DD SYSOUT=* //SYSEXEC DD DISP=SHR,DSN=SYS2.TECH.REXX //INPUTFIL DD DISP=SHR,DSN=MISC.DATASET.LISTCAT //OUTFIL DD SYSOUT=(*,INTRDR) //SYSTSIN DD * MKPERM The problem is that this submits a second job that contains 4 steps, of which one is similar to this step (REXX exec with SYSTSIN). It appears that when I try to submit the second job through the INTRDR the SYSTSIN in my REXX step of the second job gets lost. I can submit the JCL manually and it works fine. Here's the JCL from the bad step of the second job: //MKALTER EXEC PGM=IKJEFT01,REGION=8M,DYNAMNBR=300 //SYSEXEC DD DSN=SYS2.TECH.REXX,DISP=SHR //INPUTFIL DD DSN=AB07.PERMMIG.LISTINGS(+1),DISP=SHR //OUTFIL DD DSN=AB07.PERMMIG.ALTERS(+1),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE),DISP=(,CATLG) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * MKPERMLC When I let the job go through the INTRDR the MKPERMLC REXX exec does not execute, but when I manually run the JCL this step works fine. Does anyone have any ideas about this one? Thanks Todd Burrell -- 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: Weird INTRDR with REXX JCL steps
Changing this to use the PARM actually seems to have fixed this issue. Although I have no idea why this wouldn't work the other way? But I'll incorporate this in the future. Thanks for the tip. C. Todd Burrell, PMP, MCP Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Itschak Mugzach Sent: Tuesday, November 10, 2009 12:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Weird INTRDR with REXX JCL steps Todd, In SDSF enter INPUT ON to see of the systsin is empty or not. But the best way is to enter the exec name as a parameter to IKJEFT01 (e.g. //stepx exec pgm=ikjeft01,parm=mkperm,...). ITschak On Tue, Nov 10, 2009 at 7:43 PM, Todd Burrell z...@cdc.gov wrote: I'm having a strange JCL/REXX issue that I am hoping someone can help with. I am running one job that does a listcat, and then depending on the RC from the listcat, it will run the final step of the first job which is a REXX exec that submits JCL to the internal reader. Here is the JCL for this last job step: //STEP2EXEC PGM=IKJEFT01,DYNAMNBR=240,COND=(0,LT,LISTCAT) //SYSTSPRT DD SYSOUT=* //SYSEXEC DD DISP=SHR,DSN=SYS2.TECH.REXX //INPUTFIL DD DISP=SHR,DSN=MISC.DATASET.LISTCAT //OUTFIL DD SYSOUT=(*,INTRDR) //SYSTSIN DD * MKPERM The problem is that this submits a second job that contains 4 steps, of which one is similar to this step (REXX exec with SYSTSIN). It appears that when I try to submit the second job through the INTRDR the SYSTSIN in my REXX step of the second job gets lost. I can submit the JCL manually and it works fine. Here's the JCL from the bad step of the second job: //MKALTER EXEC PGM=IKJEFT01,REGION=8M,DYNAMNBR=300 //SYSEXEC DD DSN=SYS2.TECH.REXX,DISP=SHR //INPUTFIL DD DSN=AB07.PERMMIG.LISTINGS(+1),DISP=SHR //OUTFIL DD DSN=AB07.PERMMIG.ALTERS(+1),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE),DISP=(,CATLG) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * MKPERMLC When I let the job go through the INTRDR the MKPERMLC REXX exec does not execute, but when I manually run the JCL this step works fine. Does anyone have any ideas about this one? Thanks Todd Burrell -- 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 -- 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: Weird INTRDR with REXX JCL steps
Add a // or /* as the last statement of the job. There used to be some issues where JES did not know if the submitted job stream was complete or not. The // or /* statement was a definitive delimiter for the job stream. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Todd Burrell Sent: Tuesday, November 10, 2009 11:43 AM To: IBM-MAIN@bama.ua.edu Subject: Weird INTRDR with REXX JCL steps I'm having a strange JCL/REXX issue that I am hoping someone can help with. I am running one job that does a listcat, and then depending on the RC from the listcat, it will run the final step of the first job which is a REXX exec that submits JCL to the internal reader. Here is the JCL for this last job step: //STEP2EXEC PGM=IKJEFT01,DYNAMNBR=240,COND=(0,LT,LISTCAT) //SYSTSPRT DD SYSOUT=* //SYSEXEC DD DISP=SHR,DSN=SYS2.TECH.REXX //INPUTFIL DD DISP=SHR,DSN=MISC.DATASET.LISTCAT //OUTFIL DD SYSOUT=(*,INTRDR) //SYSTSIN DD * MKPERM The problem is that this submits a second job that contains 4 steps, of which one is similar to this step (REXX exec with SYSTSIN). It appears that when I try to submit the second job through the INTRDR the SYSTSIN in my REXX step of the second job gets lost. I can submit the JCL manually and it works fine. Here's the JCL from the bad step of the second job: //MKALTER EXEC PGM=IKJEFT01,REGION=8M,DYNAMNBR=300 //SYSEXEC DD DSN=SYS2.TECH.REXX,DISP=SHR //INPUTFIL DD DSN=AB07.PERMMIG.LISTINGS(+1),DISP=SHR //OUTFIL DD DSN=AB07.PERMMIG.ALTERS(+1),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE),DISP=(,CATLG) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * MKPERMLC When I let the job go through the INTRDR the MKPERMLC REXX exec does not execute, but when I manually run the JCL this step works fine. Does anyone have any ideas about this one? Thanks Todd Burrell -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Weird INTRDR with REXX JCL steps
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Tuesday, November 10, 2009 12:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Weird INTRDR with REXX JCL steps Add a // or /* as the last statement of the job. There used to be some issues where JES did not know if the submitted job stream was complete or not. The // or /* statement was a definitive delimiter for the job stream. I always put in a /*EOF as well. Nothing like being paranoid! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Weird INTRDR with REXX JCL steps
It appears that when I try to submit the second job through the INTRDR the SYSTSIN in my REXX step of the second job gets lost. Although you have already found a work-around, I suspect you were not writing all of the lines from your REXX code. Did you also close the OUTFIL DD by including the FINIS option? Did you write it to a file to verify the data? -- 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: Weird INTRDR with REXX JCL steps
In a message dated 11/10/2009 12:40:57 P.M. Central Standard Time, john.mck...@healthmarkets.com writes: always put in a /*EOF as well. Nothing like being paranoid! NO GOATS, NO GLORY! Whatever happened to debugging? Write the output to a file and see what you got both ways and compare the differences? -- 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: Weird INTRDR with REXX JCL steps
- Original Message - From: Hal Merritt hmerr...@jackhenry.com Newsgroups: bit.listserv.ibm-main Sent: Tuesday, November 10, 2009 1:38 PM Subject: Re: Weird INTRDR with REXX JCL steps Add a // or /* as the last statement of the job. What he said, but I would do both /* // Regards, Tom Conley -- 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: Weird INTRDR with REXX JCL steps
What he said, but I would do both /* // While a // definitely denotes the end of the JCL for the current job, /* does not. /* terminates the current sysin dataset (note that DLM= may denote a different sequence). Why not put the data on the stack and use address TSO submit * from the REXX instead of writing to a DD that is allocated to the INTRDR? -- Peter Hunkeler Credit Suisse -- 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
BPXWDYN and the Internal Reader (INTRDR)
Hi Folks,
I am in need of some direction from this august body.
As a bit of fun I am trying to mimic the TSO SUBMIT command available in
REXX, by using BPXWDYN in a COBOL program to dynamically allocate an FTINCL
output file and write it to the internal reader.
The first BPXWDYN to allocate the FTINCL disk data set works a treat, i.e.
RC = .
The second BPXWDYN which attempts to allocate the output to the internal
reader fails with either rc=0025 or 002M (i.e. -24).
I will admit to not having experimented with the OUTDES component yet, but
am wondering whether this is actually possible given the BPXWDYN does not
have the full capability of TSO ALLOC, at least that is implied in the
manual.
The COBOL Working Storage elements are:
01 ALLOC-FT-JOB.
03 FILLER PIC X(30) VALUE
'ALLOC FI(JOBIN) SHR MSG(2) DA('.
03 FT-JOB-DSN PIC X(45) VALUE SPACES.
01 ALLOC-JES-JOB.
03 FILLER PIC X(38) VALUE
'ALLOC FI(JOBOUT) WRITER(INTRDR) MSG(2)'.
Kind regards - Terry
Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK
Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk
Company Reg: 3767263 at the above address
All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware, trojans,
viruses, and worms.
--
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: BPXWDYN and the Internal Reader (INTRDR)
Would a SYSOUT status keyword do the job?
ALLOC FI(JOBOUT) SYSOUT(x) WRITER(INTRDR) MSG(2
Just a guess.
David Elliot
zSeries Software Support
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Terry Sambrooks
Sent: Tuesday, June 30, 2009 1:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: BPXWDYN and the Internal Reader (INTRDR)
Hi Folks,
I am in need of some direction from this august body.
As a bit of fun I am trying to mimic the TSO SUBMIT command available in
REXX, by using BPXWDYN in a COBOL program to dynamically allocate an
FTINCL
output file and write it to the internal reader.
The first BPXWDYN to allocate the FTINCL disk data set works a treat,
i.e.
RC = .
The second BPXWDYN which attempts to allocate the output to the internal
reader fails with either rc=0025 or 002M (i.e. -24).
I will admit to not having experimented with the OUTDES component yet,
but
am wondering whether this is actually possible given the BPXWDYN does
not
have the full capability of TSO ALLOC, at least that is implied in the
manual.
The COBOL Working Storage elements are:
01 ALLOC-FT-JOB.
03 FILLER PIC X(30) VALUE
'ALLOC FI(JOBIN) SHR MSG(2) DA('.
03 FT-JOB-DSN PIC X(45) VALUE SPACES.
01 ALLOC-JES-JOB.
03 FILLER PIC X(38) VALUE
'ALLOC FI(JOBOUT) WRITER(INTRDR) MSG(2)'.
Kind regards - Terry
Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK
Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk
Company Reg: 3767263 at the above address
All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware,
trojans,
viruses, and worms.
--
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: BPXWDYN and the Internal Reader (INTRDR)
On Tue, 30 Jun 2009 13:42:23 -0500, Elliot, David wrote: Would a SYSOUT status keyword do the job? ALLOC FI(JOBOUT) SYSOUT(x) WRITER(INTRDR) MSG(2 Indeed. Absent SYSOUT, I get: u...@mvs:134$ rexx say bpxwdyn( 'ALLOC FI(JOBOUT) WRITER(INTRDR) MSG(WTP) reuse' ) 12.54.00 STC07716 IKJ56877I FILE JOBOUT NOT ALLOCATED, MUTUALLY INCLUSIVE PARAMETER MISSING 58982425 u...@mvs:135$ Suggestion: Depending on context, msg(2) works less or more well. I find msg(WTP) to be more portable. BTW, nowadays JCL needn't be fixed-80. I find it very liberating to be able to use longer lines in SYSIN, readily done if you allocate your own INTRDR. -- gil -- 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: BPXWDYN and the Internal Reader (INTRDR)
Terry Sambrooks wrote:
Hi Folks,
I am in need of some direction from this august body.
As a bit of fun I am trying to mimic the TSO SUBMIT command available in
REXX, by using BPXWDYN in a COBOL program to dynamically allocate an FTINCL
output file and write it to the internal reader.
Do you mean an FTINCL _input_ file?
The first BPXWDYN to allocate the FTINCL disk data set works a treat, i.e.
RC = .
The second BPXWDYN which attempts to allocate the output to the internal
reader fails with either rc=0025 or 002M (i.e. -24).
I will admit to not having experimented with the OUTDES component yet, but
am wondering whether this is actually possible given the BPXWDYN does not
have the full capability of TSO ALLOC, at least that is implied in the
manual.
The COBOL Working Storage elements are:
01 ALLOC-FT-JOB.
03 FILLER PIC X(30) VALUE
'ALLOC FI(JOBIN) SHR MSG(2) DA('.
03 FT-JOB-DSN PIC X(45) VALUE SPACES.
01 ALLOC-JES-JOB.
03 FILLER PIC X(38) VALUE
'ALLOC FI(JOBOUT) WRITER(INTRDR) MSG(2)'.
Kind regards - Terry
Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK
You haven't shown your procedure division call of BPXWDYN.
In our new 2-day course Writing z/OS CGIs in COBOL, we
tackle the problem of having a user request a job and a
parm string, then we allocate the input JCL and an output
file to intrdr, copy the input file to the output, substituting
the parm string at the appropriate time (among other interesting
tasks)
http://www.trainersfriend.com/UNIX_and_Web_courses/uc04descr.htm
It looks to me like you haven't allowed for the fact the input
to a call to BPXWDYN from a COBOL program uses a half-word
prefixed string. Here are some excerpts from the submit-a-job
lab solution from the course:
.
.
.
File-control.
Select jobin assign to jobin
file status is job-in-stat.
Select jobout assign to jobout
file status is job-out-stat.
Data division.
File section.
FD jobin.
01 jobin-rec pic x(80).
FD jobout.
01 jobout-recpic x(80).
.
.
.
Working-storage section.
* items used in file alloation and processing --
01 bpxwdyn pic x(8) value 'BPXWDYN'.
01 alloc1.
02pic s9(4) binary value 50.
02pic x(40)
value 'alloc fi(jobin) shr dsn(scomsto.tr.cntl('.
02 ddin pic x(10) value spaces.
01 alloc2.
02pic s9(4) binary value 66.
02pic x(40)
value 'alloc fi(jobout) sysout writer(intrdr) '.
02pic x(26)
value 'recfm(f) lrecl(80) msg(2) '.
01 free-in.
02pic s9(4) binary value 22.
02pic x(22) value 'free fi(jobin)'.
01 free-out.
02pic s9(4) binary value 22.
02pic x(22) value 'free fi(jobout)'.
01 job-out-stat pic 99.
01 job-in-stat pic 99.
.
.
.
* Allocate and OPEN files
*
file-setup.
call bpxwdyn using alloc1
if return-code = 0
open input jobin
if job-in-stat = 00
continue
else
display 'h2OPEN failed; code: '
job-in-stat '/h2'
perform html-end
goback
end-if
else
display 'h2Allocation of input file failed; code: '
return-code '/h2'
perform html-end
goback
end-if
call bpxwdyn using alloc2
if return-code = 0
open output jobout
if job-out-stat = 00
continue
else
display 'h2OPEN failed; code: '
job-out-stat '/h2'
perform html-end
goback
end-if
else
display 'h2Allocation of output file failed; code: '
return-code '/h2'
perform html-end
goback
end-if
... and lots more ...
Works fine.
Other techniques covered in this exciting course:
* emiting HTML to stdout using DISPLAY, printf, and calling
BPX1WRT
* Redirecting to an alternate page
* Accessing environment variables; displaying environment variables
* Handling GET requests
* Dynamically building HTML responses using data from a VSAM file
* Dynamically building HTML responses using data from a DB2 table
* Creating and handling hidden controls and cookies
* Handling POST requests
* Saving files in the HFS
* Emitting Unicode
and, of course,
* Submitting jobs
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming
Re: BPXWDYN and the Internal Reader (INTRDR)
Hi, Thanks for the prompt responses, my problem is now resolved. SYSOUT was indeed missing as having read the Using REXX and USS manual there was an implication that WRITER replaced SYSOUT on the ALLOC statement. My second problem was exactly has Steve pointed out. I had omitted the half word prefix containing the length. I somehow seemed to have bounced over that information when perusing the manual. Thanks again - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- 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: ISFP default intrdr assignments
On Thu, 11 Sep 2008 14:18:47 -0500, Anton Britz [EMAIL PROTECTED] wrote: How can I change the default INTRDR assignments for ISPF to //? DD sysout=(A,INTRDR),DEST=DUMMY Summary: I want to change the default print location of all jobs to DUMMY without inserting a route print card into every job submitted. I'm not sure what you mean by default INTRDR assignments for ISPF. Do you mean: (a) for all jobs users submit while they're using ISPF? (b) for all jobs users submit from TSO? (c) or something different? Within ISPF, users could submit jobs using the TSO/E SUBMIT command, or from ISPF Edit using the Edit SUB command. Or they could be outside of ISPF and submit jobs using the TSO/E SUBMIT command. Or they could do their own allocation of a DD to INTRDR, and simply copy jobs into that DD. Would you want to affect those, too? Also, I'm curious what you would accomplish with DEST=DUMMY. Is that some destination node name you've defined in JES? -- Walt -- 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: ISFP default intrdr assignments
Hi, Thanks for the responses and yes, I did not explain enough : The Environment : zOs 1.7 and Jes2 Yes, they use a destination DUMMY as their HOLD class in JES2 ( Historical reasons ) Yes, if you do not code a /*Route Print Dummy , you have production control shipping you tons of paper because Jes2 ships it to a Printer by default. Possible solution to saving paper : Add a 'DEST=DUMMY on every INTRDR for the Session Editors and the default printer destination for all jobs, changes to DUMMY and JES2 does not print by default. It is possible to do for the product SYSD and I thought, by now there must a control card for the ISPF/TSO submit facility, but my secretary could not find it before she left to go and play BINGO for the weekend. Note: I think she said BINGO or Drilling in Alaska but I do not think, the baby part refers to her at this point in her life.. as in Drill baby drill.. She watches a lot of TV and she thinks they where talking to her.. most of the time. Anton On Fri, 12 Sep 2008 08:36:39 -0500, Walt Farrell [EMAIL PROTECTED] wrote: On Thu, 11 Sep 2008 14:18:47 -0500, Anton Britz [EMAIL PROTECTED] wrote: How can I change the default INTRDR assignments for ISPF to //? DD sysout=(A,INTRDR),DEST=DUMMY Summary: I want to change the default print location of all jobs to DUMMY without inserting a route print card into every job submitted. I'm not sure what you mean by default INTRDR assignments for ISPF. Do you mean: (a) for all jobs users submit while they're using ISPF? (b) for all jobs users submit from TSO? (c) or something different? Within ISPF, users could submit jobs using the TSO/E SUBMIT command, or from ISPF Edit using the Edit SUB command. Or they could be outside of ISPF and submit jobs using the TSO/E SUBMIT command. Or they could do their own allocation of a DD to INTRDR, and simply copy jobs into that DD. Would you want to affect those, too? Also, I'm curious what you would accomplish with DEST=DUMMY. Is that some destination node name you've defined in JES? -- Walt -- 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: ISFP default intrdr assignments
Yes, if you do not code a /*Route Print Dummy , you have production control shipping you tons of paper because Jes2 ships it to a Printer by default. In 1981, we handled this a different way. We made SYSOUT=A a held class. In 2001, we re-genned LOCAL to have no printers, and made RMT13 the remote to handle the previously local printers (different shops). No JCL changes, no exits. - Too busy driving to stop for gas! -- 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
ISFP default intrdr assignments
Hi, How can I change the default INTRDR assignments for ISPF to //? DD sysout=(A,INTRDR),DEST=DUMMY Summary: I want to change the default print location of all jobs to DUMMY without inserting a route print card into every job submitted. Anton -- 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: ISFP default intrdr assignments
On Thu, 11 Sep 2008, Anton Britz wrote: Hi, How can I change the default INTRDR assignments for ISPF to //? DD sysout=(A,INTRDR),DEST=DUMMY Summary: I want to change the default print location of all jobs to DUMMY without inserting a route print card into every job submitted. Anton Well, it is technically possible. However, at least from what little I know, the TSO SUB command does a dynamic allocation for the INTRDR. The only way that I can think of to change this is to either zap or replace the TSO SUBMIT command, or use the Dynamic Allocation exit to change the text fields to include the DEST=DUMMY field. This is the IEFDB401 exit. It is documented in the z/OS Installation Exits manual. -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
IIRC, JES2 runs the number of INTRDR processors (tasks) specifien on the INTRDR init statement. Not sure what happens when more SYSOUT=(*,INTRDR) than INTRDR PCEs are trying to submit jobs. I guess that the OPEN will just wait for an INTRDR PCE to become available to handle the request. No matter, INTRDRs don't start the batch jobs (and it's only batch jobs, so STCINRDR is out of scope), they only write the JCL to the JES2 spool queueing then on the conversion queue. Some time later the conversion PCEs will pick up the JCLs and place the converted JCL onto the spool queueing the jobs on the execution queue. Again some time later, those jobs will eventually be picked by an initiator that *is already running* when using JES managed initiators. No new address spaces are being created. If using WLM managed initiators, WLM decides it more of them shall be started depending on current system load. We often have burst of batch jobs submitted from our scheduler when day end processing is scheduled on our test system. The execution queue has some 150+ jobs waiting to be executed but this does not slow down the system in any special manner. -- Peter Hunkeler CREDIT SUISSE -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
I don't know if you can specify the number of conversion tasks allowed or not; last time I tried to care, I couldn't specify a number for conversion tasks, but I could specify up to 10 INTRDR's. Number of conversion tasks is specified on the PCEDEF statement (CNVTNUM=). I think it's been there for a lng time (JES2 V3 at least). -- Peter Hunkeler Credist Suisse -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
Neil, you mentioned that you were getting $HASP050: 90% JNUM messages during your problem time periods. Others have suggested PCE settings and some other ways to increase the number of internal readers, in order to increase throughput. Personally, I'd also look at ways to avoid JNUM 90% and to increase the total number of jobs that can be in the system at any given time. Can you tell us your settings that control JNUM? Can you increase those values, without exceeding maximums (or third- party software limitations on job numbers, ranges, format of JOBID, etc)? That's where I'd start looking at to solve this issue. Regards, Ulrich Krueger On Wed, 25 Jun 2008 18:23:59 -0400, Neil Duffee [EMAIL PROTECTED] wrote: Hey there. I'm grasping at straws and am hoping someone remembers their JES2 internals. I've looked in the JES2 Innita Tuna? manual (Ch 2. Controlling JES2 processes) without success and can't find a RedBook that helps. Perhaps someone remembers or can point me to a Fine Manual. (I'll ETR otherwise.) Background: z/OS v1.7, DB2 v7. During our (peak) registration periods, we experience occasional, un-explainable slow-downs in 1-3 minute bursts on the order of 3-5 in a 2-3 day period. To date, no particular culprit has been positively identified. Aside from 100% CPU 20+ un- dispatched tasks, one reported symptom is an increasing number of DB2 threads (from OmegaMon) waiting for Stored Procedure start-ups ie. for WLM to start another address space. (@15 TCBs each) Sure enough, once the dust settles, there can be 10+ WLM address spaces that slowly disappear as idle. This line of inquiry (among others) focuses on JES2's internal readers. We suspect processes generating e-mail to students with a 1-1 ratio of jobs to messages ie. 1 job=1 e-message, using SYSOUT=(*,INTRDR). (We're also pursuing multi-step jobs since $HASP050: 90% JNUM has already been encountered.) In a given scenario, we could have 200+ jobs with e- mail (bulk to a large class) directed at INTRDR while WLM is trying to start 1-5 Stored Procedure address spaces via STCINRDR. So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) As mentioned before, if there's no satisfactory consensus, I'll pursue an ETR and relay the response. Tks much folx. -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
In a message dated 6/26/2008 12:14:42 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Personally, I'd also look at ways to avoid JNUM 90% and to increase the total number of jobs that can be in the system at any given time. Can you tell us your settings that control JNUM? Can you increase those values, without exceeding maximums (or third- party software limitations on job numbers, ranges, format of JOBID, etc)? That's where I'd start looking at to solve this issue. Well guess a good place to start would be offloading the SMTP services to another machine or using UDP(Lionel's got a good write up in his XMITIP gem at _www.lbdsoftware.com_ (http://www.lbdsoftware.com) ). For DB/2 have to watch threads like a hawk. When they spill over to the common pool big time bottlenecks(hangs) while it thrashes it out with everything else. Then there's just bad SQL. What's his name(Platinum) quotes 70% for performance problems. **Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut000507) -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
If you believe that the slow down is in JES, have you researched the output from JMonitor and/or the JDHistory, etc. These usually go a long way in explaining what JES is doing and what's its problem? Jack Kelly 202-502-2390 (Office) -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
Neil Duffee wrote: ... This line of inquiry (among others) focuses on JES2's internal readers. We suspect processes generating e-mail to students with a 1-1 ratio of jobs to messages ie. 1 job=1 e-message, using SYSOUT=(*,INTRDR). (We're also pursuing multi-step jobs since $HASP050: 90% JNUM has already been encountered.) In a given scenario, we could have 200+ jobs with e-mail (bulk to a large class) directed at INTRDR while WLM is trying to start 1-5 Stored Procedure address spaces via STCINRDR. So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) I'm assuming your JES2 is also at z/OS 1.7 level. I suspect your problem doesn't lie in INTRDR processing. As of z/OS 1.7 JES2 internal readers are processed in the address space that allocates them--you can't even specify how many there are. So their own TCBs is yes. Bob -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
At 18:23 -0400 on 06/25/2008, Neil Duffee wrote about z/OS v1.7 JES2: StcInRdr vs. IntRdr: So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) If you think you might have contention in JES2, you might want to try going to Poly-JES. This is basically starting a 2nd copy of JES2 on the CPU as another member of your JES2 Multi-Access Spool system. You submit the INTRDR Jobs with an /*EQU MEMBER2 Card and they will execute on the 2nd JES2 along with using its INTRDRs. The jobs that are submitted can either /*EQU back to the main JES2 or execute on MEMBER2. When not handling this work MEMBER2 is essentially idle and has little impact on the Main JES2 Member (set the MEMBER2 Spool Hold settings to quickly release the Checkpoint Record so it does not impact the Main JES@ Mamber). If you know when you will be doing the flood submission of EMAIL Jobs, you can start MEMBER2 and then shut it down when you are done to control its impact when not doing anything. -- 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
z/OS v1.7 JES2: StcInRdr vs. IntRdr
Hey there. I'm grasping at straws and am hoping someone remembers their JES2 internals. I've looked in the JES2 Innita Tuna? manual (Ch 2. Controlling JES2 processes) without success and can't find a RedBook that helps. Perhaps someone remembers or can point me to a Fine Manual. (I'll ETR otherwise.) Background: z/OS v1.7, DB2 v7. During our (peak) registration periods, we experience occasional, un-explainable slow-downs in 1-3 minute bursts on the order of 3-5 in a 2-3 day period. To date, no particular culprit has been positively identified. Aside from 100% CPU 20+ un-dispatched tasks, one reported symptom is an increasing number of DB2 threads (from OmegaMon) waiting for Stored Procedure start-ups ie. for WLM to start another address space. (@15 TCBs each) Sure enough, once the dust settles, there can be 10+ WLM address spaces that slowly disappear as idle. This line of inquiry (among others) focuses on JES2's internal readers. We suspect processes generating e-mail to students with a 1-1 ratio of jobs to messages ie. 1 job=1 e-message, using SYSOUT=(*,INTRDR). (We're also pursuing multi-step jobs since $HASP050: 90% JNUM has already been encountered.) In a given scenario, we could have 200+ jobs with e-mail (bulk to a large class) directed at INTRDR while WLM is trying to start 1-5 Stored Procedure address spaces via STCINRDR. So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) As mentioned before, if there's no satisfactory consensus, I'll pursue an ETR and relay the response. Tks much folx. -- signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- 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: z/OS v1.7 JES2: StcInRdr vs. IntRdr
-snip--- Hey there. I'm grasping at straws and am hoping someone remembers their JES2 internals. I've looked in the JES2 Innita Tuna? manual (Ch 2. Controlling JES2 processes) without success and can't find a RedBook that helps. Perhaps someone remembers or can point me to a Fine Manual.(I'll ETR otherwise.) Background: z/OS v1.7, DB2 v7. During our (peak) registration periods, we experience occasional, un-explainable slow-downs in 1-3 minute bursts on the order of 3-5 in a 2-3 day period. To date, no particular culprit has been positively identified. Aside from 100% CPU 20+ un-dispatched tasks, one reported symptom is an increasing number of DB2 threads (from OmegaMon) waiting for Stored Procedure start-ups ie. for WLM to start another address space. (@15 TCBs each) Sure enough, once the dust settles, there can be 10+ WLM address spaces that slowly disappear as idle. This line of inquiry (among others) focuses on JES2's internal readers. We suspect processes generating e-mail to students with a 1-1 ratio of jobs to messages ie. 1 job=1 e-message, using SYSOUT=(*,INTRDR). (We're also pursuing multi-step jobs since $HASP050: 90% JNUM has already been encountered.) In a given scenario, we could have 200+ jobs with e-mail (bulk to a large class) directed at INTRDR while WLM is trying to start 1-5 Stored Procedure address spaces via STCINRDR. So, the question is, presuming it's already working on INTRDR, how does JES2 contend with this load? Are all the jobs in INTRDR converted then JES2 switches to STCINRDR? Does STCINRDR have precedence for JES2 and INTRDR is interrupted at the next JOB card? Are they simultaneous with their own TCBs? Curious minds would like to know. (or even hear speculation...) As mentioned before, if there's no satisfactory consensus, I'll pursue an ETR and relay the response. Tks much folx. --unsnip- Neil, what's the observed CPU utilization of your JES2? If it's not really high, I'd suggest you look elsewhere. It's been a long time since I looked in this area, but IIRC, STC's take a slightly different path through JES2 processing. A more likely culprit might be AS-Create; even more likely, IMHO, a ENQ/DEQ contention issue. JES2 uses something called a PCE, a Process Control Element, to represent multiple INTRDR's, rather than TCB's. They're managed internally by JES2 and typically run fairly quickly. I'm not sure, but I think conversion is done under a PCE as well, so the CPU time involved would be attributed to JES2. How many INTRDR's do you have defined? I don't know if you can specify the number of conversion tasks allowed or not; last time I tried to care, I couldn't specify a number for conversion tasks, but I could specify up to 10 INTRDR's. Without a much broader picture of your system, it's going to be hard to make any definitive diagnosis. Are you running RMF? I like RMF, with a 10-minute recording interval. If you'll do that, over a period where you're affected by this issue, and send me the reports, beginning two periods before and ending two periods after, I'll try and give you some pointers. (ZIP the reports, please.) :-) -- 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
RDINUM RDI(INTRDR) RDI(STCINRDR)
I am running with the default JES2 RDINUM of 100 (which gives you 102) It breaks down as RDI(TSOINRDR) = 1, RDI(INTRDR) = 49, RDI(STCINRDR) = 52 Question: IS RDINUM always evenly (almost) split between INTRDR and STCINRDR or can I set the limits separately? I recently ran out of INTRDR and need to increase but it appears that I have excess STCINRDR so I would like to have more INTRDR and keep STCINRDR the same. Thanks all Ken Porowski AVP Systems Software CIT Group E: [EMAIL PROTECTED] -- 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: RDINUM RDI(INTRDR) RDI(STCINRDR)
Oops, my bad, Operators bounced the INITS so it ate a bunch of STCINRDR + what is hard allocated to CICS regions etc. TFM (Jes2 IT Guide not Reference) states there is no specific allocation between STCINRDR and INTRDR and that they are allocated as needed. Apologies for the diversion. _ From: Porowski, Ken Sent: Tuesday, September 26, 2006 11:59 AM To: 'IBM Mainframe Discussion List' Subject: RDINUM RDI(INTRDR) RDI(STCINRDR) I am running with the default JES2 RDINUM of 100 (which gives you 102) It breaks down as RDI(TSOINRDR) = 1, RDI(INTRDR) = 49, RDI(STCINRDR) = 52 Question: IS RDINUM always evenly (almost) split between INTRDR and STCINRDR or can I set the limits separately? I recently ran out of INTRDR and need to increase but it appears that I have excess STCINRDR so I would like to have more INTRDR and keep STCINRDR the same. Thanks all Ken Porowski AVP Systems Software CIT Group E: [EMAIL PROTECTED] -- 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
