info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
reasons for using started task or batch job
763 views
Skip to first unread message
Pommier, Rex R.
Aug 10, 2012, 11:51:09 AM8/10/12
to
Hi List,
I'm sure this has been discussed but I can't find it in the archives (probably due to my inability to narrow the search down).
What would be the reason(s) for starting long-running tasks like CICS as a started task or a batch job? My foggy brain seems to remember there being issues with running multi-step started tasks, and something about there not being as much data gathered (performance, diagnostics, that kind of stuff) for a started task versus a batch job.
Any pointers to limitations or other info one way or the other would be appreciated.
Thanks.
Rex
The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
I'm sure this has been discussed but I can't find it in the archives (probably due to my inability to narrow the search down).
What would be the reason(s) for starting long-running tasks like CICS as a started task or a batch job? My foggy brain seems to remember there being issues with running multi-step started tasks, and something about there not being as much data gathered (performance, diagnostics, that kind of stuff) for a started task versus a batch job.
Any pointers to limitations or other info one way or the other would be appreciated.
Thanks.
Rex
The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
McKown, John
Aug 10, 2012, 12:05:44 PM8/10/12
to
What you have said was true in the past, about jobs having more data in SMF than STCs sometimes did. Some STCs must still be single step, such as an external writer or anything running a program in the PPT. This is not true of CICS. We run multi-step CICS regions as started jobs (not tasks) as our standard. Perhaps some shops ran a process as a job just in order to run multiple steps which were procs. In the past, an STC had to be a single PROC. Also, with STC (started procs), all the STCs ran with the same, generated, pseudo-JOB card. Some shops wanted to run with different job accounting parameters, for billing purposed. They either had to do some fancy exit programming, or ran as a batch job. But with started jobs, you can now run an STC as a "started job" (complete with JOB card with all parameters except CLASS=) with multiple EXEC PROC= steps. Also, you can now nest PROCs and so have an STC be a PROC, but that that PROC can run the other PROCs required in order.
We run CICS as a "started job". I changed to this on the first release of z/OS in which it was available.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@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
We run CICS as a "started job". I changed to this on the first release of z/OS in which it was available.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@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
Chris Mason
Aug 11, 2012, 12:39:24 PM8/11/12
to
John
Regarding your paranoia - pay-back time for false accusations of "ranting"! - over the PPT:
> Some STCs must still be single step, such as ... anything running a program in the PPT.
The best policy here would be actually to read up on what is said about multiple/single steps in the description of the attributes of a PPT entry as covered by the description of the PPT statement of the SCHEDxx member in the z/OS MVS Initialization and Tuning Reference manual:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2C1/76.6
Out of infinite kindness, I present the pointers here:
<quote>
...
For NODSI, the job must be a one-step job. If the job is not a one-step job, NODSI is nullified and the system issues message IEF188I. All other properties remain in effect.
...
For SYST, the program must be a one-step job started by a START or MOUNT command. If these conditions are not met, SYST is nullified and the system issues message IEF188I. All other properties remain in effect.
If procedures are multistep or if NOSYST is specified, TIME=1440 may be required to prevent timeout.
...
</quote>
As I have mentioned on a few occasions in IBM-MAIN in posts which have clearly been ignored, long ago in the days when I education/test systems, I encountered the irritating multiple step restriction caused by the SYST attribute. With the aid of the PPT statement of the SCHEDxx member of SYS1.PARMLIB, I simply denuded the infected program name of the SYST attribute and was happily able to run VTAM (ISTINM01), NetView(DSIMNT or BNJLINTX) and the address space corresponding to the IP component of Communications Server - "TCP/IP for MVS" at the time - (EZBTCPIP) as multiple steps without "issue". (What a shame they are childless!)
One - perhaps the only one - of my objectives was to enable the introduction of an IEFBR14 step at the beginning of the procedure in order to ensure[1] that "trace and dump" data sets from any previous executions of the procedures were deleted - by the use of DISP=(MOD,DELETE). I was then able to allocate them as DISP=NEW data sets with minimal primary space allocation - keeping the limited DASD space at the disposal of my multiple systems all "neat and tidy". I appreciate that the considerations relating to my education/test environment do not apply to a production environment but, if the design of an "application" would suit multiple steps in the procedure, being put off because the PPT table CSECT, IEFSDPPT (module IEFSD060), entry for the program name happens to have the SYST attribute set should *not* be an inhibitor.[2]
There is one consideration when SYST is removed which is that the EXEC statement associated with the previously infected program will now need TIME=1440 - or the equivalent.
> Perhaps some shops ran a process as a job just in order to run multiple steps which were procs.
It is certain that actually reading the manual would have been more productive in the long run - but there's no accounting for folk!
> In the past, an STC had to be a single PROC.
How far into the past would that be? I used to play "fast and loose" with the SYST attribute from around the late 1980s IMMSMC.
-
[1] I've just read a post where the word "insure" was used when it was "ensure" that made sense of what appeared to be being said. Is this yet another case of folk between the shining seas "evolving" the originally English language?
From Googling:
- ensure: Make certain that (something) shall occur or be the case.
- insure: Provide insurance coverage
[2] I did ask about whether there might be some disadvantages undocumented in the description of the SYST attribute in the z/OS MVS Initialization and Tuning Reference manual in IBM-MAIN some time ago. There were a few replies but no evidence of hidden dangers was forthcoming.
Archive reference (Search on Subject Contains: SYST, Author's Address: Mason):
Subject: SYST
From: Chris Mason
Date: Sat, 25 Feb 2006 16:58:39 +0100
Hm! Having made sure that I could refer folk to my "SYST" thread, I couldn't resist reminding myself of the responses. It turns out that some character going by the name of "John McKown" responded. Now, who would that be, I wonder?
-
Chris Mason
On Fri, 10 Aug 2012 11:05:28 -0500, McKown, John <John....@HEALTHMARKETS.COM> wrote:
>What you have said was true in the past, about jobs having more data in SMF than STCs sometimes did. Some STCs must still be single step, such as an external writer or anything running a program in the PPT. This is not true of CICS. We run multi-step CICS regions as started jobs (not tasks) as our standard. Perhaps some shops ran a process as a job just in order to run multiple steps which were procs. In the past, an STC had to be a single PROC. Also, with STC (started procs), all the STCs ran with the same, generated, pseudo-JOB card. Some shops wanted to run with different job accounting parameters, for billing purposed. They either had to do some fancy exit programming, or ran as a batch job. But with started jobs, you can now run an STC as a "started job" (complete with JOB card with all parameters except CLASS=) with multiple EXEC PROC= steps. Also, you can now nest PROCs and so have an STC be a PROC, but that that PROC can run the other PROCs required in order.
>
>We run CICS as a "started job". I changed to this on the first release of z/OS in which it was available.
>
>--
>John McKown
Regarding your paranoia - pay-back time for false accusations of "ranting"! - over the PPT:
> Some STCs must still be single step, such as ... anything running a program in the PPT.
The best policy here would be actually to read up on what is said about multiple/single steps in the description of the attributes of a PPT entry as covered by the description of the PPT statement of the SCHEDxx member in the z/OS MVS Initialization and Tuning Reference manual:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2C1/76.6
Out of infinite kindness, I present the pointers here:
<quote>
...
For NODSI, the job must be a one-step job. If the job is not a one-step job, NODSI is nullified and the system issues message IEF188I. All other properties remain in effect.
...
For SYST, the program must be a one-step job started by a START or MOUNT command. If these conditions are not met, SYST is nullified and the system issues message IEF188I. All other properties remain in effect.
If procedures are multistep or if NOSYST is specified, TIME=1440 may be required to prevent timeout.
...
</quote>
As I have mentioned on a few occasions in IBM-MAIN in posts which have clearly been ignored, long ago in the days when I education/test systems, I encountered the irritating multiple step restriction caused by the SYST attribute. With the aid of the PPT statement of the SCHEDxx member of SYS1.PARMLIB, I simply denuded the infected program name of the SYST attribute and was happily able to run VTAM (ISTINM01), NetView(DSIMNT or BNJLINTX) and the address space corresponding to the IP component of Communications Server - "TCP/IP for MVS" at the time - (EZBTCPIP) as multiple steps without "issue". (What a shame they are childless!)
One - perhaps the only one - of my objectives was to enable the introduction of an IEFBR14 step at the beginning of the procedure in order to ensure[1] that "trace and dump" data sets from any previous executions of the procedures were deleted - by the use of DISP=(MOD,DELETE). I was then able to allocate them as DISP=NEW data sets with minimal primary space allocation - keeping the limited DASD space at the disposal of my multiple systems all "neat and tidy". I appreciate that the considerations relating to my education/test environment do not apply to a production environment but, if the design of an "application" would suit multiple steps in the procedure, being put off because the PPT table CSECT, IEFSDPPT (module IEFSD060), entry for the program name happens to have the SYST attribute set should *not* be an inhibitor.[2]
There is one consideration when SYST is removed which is that the EXEC statement associated with the previously infected program will now need TIME=1440 - or the equivalent.
> Perhaps some shops ran a process as a job just in order to run multiple steps which were procs.
> In the past, an STC had to be a single PROC.
-
[1] I've just read a post where the word "insure" was used when it was "ensure" that made sense of what appeared to be being said. Is this yet another case of folk between the shining seas "evolving" the originally English language?
From Googling:
- ensure: Make certain that (something) shall occur or be the case.
- insure: Provide insurance coverage
[2] I did ask about whether there might be some disadvantages undocumented in the description of the SYST attribute in the z/OS MVS Initialization and Tuning Reference manual in IBM-MAIN some time ago. There were a few replies but no evidence of hidden dangers was forthcoming.
Archive reference (Search on Subject Contains: SYST, Author's Address: Mason):
Subject: SYST
From: Chris Mason
Date: Sat, 25 Feb 2006 16:58:39 +0100
Hm! Having made sure that I could refer folk to my "SYST" thread, I couldn't resist reminding myself of the responses. It turns out that some character going by the name of "John McKown" responded. Now, who would that be, I wonder?
-
Chris Mason
On Fri, 10 Aug 2012 11:05:28 -0500, McKown, John <John....@HEALTHMARKETS.COM> wrote:
>What you have said was true in the past, about jobs having more data in SMF than STCs sometimes did. Some STCs must still be single step, such as an external writer or anything running a program in the PPT. This is not true of CICS. We run multi-step CICS regions as started jobs (not tasks) as our standard. Perhaps some shops ran a process as a job just in order to run multiple steps which were procs. In the past, an STC had to be a single PROC. Also, with STC (started procs), all the STCs ran with the same, generated, pseudo-JOB card. Some shops wanted to run with different job accounting parameters, for billing purposed. They either had to do some fancy exit programming, or ran as a batch job. But with started jobs, you can now run an STC as a "started job" (complete with JOB card with all parameters except CLASS=) with multiple EXEC PROC= steps. Also, you can now nest PROCs and so have an STC be a PROC, but that that PROC can run the other PROCs required in order.
>
>We run CICS as a "started job". I changed to this on the first release of z/OS in which it was available.
>
>--
>John McKown
Shmuel Metz , Seymour J.
Aug 12, 2012, 10:49:08 AM8/12/12
to
In
<3EBF9C9D119FD847B3A0...@SURFSDVMP35.cnasurety.net>,
on 08/10/2012
in the address space.
>My foggy brain seems to remember there being issues with running
>multi-step started tasks,
If you require an entry in the PPT, the same restrictions apply for a
started task and a batch job.
>and something about there not being as much data gathered
There used to be an SMF restriction, but these days it's under parmlib
control.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
<3EBF9C9D119FD847B3A0...@SURFSDVMP35.cnasurety.net>,
on 08/10/2012
at 03:50 PM, "Pommier, Rex R." <Rex.P...@CNASURETY.COM> said:
>What would be the reason(s) for starting long-running tasks like CICS
>as a started task or a batch job?
START doesn't tie up an initiator, and there's one less jobstep task
>What would be the reason(s) for starting long-running tasks like CICS
>as a started task or a batch job?
in the address space.
>My foggy brain seems to remember there being issues with running
>multi-step started tasks,
started task and a batch job.
>and something about there not being as much data gathered
control.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Vernooij, CP - SPLXM
Aug 13, 2012, 2:25:38 AM8/13/12
to
Besides the reasons for STC or job from the past, there is one important
difference from the 'modern' area: STCs can fully use system symbols
while jobs cannot (or hardly).
Kees.
"Pommier, Rex R." <Rex.P...@CNASURETY.COM> wrote in message
news:<3EBF9C9D119FD847B3A0...@SURFSDVMP35.cnasurety.net
>...
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************
difference from the 'modern' area: STCs can fully use system symbols
while jobs cannot (or hardly).
Kees.
"Pommier, Rex R." <Rex.P...@CNASURETY.COM> wrote in message
news:<3EBF9C9D119FD847B3A0...@SURFSDVMP35.cnasurety.net
>...
> Hi List,
>
> I'm sure this has been discussed but I can't find it in the archives
(probably due to my inability to narrow the search down).
>
>
> I'm sure this has been discussed but I can't find it in the archives
(probably due to my inability to narrow the search down).
>
> What would be the reason(s) for starting long-running tasks like CICS
as a started task or a batch job? My foggy brain seems to remember
there being issues with running multi-step started tasks, and something
about there not being as much data gathered (performance, diagnostics,
that kind of stuff) for a started task versus a batch job.
>
> Any pointers to limitations or other info one way or the other would
be appreciated.
>
> Thanks.
>
> Rex
>
> The information contained in this e-mail may contain confidential
and/or privileged information and is intended for the sole use of the
intended recipient. If you are not the intended recipient, you are
hereby notified that any unauthorized use, disclosure, distribution or
copying of this communication is strictly prohibited and that you will
be held responsible for any such unauthorized activity, including
liability for any resulting damages. As appropriate, such incident(s)
may also be reported to law enforcement. If you received this e-mail in
error, please reply to sender and destroy or delete the message and any
attachments. Thank you.
>
there being issues with running multi-step started tasks, and something
about there not being as much data gathered (performance, diagnostics,
that kind of stuff) for a started task versus a batch job.
>
> Any pointers to limitations or other info one way or the other would
be appreciated.
>
> Thanks.
>
> Rex
>
> The information contained in this e-mail may contain confidential
and/or privileged information and is intended for the sole use of the
intended recipient. If you are not the intended recipient, you are
hereby notified that any unauthorized use, disclosure, distribution or
copying of this communication is strictly prohibited and that you will
be held responsible for any such unauthorized activity, including
liability for any resulting damages. As appropriate, such incident(s)
may also be reported to law enforcement. If you received this e-mail in
error, please reply to sender and destroy or delete the message and any
attachments. Thank you.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
********************************************************
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************
Barry Merrill
Aug 14, 2012, 12:39:49 PM8/14/12
to
Except for the existence of SMF 30 EXCP segments based on SMFPRMxx options,
(i.e., whether they exist in the Step term and Job term records, where
they cause problems for long running STCs, causing virtual storage
exhaustion,
or whether they are only in the Interval records, so they are still counted,
and which is recommended for long running STCs), I'm not aware of any other
differences in the SMF data created for a batch job versus a started task.
Can someone educate me if there are other differences in data?
I have a very old note that says that running a task as a Started Task
rather
than as a JOB bypasses some validity checking, but that if all of the
STEPLIB
datasets are Authorized, that same validity checking is bypassed for a JOB.
But I have no more details nor any proof, now.
Barry Merrill
(i.e., whether they exist in the Step term and Job term records, where
they cause problems for long running STCs, causing virtual storage
exhaustion,
or whether they are only in the Interval records, so they are still counted,
and which is recommended for long running STCs), I'm not aware of any other
differences in the SMF data created for a batch job versus a started task.
Can someone educate me if there are other differences in data?
I have a very old note that says that running a task as a Started Task
rather
than as a JOB bypasses some validity checking, but that if all of the
STEPLIB
datasets are Authorized, that same validity checking is bypassed for a JOB.
But I have no more details nor any proof, now.
Barry Merrill
Ed Gould
Aug 14, 2012, 8:54:49 PM8/14/12
to
Berry:
We had an STC that processed sysouts (some off the wall product that
may not be around now). If we didn't suppress the type 30's (I think
its been a while). Whenever we would bring it down it would literally
cause the SMF address space to run at 100 per cent cpu for hours
writing out type 30's records. It took me weeks to figure it out.
Even trying to take a dump of SMF address space was fun. I took a
SALONE and did some hunting and looking around and found type 30's
were the culprit. We needed them for accounting. Trying to dump
(IFSMFDMP) the smf datasets was hopeless when this was happening. We
had to schedule extra OT for the operators and they weren't happy.
Ed
Our operators hated being there as they couldn't leave until the
system came down
We had an STC that processed sysouts (some off the wall product that
may not be around now). If we didn't suppress the type 30's (I think
its been a while). Whenever we would bring it down it would literally
cause the SMF address space to run at 100 per cent cpu for hours
writing out type 30's records. It took me weeks to figure it out.
Even trying to take a dump of SMF address space was fun. I took a
SALONE and did some hunting and looking around and found type 30's
were the culprit. We needed them for accounting. Trying to dump
(IFSMFDMP) the smf datasets was hopeless when this was happening. We
had to schedule extra OT for the operators and they weren't happy.
Ed
Our operators hated being there as they couldn't leave until the
system came down
Barry Merrill
Aug 14, 2012, 9:25:14 PM8/14/12
to
The problem you describe was found by Dianne Eppestein at Southwestern Bell
in 1987
in 19xx and Bill Richardson at IBM SMF created the DDCONS=NO option that
eliminated
the CPU time when there were tens of thousands of DD segments at step
termination.
But the same problem would impact any long-running asid, batch job or
started task,
that created many DD segments.
From MXG Newsletters:
In 1987, Diane Eppestine at Southwestern Bell saw that whenever their
SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to
100% busy for 30-60 minutes. Instruction traces found the "loop" was in
DD Consolidation. SAR dynamically allocates a DD for each SYSOUT file
it processes; by the end of the week that step had over 75,000 DD
entries! DD consolidation reads the first DD segment, scans the
remaining 74,999 segments for a match, reads the second and scans the
remaining 74,998 for a match, etc. etc., etc., all at DPRTY=FE! In
response to Diane's discovery, Bill Richardson, IBM SMF Development,
subsequently provided a new SMF option, DDCONS(NO), specified in
SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my
opinion) algorithm, and thereby eliminate its wasted CPITCBTM and
CPISRBTM CPU time.
in 1987
in 19xx and Bill Richardson at IBM SMF created the DDCONS=NO option that
eliminated
the CPU time when there were tens of thousands of DD segments at step
termination.
But the same problem would impact any long-running asid, batch job or
started task,
that created many DD segments.
From MXG Newsletters:
In 1987, Diane Eppestine at Southwestern Bell saw that whenever their
SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to
100% busy for 30-60 minutes. Instruction traces found the "loop" was in
DD Consolidation. SAR dynamically allocates a DD for each SYSOUT file
it processes; by the end of the week that step had over 75,000 DD
entries! DD consolidation reads the first DD segment, scans the
remaining 74,999 segments for a match, reads the second and scans the
remaining 74,998 for a match, etc. etc., etc., all at DPRTY=FE! In
response to Diane's discovery, Bill Richardson, IBM SMF Development,
subsequently provided a new SMF option, DDCONS(NO), specified in
SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my
opinion) algorithm, and thereby eliminate its wasted CPITCBTM and
CPISRBTM CPU time.
Bonaduce, Frank
Aug 17, 2012, 1:27:05 PM8/17/12
to
Kees -
You can exploit the use of system symbolic in batch using an IEFUJV exit. We have been doing this for several years.
Frank.
GSG Systems Engineering
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM
Sent: Monday, August 13, 2012 2:25 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: reasons for using started task or batch job
You can exploit the use of system symbolic in batch using an IEFUJV exit. We have been doing this for several years.
Frank.
GSG Systems Engineering
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM
Sent: Monday, August 13, 2012 2:25 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: reasons for using started task or batch job
0 new messages