JCL return code in REXX
Tulasi Mohan Telaga
I have submitted JCL from REXX. After that I need to know the Job got
completed successfully and then I need to process some other part in my
REXX code.
Can some one help me, how I can do this. In REXX, once we submit JOB,
that will run in batch and the remaining part of REXX code starts
executing.
Thanks,
Tulasi
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Jeff Byrum
Meanwhile, you can submit the job with OUTTRAP in effect and the parse the results to get the job number:
x=OUTTRAP("SUB.")
address TSO " SUBMIT " DSN
x=OUTTRAP("OFF")
Then, you basically just have to keep checking (in a loop) to see if the job has completed yet, with:
ADDRESS TSO "STATUS" jobname"("jobid")"
but be sure to put some kind of "sleep" or "wait" in the loop so you are not checking too frequently and using up too many resources.
Once you detect the job has completed, you can use:
ADDRESS TSO "OUTPUT" . . .
to retrieve the job output into a dataset.
Hopefully someone can post the example from the original example...
Jeff
Mohan, Jayaraj , Cognizant
Easy way is to add a step at the end of ur JCL to execute "the remaining part of REXX code" in batch. You can set a condition to execute this step only if return code of previous step is 0.
sample step
//IKJEFT01 EXEC PGM=IKJEFT01,COND=(0,NE)
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SUB 'xxx.xxx.REXX(xxxxxxxx)'
/*
//*
Hope this is what you want.
Thanks
Jayaraj
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU]On Behalf
Of Tulasi Mohan Telaga
Sent: Tuesday, December 21, 2004 4:48 PM
To: TSO-...@VM.MARIST.EDU
Subject: JCL return code in REXX
Hi,
I have submitted JCL from REXX. After that I need to know the Job got
completed successfully and then I need to process some other part in my
REXX code.
Can some one help me, how I can do this. In REXX, once we submit JOB,
that will run in batch and the remaining part of REXX code starts
executing.
Thanks,
Tulasi
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.
Visit us at http://www.cognizant.com
Alain Janssens
REXX waits until job has ended or (disadvantage) timed out.
regards,
Alain
Jeff Byrum (21/12/2004 13:07):
mailto:alain.j...@B-RAIL.BE
----------------------------------------------------------------------
Jeremy C B Nicoll
<56E2573C375A41419111...@kecmsg06.ad.infosys.com>,
Tulasi Mohan Telaga <tulasi...@INFOSYS.COM> wrote:
> Hi,
>
> I have submitted JCL from REXX. After that I need to know the Job got
> completed successfully and then I need to process some other part in
> my REXX code.
It's a bad idea; the submitted job might never run (eg if the jes
initiators are drained), and meantime your tso session will be wasting
time waiting for something that won't happen.
If you must do this, have the last step of the job create a dataset
with a unique name, only if the job works, and have the tso/ispf bit
occasionally check if the dataset has been created. Or, better, create
a flagfile just before you submit the job, eg called
...MYJOB.FLAGFILE.SUBBED
and make sure the submitted job knows the name of its own flagfile.
You can have it rename that at the start eg to
...MYJOB.FLAGFILE.STARTED
and changed to ...MYJOB.FLAGFILE.RANOK or ...MYJOB.FLAGFILE.FAILED in
the final step(s) according to whether the job worked.
Then you only have to look for datasets with those names to se how the
job is progressing.
--
Jeremy C B Nicoll - my opinions are my own.
Paul Gilmartin
> Date: Tue, 21 Dec 2004 13:31:39 +0000
> >
> > I have submitted JCL from REXX. After that I need to know the Job got
> > completed successfully and then I need to process some other part in
> > my REXX code.
>
> It's a bad idea; the submitted job might never run (eg if the jes
> initiators are drained), and meantime your tso session will be wasting
> time waiting for something that won't happen.
>
You're jumping to a conclusion: the original poster never said a TSO
session was involved. (I know; this is the TSO-REXX list, but is there
a separate forum which is preferred for "z/OS Rexx outside TSO"?)
My question, though, is whether submitting a batch job is necessary:
is there any processing in the batch job which can not be done within
the Rexx code with "address ATTCHMVS ..." replacing "//STEP EXEC ..."?
That's my preferred mode of operation; it allows me, e.g. to generate
a summary file with the results of each step, and to do more complex
revovery, e.g. creating a data set if allocation fails because it
doesn't exist.
-- gil
--
StorageTek
INFORMATION made POWERFUL
Scott, John , Endevor
on any lpar in a sysplex and include DB2 binding.
After the job is submitted it looks up parms to works out which DB2
subsystem it needs to bind for.
We don't have DB2 datasharing across all the lpars and some DB2 subsystems
only run on certain lpars.
However we don't know where the DB2 processing is to run until after the
Endevor job has started running and Endevor has checked the parms.
It seems we will need to submit a second job to be directed to the relevant
lpar but don't want the first job to issue RC=0 unless the second job has
been okay.
The technique of submitting a second job and waiting until its okay, either
by tso status command or waiting for a dataset to be allocated as people
have suggested.
Is there any other way to get the DB2 bind processing (REXX/TSO DSN command)
to run on a different lpar than the one where the first job was sumbmitted
without using a second job ?
The Royal Bank of Scotland plc, Registered in Scotland No. 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
The Royal Bank of Scotland plc is authorised and regulated by the Financial Services Authority and represents The Royal Bank of Scotland Marketing Group. The Bank sells life policies, collective investment schemes and pension products and advises only on the Marketing Group's range of these products and on a With-Profit Bond produced by Norwich Union Life (RBS) Limited.
This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
Steve Comstock
MJay...@CHN.COGNIZANT.COM writes:
> Hi Tulasi,
> Easy way is to add a step at the end of ur JCL to execute "the remaining
> part of REXX code" in batch. You can set a condition to execute this step
> only if return code of previous step is 0.
>
> sample step
>
>
> //IKJEFT01 EXEC PGM=IKJEFT01,COND=(0,NE)
>
> //SYSTSPRT DD SYSOUT=*
>
> //SYSTSIN DD *
>
> SUB 'xxx.xxx.REXX(xxxxxxxx)'
>
> /*
>
>
Why would you ever propose using COND when IF THEN has been around for almost
20 years and is much more flexible, maintainable, and readable?
Kind regards,
-Steve Comstock
Bob Bridges
then stopped reading the manual except for the occasional reminder. I
didn't know IF/THEN had been invented for JCL until three or four years
ago.
---
Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
rhb...@attglobal.net, 847 520-1684 xt 243
/* Happiness isn't getting what you want, it's wanting what you've got.
-Garth Brooks */
Steve Comstock <SCom...@AOL.COM>
2004-12-21 09:10
To: TSO-...@VM.MARIST.EDU
cc:
Subject: Re: JCL return code in REXX
Why would you ever propose using COND when IF THEN has been around for
almost 20 years and is much more flexible, maintainable, and readable?
--- In a message dated 12/21/2004 5:05:21 AM Mountain Standard Time,
MJay...@CHN.COGNIZANT.COM writes:
> Easy way is to add a step at the end of ur JCL to execute "the
remaining
> part of REXX code" in batch. You can set a condition to execute this
step
> only if return code of previous step is 0.
>
> //IKJEFT01 EXEC PGM=IKJEFT01,COND=(0,NE)
> //SYSTSPRT DD SYSOUT=*
> //SYSTSIN DD *
> SUB 'xxx.xxx.REXX(xxxxxxxx)'
----------------------------------------------------------------------
Farley, Peter x23353
years back but have yet to use it. Ossification of the JCL brain cells, I
suppose. :)
<rant>
OTOH, I am still mad at IBM for making certain VSAM parameters only
available in one of the JCL "class" definitions (I think it's DATACLAS,
don't remember off hand at the moment and too lazy to look it up). This
means you MUST have a cooperative and responsive Storage Admin to allocate
new VSAM files in JCL only (no IDCAMS). This is just plain stupid and lazy
on IBM's part, IMNSHO. It means the programmer does not have full control
of the definition of his own files.
</rant>
Peter
_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Dave Salt
process. If the foreground process submits a batch job and the batch job
doesn't run (JCL error, inititators drained, etc.) then the foreground job
is sitting there waiting for something that's never going to happen. Or,
maybe the initiators are full and the batch job goes into a queue and the
foreground process has to wait 5, 10, 15 minutes...
The whole point of submitting batch jobs is to prevent a foreground session
being tied up. To submit a batch job and then have the foreground session
tied up while it waits for the batch job to finish just doesn't make any
sense.
To do what you want there are a couple of alternatives. You could submit a
batch job with an extra step that finishes doing whatever it was you wanted
the original REXX to do. Or, convert the JCL to REXX format (e.g. allocate
the ddnames in your REXX program and call the program from REXX) so that
everything is done in foreground.
HTH,
Dave Salt
Soft-Center Solutions Inc.
http://www.soft-center.com
1-877-SoftCen
Bringing you SimpList(tm) - The easiest, most powerful way to surf a
mainframe!
Farley, Peter x23353
Control Program) example with REXX. The Buroughs MCP operating system was
written in a subset of Algol 60, and the control language you used to run
"batch" jobs was that exact same subset of Algol (no I/O facilities, but
file allocation, program execution, utilities execution, etc. were all done
in the same language). You had all the looping and procedural language
elements that you use for application programming available to control your
"batch" process. Very powerful concept.
*ix variants followed a similar path with the various "shell" dialects.
Everything you can do is under control of the same "shell" program, and all
your interactions with the system ("online" or "batch") are performed in
that language.
A juduciously staged migration to REXX as the ONLY "JOB" control language
*could* have been started 15 or 20 years ago. It would be *so* much easier
to teach and learn than cryptic JCL. Also more powerful, easier to
maintain, etc., etc. I have always guessed that the old(er) farts at IBM
back then were head-in-the-sand MVS bigots, and didn't want something
invented by those pesky VM clowns to take over "their" OS.
Peter
> -----Original Message-----
> From: Paul Gilmartin [mailto:gil...@UNIX.STORTEK.COM]
> Sent: Tuesday, December 21, 2004 9:23 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: JCL return code in REXX
>
>
> In a recent note, Jeremy C B Nicoll said:
>
> > Date: Tue, 21 Dec 2004 13:31:39 +0000
> > >
> > > I have submitted JCL from REXX. After that I need to know the Job
> > > got completed successfully and then I need to process some other
> > > part in my REXX code.
> >
> > It's a bad idea; the submitted job might never run (eg if the jes
> > initiators are drained), and meantime your tso session will
> be wasting
> > time waiting for something that won't happen.
> >
> You're jumping to a conclusion: the original poster never
> said a TSO session was involved. (I know; this is the
> TSO-REXX list, but is there a separate forum which is
> preferred for "z/OS Rexx outside TSO"?)
>
> My question, though, is whether submitting a batch job is
> necessary: is there any processing in the batch job which can
> not be done within the Rexx code with "address ATTCHMVS ..."
> replacing "//STEP EXEC ..."? That's my preferred mode of
> operation; it allows me, e.g. to generate a summary file with
> the results of each step, and to do more complex revovery,
> e.g. creating a data set if allocation fails because it doesn't exist.
>
> -- gil
> --
> StorageTek
> INFORMATION made POWERFUL
_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
Thomas H Parker
years is more like it), but it was definitely before the turn of the
century (remember y2k?)
Tom Parker
8616 Freeport Parkway, Room 3B223
Irving, TX 75063
Phone: 469 499 8603
----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------
"Farley, Peter x23353" <Peter_Farley
@ADP.COM>
Sent by: TSO REXX Discussion List <TSO-REXX
12/21/2004 09:45 AM
Please respond to TSO REXX Discussion List
To: TSO-...@VM.MARIST.EDU
cc:
Subject: Re: JCL return code in REXX
I'll second that response. I learned that IF THEN exists for JCL a few
years back but have yet to use it. Ossification of the JCL brain cells, I
suppose. :)
<rant>
OTOH, I am still mad at IBM for making certain VSAM parameters only
available in one of the JCL "class" definitions (I think it's DATACLAS,
don't remember off hand at the moment and too lazy to look it up). This
means you MUST have a cooperative and responsive Storage Admin to allocate
new VSAM files in JCL only (no IDCAMS). This is just plain stupid and
lazy
on IBM's part, IMNSHO. It means the programmer does not have full control
of the definition of his own files.
</rant>
Peter
> -----Original Message-----
> From: Bob Bridges [mailto:robert...@DISCOVERFINANCIAL.COM]
> Sent: Tuesday, December 21, 2004 10:35 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: JCL return code in REXX
>
>
> Some of us old farts learned everything there was to know
> about JCL and then stopped reading the manual except for the
> occasional reminder. I didn't know IF/THEN had been invented
> for JCL until three or four years ago.
>
> ---
> Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
> rhb...@attglobal.net, 847 520-1684 xt 243
>
> /* Happiness isn't getting what you want, it's wanting what
> you've got. -Garth Brooks */
>
> Steve Comstock <SCom...@AOL.COM>
> 2004-12-21 09:10
>
> To: TSO-...@VM.MARIST.EDU
> cc:
> Subject: Re: JCL return code in REXX
>
> Why would you ever propose using COND when IF THEN has been
> around for almost 20 years and is much more flexible,
> maintainable, and readable?
>
> --- In a message dated 12/21/2004 5:05:21 AM Mountain
> Standard Time, MJay...@CHN.COGNIZANT.COM writes:
> > Easy way is to add a step at the end of ur JCL to execute "the
> remaining
> > part of REXX code" in batch. You can set a condition to execute this
> step
> > only if return code of previous step is 0.
> >
> > //IKJEFT01 EXEC PGM=IKJEFT01,COND=(0,NE)
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN DD *
> > SUB 'xxx.xxx.REXX(xxxxxxxx)'
_
Steve Comstock
Bob Bridges writes:
> Some of us old farts learned everything there was to know about JCL and
> then stopped reading the manual except for the occasional reminder. I
> didn't know IF/THEN had been invented for JCL until three or four years
> ago.
>
>
I was going to let this pass, since it is a common
enough kind of remark from us long-time folks in
the biz, but then I started thinking about it a
little, and I decided to challenge it.
[And this is not just for Bob, or Peter Farley
who made a similar comment, but for everyone who
has been around a while.]
Don't you think this attitude encourages the
management perception that us old farts are
expendable? Those low-priced folks over in
India, China, Eastern Europe, and so on know
how important it is to _know_ the most effective
way to do things. If they want to get our jobs,
it is important not only to offer low prices
but you have to compete on quality. You don't
think they aren't out learning all they can
so they can compete? While us "old farts" lean
back comfortable in the illusion of our
invicibility?
Of course, I have an agenda: I make my living
doing technical training. Full disclosure.
But that doesn't lessen the validity of my point:
we continually deny our vulnerability while we
see colleagues down sized and outsourced; we
refuse to take responsiblity for our own technical
and professional growth; we adopt a sense of
inevitability regarding the demise of the mainframe.
We do all the wrong things to enhance and
extend our careers. We don't put any effort into
selling and promoting the things that can be
done from today's mainframe platform.
Of course, there are exceptions. The folks who
make SHARE possible, along with other events and
conferences, and those who fight the good fight
inside their companies, and those who write
articles, and those who make it a point to keep
current, and who share their knowledge with
their co-workers through brown bag sessions and
internal training and mentoring. And, yes,
those who share and help on listserv's and
usenet's.
But there is a serious problem here, and most
of us are not doing much to be part of the
solution. That can only hurt us in the not-so-long
run.
I am not saying nor implying that I have the
answers or solutions. But I am keenly aware of
the problems, and I sometimes get disheartened
by indifference.
Kind regards,
-Steve Comstock
Robert Zenuk
John.P...@RBS.CO.UK writes:
Endevor job has started running and Endevor has checked the parms.
It seems we will need to submit a second job to be directed to the relevant
lpar but don't want the first job to issue RC=0 unless the second job has
been okay.
The technique of submitting a second job and waiting until its okay, either
by tso status command or waiting for a dataset to be allocated as people
have suggested.
In general, I have to agree, having a REXX EXEC (batch or TSO online) wait
for a batch job to complete is bad design. It can be done if you jump through
enough flaming hoops. The FTP JES interface is a pretty cool way of doing
this, but the timeout issue is a formidable hurdle. Usually, there is a
better way to design the process that avoids things slipping into (what the user
will perceive as) the "black hole".
In the Endevor example; it seems to me you could do the Endevor stuff in one
step to gather the required information needed to know which LPAR to submit
the second job (apparently the valid DB2 hosting LPAR and SSID). The second
job could be submitted from a second batch TSO REXX step in the original job
based on a valid condition code from the Endevor step. This second step
could either use ISPF FT processing to generate the valid /*ROUTE XEQ xxxx and/or
*/JOBPARM SYSAFF=xxxx or a non ISPF approach to generating the JCL. This is
presumably to perform your Precompile/Compile/Link processing (or processed
module copying). Unless I'm missing something, it sounds like the second job
could also be multi-step and based on the success of the language processing
could then include the JCL for a batch DB2 Bind (again based on condition
codes). The generated JCL could easily fill in all the JES routing details,
program/source/copy locations/details and DB2 subsystem information based on
the results of the initial Endevor job (I am assuming you are already
extracting/parsing the Endevor details in a way your REXX EXEC can process it).
In this scenario, the second job is the critical job that does all the work.
Why do you need the original job to wait? If this is a status posting
issue, the second job could submit a job back to the originating system (using
the same JCL generation approach from above) and again, based on condition
codes the posting job submitted by the second job would complete the process on
the originating LPAR. I have seen this approach used between steps as well.
This allows the posting of interim job/step status on another LPAR outside of
the current Sysplex.
A very simplistic example of this could be to use a simple TSO SEND command
at the appropriate points in the second job's processing. In the example
above, the first step in the second job would be a REXX step that would submit a
job back to the originating LPAR. It's only role in life is to send the
original submitter a message saying the job started on the target LPAR. It
could also display the LPAR, DB2 SSID and anything else you could fit in TSO
SEND's character limit (maybe a generated SMTP email example would be better).
After the precompile, send another message, after the compile, send another
message, after the link, send another message, after the DB2 Bind, send another
message, etc.
Obviously, the "posting" steps could do more than just a TSO SEND (or SMTP
email), but that would be up to you to decide how to implement a cross LPAR
(and/or Sysplex) posting process. I have seen this implemented as ISPF table
updates (and a "status viewer"), DB2 table updates (and a "status viewer"),
creating "status" datasets (use 3.4 to research success), generating "status"
HTML that is FTP'd to a Web Server (fills in a "status" Web Page that uses
<META HTTP-EQUIV="Refresh" CONTENT=nn> for an auto-refresh). There are many,
many ways to do this...
Is there any other way to get the DB2 bind processing (REXX/TSO DSN command)
to run on a different lpar than the one where the first job was sumbmitted
without using a second job ?
Not that I am aware of...
Hope This Helps,
Rob
Hamilton, Robert L
on the AS/400. Unfortunately, the Control Language was a mess;
Fortunately, 400REXX is pretty good and I wrote control pgms in REXX.
bobh
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Farley, Peter x23353
Sent: Tuesday, December 21, 2004 10:03 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: JCL return code in REXX
Peter
> Sent: Tuesday, December 21, 2004 9:23 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: JCL return code in REXX
>
>
> In a recent note, Jeremy C B Nicoll said:
>
> > Date: Tue, 21 Dec 2004 13:31:39 +0000
> > >
> > > I have submitted JCL from REXX. After that I need to know the Job
> > > got completed successfully and then I need to process some other
> > > part in my REXX code.
> >
> > It's a bad idea; the submitted job might never run (eg if the jes
> > initiators are drained), and meantime your tso session will
> be wasting
> > time waiting for something that won't happen.
> >
> You're jumping to a conclusion: the original poster never said a TSO
> session was involved. (I know; this is the TSO-REXX list, but is
> there a separate forum which is preferred for "z/OS Rexx outside
> TSO"?)
>
> My question, though, is whether submitting a batch job is
> necessary: is there any processing in the batch job which can not be
> done within the Rexx code with "address ATTCHMVS ..."
> replacing "//STEP EXEC ..."? That's my preferred mode of operation; it
> allows me, e.g. to generate a summary file with the results of each
> step, and to do more complex revovery, e.g. creating a data set if
> allocation fails because it doesn't exist.
>
> -- gil
> --
> StorageTek
> INFORMATION made POWERFUL
_
This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and
confidential. If the reader of the message is not the intended recipient
or an authorized representative of the intended recipient, you are
hereby notified that any dissemination of this communication is strictly
prohibited. If you have received this communication in error, please
notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
Scott, John , Endevor
that the processing needs to run on a certain lpar depending on the db2
subsystem being processed.
Endevor runs in one step and stores the return code (if its failed then the
element cannot be moved to prod without reprocessing)
That is the resaon we need to make the Endevor job wait or leave it to the
users to remember to find out where their db2 is that day and change the
jobcard sysaff accordingly.
> -----Original Message-----
> From: Robert Zenuk [SMTP:Robz...@AOL.COM]
> Sent: Tuesday, December 21, 2004 4:26 PM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: JCL return code in REXX
>
> *** WARNING : This message originates from the Internet ***
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
The Royal Bank of Scotland plc, Registered in Scotland No. 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
The Royal Bank of Scotland plc is authorised and regulated by the Financial Services Authority and represents The Royal Bank of Scotland Marketing Group. The Bank sells life policies, collective investment schemes and pension products and advises only on the Marketing Group's range of these products and on a With-Profit Bond produced by Norwich Union Life (RBS) Limited.
This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
----------------------------------------------------------------------
Jim Harrison
mention of an IF statement. And that probably explains why I've never tried it
before.
Quoting Thomas H Parker <tpar...@CSC.COM>:
> I can't say that I found IF/THEN/ELSE for JCL 20 years ago, (perhaps 10
> years is more like it), but it was definitely before the turn of the
> century (remember y2k?)
>
> Tom Parker
>
> 8616 Freeport Parkway, Room 3B223
> Irving, TX 75063
>
> Phone: 469 499 8603
>
>
----------------------------------------------------------------------
Michael Ebert
don't know about your quality; they don't even know you exist except as a
number. All they see is the price tag.
This doesn't mean it is unnecessary to go to trainings and conferences and
so on, of course... except that to management, this is again just a
bothersome cost factor.
Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany
From: Steve Comstock <SCom...@AOL.COM>@VM.MARIST.EDU on 21-12-2004
11:25 EST
Please respond to TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
cc:
Subjec Re: JCL return code in REXX
t:
Bob Bridges writes:
....
But there is a serious problem here, and most
of us are not doing much to be part of the
solution. That can only hurt us in the not-so-long
run.
I am not saying nor implying that I have the
answers or solutions. But I am keenly aware of
the problems, and I sometimes get disheartened
by indifference.
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
Farley, Peter x23353
*must* stay current, and share our knowledge (via SHARE and internal and the
net, all as you say). Especially, sharing our mainframe design and
implementation experiences is the best way to help our midlle-tier
compatriots remember all the security and reliability lessons we learned
through the school of hard knocks, and also the best way to show management
that the mainframe is where the business can (more) safely be bet.
I am certainly not indifferent to the vulnerability of my employment
position. 5 years of consulting between permanent positions taught me that
no one's position is invulnerable. We are all, indeed, expendable identical
cogs in the minds of the bean counters.
I believe (perhaps naively) that most of us who are left do not stint on
"keeping up with the Jones's". I have been running Linux at home for
several years now, and I know of many others who keep their hands active in
both the mainframe and "other" computing arenas, if only for the sheer joy
of increasing our knowledge base. Personally, I have been able to produce
material for my management that would not have been possible without the use
of *ix-based utilities and facilities. I still need to keep learning, it is
a life-long job IMHO.
But you have to admit, the JCL IF/THEN facility is a very, very poor feature
compared to, say, REXX (to keep on-topic for this forum) looping and
procedural capabilities. Why bother using it when it adds (IMHO) very
little readbility to an already cryptic language? *IF* it had been allowed
to go where *ix shell languages have long-since been and permit testing and
looping based on JCL and system symbolic variable contents, *THEN* it would
be a significant enough facility to start using actively. In my judgement,
the condition-code-only capability is just not enough of an "advance" to
bother with.
Best regards, and Happy Holidays to you and yours.
Peter
> Of course, there are exceptions. The folks who
> make SHARE possible, along with other events and
> conferences, and those who fight the good fight
> inside their companies, and those who write
> articles, and those who make it a point to keep
> current, and who share their knowledge with
> their co-workers through brown bag sessions and
> internal training and mentoring. And, yes,
> those who share and help on listserv's and
> usenet's.
>
> But there is a serious problem here, and most
> of us are not doing much to be part of the
> solution. That can only hurt us in the not-so-long
> run.
>
> I am not saying nor implying that I have the
> answers or solutions. But I am keenly aware of
> the problems, and I sometimes get disheartened
> by indifference.
>
>
> Kind regards,
>
> -Steve Comstock
_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
Robert Zenuk
Peter_...@ADP.COM writes:
<rant>
OTOH, I am still mad at IBM for making certain VSAM parameters only
available in one of the JCL "class" definitions (I think it's DATACLAS,
don't remember off hand at the moment and too lazy to look it up). This
means you MUST have a cooperative and responsive Storage Admin to allocate
new VSAM files in JCL only (no IDCAMS). This is just plain stupid and lazy
on IBM's part, IMNSHO. It means the programmer does not have full control
of the definition of his own files.
</rant>
It does not need the DATACLAS parameter. Here is a working example:
//jobcard...
//****************************************************************
//* DEFINE A CLUSTER USING JCL *
//****************************************************************
//DEFVSAM EXEC PGM=IEFBR14
//MYKSDS DD DSN=your.CLUSTER,UNIT=SYSDA,LRECL=80,
// AVGREC=(K),KEYLEN=10,KEYOFF=0,RECORG=KS,DISP=(,CATLG),
// SPACE=(80,(100,10))
//****************************************************************
//REPRO EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//IN DD *
0000000001 RECORD 1
0000000002 RECORD 2
0000000003 RECORD 3
0000000004 RECORD 4
0000000005 RECORD 5
//OUT DD DSN=your.CLUSTER,DISP=SHR
//SYSIN DD *
REPRO INFILE(IN) OUTFILE(OUT)
//****************************************************************
//PRINT EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//IN DD DSN=your.CLUSTER,DISP=SHR
//SYSIN DD *
PRINT INFILE(IN) CHAR
//****************************************************************
//DELVSAM EXEC PGM=IEFBR14
//MYKSDS DD DSN=your.CLUSTER,DISP=(OLD,DELETE)
The JCL LIKE parameter is also very powerful for this kind of stuff...
Rob
Farley, Peter x23353
figures out the right LPAR to submit the "real" Endevor job? That way, the
LPAR decision is in an interactive environment where you have much more
control, and the only batch job that gets submitted is "the real thing". A
"pre-submit" process, in effect.
Peter
> -----Original Message-----
> From: Scott, John (Endevor) [mailto:John.P...@RBS.CO.UK]
> Sent: Tuesday, December 21, 2004 11:45 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: JCL return code in REXX
>
>
> The issue is that the user can submit the job on any lpar but
> DB2 dictates that the processing needs to run on a certain
> lpar depending on the db2 subsystem being processed. Endevor
> runs in one step and stores the return code (if its failed
> then the element cannot be moved to prod without reprocessing)
>
> That is the resaon we need to make the Endevor job wait or
> leave it to the users to remember to find out where their db2
> is that day and change the jobcard sysaff accordingly.
> > -----Original Message-----
> > From: Robert Zenuk [SMTP:Robz...@AOL.COM]
> > Sent: Tuesday, December 21, 2004 4:26 PM
> > To: TSO-...@VM.MARIST.EDU
> > Subject: Re: JCL return code in REXX
> >
> > *** WARNING : This message originates from the Internet ***
> >
> > In a message dated 12/21/2004 7:38:30 AM US Mountain Standard Time,
> > Rob
> >
> >
> >
> >
> >
> ----------------------------------------------------------------------
> > For TSO-REXX subscribe / signoff / archive access
> instructions, send
> > email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
>
>
> The Royal Bank of Scotland plc, Registered in Scotland No.
> 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
>
> The Royal Bank of Scotland plc is authorised and regulated by
> the Financial Services Authority and represents The Royal
> Bank of Scotland Marketing Group. The Bank sells life
> policies, collective investment schemes and pension products
> and advises only on the Marketing Group's range of these
> products and on a With-Profit Bond produced by Norwich Union
> Life (RBS) Limited.
>
> This e-mail message is confidential and for use by the
> addressee only. If the message is received by anyone other
> than the addressee, please return the message to the sender
> by replying to it and then delete the message from your
> computer. Internet e-mails are not necessarily secure. The
> Royal Bank of Scotland plc does not accept responsibility for
> changes made to this message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the
> transmission of viruses, it is the responsibility of the
> recipient to ensure that the onward transmission, opening or
> use of this message and any attachments will not adversely
> affect its systems or data. No responsibility is accepted by
> The Royal Bank of Scotland plc in this regard and the
> recipient should carry out such virus and other checks as it
> considers appropriate.
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access
> instructions, send email to LIST...@VM.MARIST.EDU with the
> message: INFO TSO-REXX
>
_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
Robert Zenuk
John.P...@RBS.CO.UK writes:
The issue is that the user can submit the job on any lpar but DB2 dictates
that the processing needs to run on a certain lpar depending on the db2
subsystem being processed.
Endevor runs in one step and stores the return code (if its failed then the
element cannot be moved to prod without reprocessing)
That is the resaon we need to make the Endevor job wait or leave it to the
users to remember to find out where their db2 is that day and change the
jobcard sysaff accordingly.
I understand the need to get to the correct target LPAR. Isn't there an
Endevor "reportonly" or "simulate" option to get the details. Once you had this
information, you could then generate the "real" Endevor step with the
correct LPAR and SSID. Then the job could be submitted on the correct target to
begin with...
Scott, John , Endevor
The Royal Bank of Scotland plc, Registered in Scotland No. 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
The Royal Bank of Scotland plc is authorised and regulated by the Financial Services Authority and represents The Royal Bank of Scotland Marketing Group. The Bank sells life policies, collective investment schemes and pension products and advises only on the Marketing Group's range of these products and on a With-Profit Bond produced by Norwich Union Life (RBS) Limited.
This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
----------------------------------------------------------------------
Robert Zenuk
ji...@QIS.NET writes:
Definitely less than 20 years. My MVS/XA JCL ref, dated Sept. 1989, has no
mention of an IF statement. And that probably explains why I've never tried
it
before.
I believe the JCL IF statement was introduced with MVS/ESA V4 (circa 1989).
I know I have been using it for about 15 years. Even though I was pretty
good with the RPN logic of the old COND parameter, I hated it every time I used
it because I knew I would get called if the job broke... Even the old "if
the condition is true, fall through" adage was confusing to most folks...
Rob
Bob Bridges
you're saying we should CONCEAL our weaknesses so as not to be downsized
or outsourced, I'm sure you'll find many to agree but I won't be one of
them.
What you probably meant, though, is that we should FIX the weaknesses, and
with that I heartily agree. That's why what I said was a confession, you
see. Now that I know about IF/THEN, I agree it's a better feature than
COND codes. Likewise other things I run across occasionally in the IBM
manuals.
The fact is, I got into contracting fearing I wouldn't have as much
opportunity to learn new things ("they won't hire contractors to learn
something, they'll hire contractors to hit the ground running"), but have
found with pleasure that contracting requires me to keep on adding new
skills all the time. So I haven't a guilty conscience in that regard, and
feel free to ring out a hearty "hear him!" concerning your speech, without
a twinge of conscience. I do have a question, though: How many do you
think really ARE just coasting along on what they learned 20 years ago?
Some, surely. But do you think there are many of them?
---
Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
rhb...@attglobal.net, 847 520-1684 xt 243
/* We should be careful to get out of an experience only the wisdom that
is in it -- and stop there -- lest we be like the cat that sits down on a
hot stove-lid. She will never sit down on a hot stove-lid again, and that
is well; but also she will never sit down on a cold one any more. -Mark
Twain */
Steve Comstock <SCom...@AOL.COM>
2004-12-21 10:25
To: TSO-...@VM.MARIST.EDU
cc:
Subject: Re: JCL return code in REXX
I was going to let this pass, since it is a common
--- Bob Bridges writes:
> Some of us old farts learned everything there was to know about JCL and
> then stopped reading the manual except for the occasional reminder. I
> didn't know IF/THEN had been invented for JCL until three or four years
> ago.
----------------------------------------------------------------------
Robert Zenuk
Peter_...@ADP.COM writes:
But you have to admit, the JCL IF/THEN facility is a very, very poor feature
compared to, say, REXX (to keep on-topic for this forum) looping and
procedural capabilities. Why bother using it when it adds (IMHO) very
little readbility to an already cryptic language? *IF* it had been allowed
to go where *ix shell languages have long-since been and permit testing and
looping based on JCL and system symbolic variable contents, *THEN* it would
be a significant enough facility to start using actively. In my judgement,
the condition-code-only capability is just not enough of an "advance" to
bother with.
The thing that JCL/JES brings to the table is guaranteed output. I too have
worked on multiple platforms and have done about 10 years of Unix work.
When I started scripting, I was amazed at how little most Unix Sysadmins knew
about systems management. Sure they were all "command line jockeys" and were
proud of the fact that they could "fix that problem in one command". True,
that command was actually 12 commands piped together. Unfortunately, once it
was executed all system knowledge of it was gone as soon at it scrolled of the
user's telnet session.
I also found that most (not all) Unix Sysadmins were poor programmers
(whether shell programming or other). The concept of redirecting the output of a
command or script to a file and archiving those files so they were retrievable
documents for future research was a foreign concept. Writing all commands
and responses to a log file was also foreign (no "real" Syslog equivalent).
When I introduced shell programming techniques that insured the output would
be available the next day or the next Monday, they thought I was a genius...
When I rewrote all the cron jobs (a Unix tool kind of like a job scheduler
on depressants) to use the same techniques, they were amazed they could now
figure out what happened during those "weird problems" at night. Obviously,
this was no magic or genius, it was simply exploiting good practices that I
learned from the mainframe.
TSO CLIST and REXX can be the same way. If the coder decides to simply
WRITE or SAY all the output to the screen, the data and results are lost forever.
The thing that JCL brings to the table is it enforces good practices and
insures you will have output for diagnostic purposes. When all the output
control is in the hands of the developer, you are at the mercy of the dedication
and foresightedness of the programmer and/or the standards in place at the
time.
I love REXX, but (like anything else) in the hands of someone with no
foresight, you can have a mess on your hands. I am thankful MVS/JES has the
extensive SYSLOG that shows every system command execution and the results. I am
also thankful that any job that was run is recorded and the details are in the
spool as well as SMF data to back it up. The JOBLOG, the JCL, the
Allocation/Deallocation messages and all the SYSOUT's make problem determination much
easier. If all this was done by interactive REXX, we might start missing
stuff we can see today. REXX is extremely powerful, but (to quote Spiderman's
Uncle) with great power comes great responsibility.
Rob
Ted MacNEIL
I do have a question, though: How many do you
think really ARE just coasting along on what they learned 20 years ago?
Too many! If my experience at IGS Canada, and many other companies is the norm.
Ted MacNEIL
users to remember to find out where their db2 is that day and change the
jobcard sysaff accordingly.
You can use the old 'mellon' mods or THRUPUT Manager to dynamically determine affinities.
But, why are you moving DB2 around? Isn't that error-prone?
Consider making them all a DB2-PLEX (sharing group), then it won't matter.
Bill Turner, WB4ALM
>[Sent to the TSO REXX list; cross posted to others.]
>
>Bob Bridges writes:
>
>
>
>>Some of us old farts learned everything there was to know about JCL and
>>then stopped reading the manual except for the occasional reminder. I
>>didn't know IF/THEN had been invented for JCL until three or four years
>>ago.
>>
>>
>>
>>
>
>I was going to let this pass, since it is a common
>enough kind of remark from us long-time folks in
>the biz, but then I started thinking about it a
>little, and I decided to challenge it.
>
>
Steve, In some cases the Management is the "old folks" and they refuse
to allow new features to be used, because,
(and this is a quote), "It will confuse everybody until they are
trained, and I'm not funding any more training this year."
The funny part, is that the individual who said that, just barely knew
how to code a "//SYSIN DD * " statement.
He claimed that IF/THEN/ELSE was harder to code then COND=, conveniently
forgetting that he never coded
it correctly himself.
Ah, but then stories like this creates filler material for trainers....
<grin>
/s/ Bill Turner
Thomas H Parker
responsible for implementing MVS 5.1 (whatever its real name was)
Tom Parker
8616 Freeport Parkway, Room 3B223
Irving, TX 75063
----------------------------------------------------------------------
Robert Zenuk
tedma...@BELL.BLACKBERRY.NET writes:
But, why are you moving DB2 around? Isn't that error-prone?
I didn't read that they are moving the DB2's around, but they have multiple
LPAR's some with Datasharing and some with standalone DB2 subsystems. I also
got the impression that they had multiple Sysplexes, so even if TPM is
available I think working outside a Sysplex/JES MAS might be a challenge.
I know in our environment we have a 2-way developer Sysplex with 24 DB2
Datasharing groups. These are all various test environments that the same change
could have to go through... Sometimes, you just have to know where you want
to go before you start...
Rob
David S Speake
"IBM Manuals? These people don't have time for intellectual
BS, they have work to do."
Didn't hear him say it myself but it fit. Not too bad a guy
other than that. And he was barely 30 at the time.
David Speake
------------------( Forwarded letter 1 follows )---------------------
Date: Tue, 21 Dec 2004 13:19:16 -0500
To: TSO-...@VM.MARIST.EDU.inet
From: WB4ALM.BillTurner[wb4alm]@ARRL.NET.inet
Sender: owner-t...@vm.marist.edu.inet
Reply-To: TSO.REXX.Discussion.List[TSO-REXX]@VM.MARIST.EDU.inet
Subject: Re: JCL return code in REXX
Steve Comstock wrote:
>[Sent to the TSO REXX list; cross posted to others.]
>
>Bob Bridges writes:
>
>
>
>>Some of us old farts learned everything there was to know about JCL and
>>then stopped reading the manual except for the occasional reminder. I
>>didn't know IF/THEN had been invented for JCL until three or four years
>>ago.
>>
>>
>>
>>
>
>I was going to let this pass, since it is a common
>enough kind of remark from us long-time folks in
>the biz, but then I started thinking about it a
>little, and I decided to challenge it.
>
>
Steve, In some cases the Management is the "old folks" and they refuse
to allow new features to be used, because,
(and this is a quote), "It will confuse everybody until they are
trained, and I'm not funding any more training this year."
The funny part, is that the individual who said that, just barely knew
how to code a "//SYSIN DD * " statement.
He claimed that IF/THEN/ELSE was harder to code then COND=, conveniently
forgetting that he never coded
it correctly himself.
Ah, but then stories like this creates filler material for trainers....
<grin>
/s/ Bill Turner
----------------------------------------------------------------------
Bill Turner, WB4ALM
>In a message dated 12/21/2004 10:58:56 AM US Mountain Standard Time,
>tedma...@BELL.BLACKBERRY.NET writes:
>
>But, why are you moving DB2 around? Isn't that error-prone?
>
>
>
>
Some Operations groups REQUIRE that they have the ability to move
subsystems around, such as DB2 to insure that Disaster Receovery
Procedures work... If you haven't moved DB2 from one LPAR to another
(maybe even on a different hardware box) how do you know you can, when
you have to?
Ted MacNEIL
Some Operations groups REQUIRE that they have the ability to move
subsystems around, such as DB2 to insure that Disaster Receovery
Procedures work... If you haven't moved DB2 from one LPAR to another
(maybe even on a different hardware box) how do you know you can, when
you have to?
We found that, as we set up GDPS, a rigid match of sub-system to image made things a lot easier.
Of course, we were fully IMS & DB2 datasharing under Parallel SYSPLEX.
So, binds could run anywhere there was an INIT.
As a matter of fact, due to GDPS & SA/390 restrictions, it was easier to leave things where they were.
Bob Bridges
COBOL program I was writing lo, these many years ago. They didn't want to
allow it in the walkthru "because an UNSTRING command is kind of exotic
and not everyone knows how it works". My argument, of course, was that if
there's a COBOL programmer who doesn't know one of the COBOL statements,
then it isn't too late for him to dig into a manual and learn it. I don't
remember who won that one.
---
Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
rhb...@attglobal.net, 847 520-1684 xt 243
/* If you can persuade your customer to tattoo your name on their chest,
they probably will not switch brands. -an Indiana University professor on
Harley-Davidson owners */
"Bill Turner, WB4ALM" <wb4...@ARRL.NET>
2004-12-21 12:19
To: TSO-...@VM.MARIST.EDU
cc:
Subject: Re: JCL return code in REXX
Steve, In some cases the Management is the "old folks" and they refuse
to allow new features to be used, because,
(and this is a quote), "It will confuse everybody until they are
trained, and I'm not funding any more training this year."
The funny part, is that the individual who said that, just barely knew
how to code a "//SYSIN DD * " statement.
He claimed that IF/THEN/ELSE was harder to code then COND=, conveniently
forgetting that he never coded
it correctly himself.
Ah, but then stories like this creates filler material for trainers....
<grin>
--- Steve Comstock wrote:
>I was going to let this pass, since it is a common
>enough kind of remark from us long-time folks in
>the biz, but then I started thinking about it a
>little, and I decided to challenge it.
>--- Bob Bridges writes:
>>Some of us old farts learned everything there was to know about JCL and
>>then stopped reading the manual except for the occasional reminder. I
>>didn't know IF/THEN had been invented for JCL until three or four years
>>ago.
----------------------------------------------------------------------
Bill Turner, WB4ALM
>LPAR's some with Datasharing and some with standalone DB2 subsystems. I also
>got the impression that they had multiple Sysplexes, so even if TPM is
>available I think working outside a Sysplex/JES MAS might be a challenge.
>
>
>
DB2 environments...
...for example, if you have a number (10 to 20) very large PROJECT
groups, each with their own distribution cycle to other corporate
sites, you might not be able to have everybody on the same release and
maintence level of db2... As an example if each of 20 groups makes 4
maintenance distibutions (new project releases) a year, then that
requires 80 weekends each year.
Hummmmm - thats about 30 more weekends each year then actually exists.
Furthermore, if one of those major applications is a tax accounting
system for customers, then you probably don't go making any changes
between January and uh, April 15th.
While it is real nice to maintain the exact DB2 subsystem on ALL lpars,
and all Systems in a complex, and across all compexes in an
international company - it just can't always happen that way.
So our shop developed a LARGE number of tools written in REXX that run
under TSO to assist the user in concatenating the correct datasets for
use when accessing a given DB2 environment. Some of those also assist
in getting logged onto the correct LPAR in the first place.
/s/ Bill Turner, wb4alm
Ted MacNEIL
In a very large shop, ir mighr bw necessary to have a number of diferent
DB2 environments...
...
I don't know how they did it, but they managed many DB2 environments (sysprog, dev, ist, uat, prod, and all set up as sharing) with two DB2 SYSPROGs
and 6 DBAs.
4000 MIPS, 26 TB (not all DB2, of course), and over 25 DB2 environments.
Nothing moved around, except during maintenance and D/R testing.
And, even then the rules were/are rigid.
GDPS enforces rigidity if you want it to work efficiently.
tedma...@bell.blackberry.net
Robert Zenuk
wb4...@ARRL.NET writes:
If you haven't moved DB2 from one LPAR to another
(maybe even on a different hardware box) how do you know you can, when
you have to?
We actually do this, but tend to return them to their normal home after
tests and/or problems. This is because there are so many issues that have to be
dealt under these test and/or disaster situations. Basically if a DB2 moves,
all the associated CICS regions must move too and therefore all the
associated MQ QMGR's must move. This tends to cause a capacity crunch, so developer
concerns are the least of our concerns in those scenarios and all that work
is halted until things can be returned to normal. CICS supporting the "Group
Attach" has eased some of these issues, but separate standalone DB2
subsystems and LPAR's not in the same Sysplex would not be able to take advantage of
that.
Rob
Robert Zenuk
tedma...@BELL.BLACKBERRY.NET writes:
As a matter of fact, due to GDPS & SA/390 restrictions, it was easier to
leave things where they were.
GDPS is not an instant takeover, so most shops will have an interim recovery
mechanism while the "backup" plex is being brought up. We actually found
GDPS (with PPRC) to be too slow and chose the XRC route instead.
SA/390 2.2 introduced "MOVE Groups" that makes moving things much easier.
You still have potential capacity issues though...
Robert Zenuk
robert...@DISCOVERFINANCIAL.COM writes:
because an UNSTRING command is kind of exotic
and not everyone knows how it works
STRING and UNSTRING used to be on the IBM restricted list for CICS. Many
shops forbid it's use to avoid programming style differences between batch and
online. I'm pretty sure this restriction was removed with VS COBOL II (years
ago).
Ted MacNEIL
GDPS is not an instant takeover, so most shops will have an interim recovery
mechanism while the "backup" plex is being brought up. We actually found
GDPS (with PPRC) to be too slow and chose the XRC route instead.
We were on very old DASD technology when we started working on GDPS.
10ms I/O response at the time.
We went to shark, lightning, and whatever was EMC's current tech, 3 years ago.
Our D/R site was 35km aways.
Going remote PPRC, with flashcopy, and all the bells & whistles, our response ended up at 5-7ms.
For us, it was a net gain.
Plus, multi-second network response masked every thing else.
Also, there is no interim solution.
GDPS is not yet mature.
There is a lot of automation to be written, but the whole shebang has to be initiated (at this stage) by a manual (operator) command.
Eventually, it will improve.
But, it beat our old method (FTAM).
Paul Gilmartin
> Date: Tue, 21 Dec 2004 11:47:34 -0500
>
> Definitely less than 20 years. My MVS/XA JCL ref, dated Sept. 1989, has no
> mention of an IF statement. And that probably explains why I've never tried it
> before.
>
Buy a new book.
-- gil
--
StorageTek
INFORMATION made POWERFUL
Mark Zelden
MVS JCL Reference:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2B632/
MVS JCL User's Guide
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2B520/
--
Mark Zelden
Sr. Software and Systems Architect
mailto: mark....@zurichna.com
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Paul Gilmartin
<gil...@UNIX.STO To: TSO-...@VM.MARIST.EDU
RTEK.COM> cc:
Sent by: TSO Subject: Re: JCL return code in REXX
REXX Discussion
List
<TSO-...@VM.MAR
IST.EDU>
12/21/2004 02:38
PM
Please respond
to TSO REXX
Discussion List
******************* PLEASE NOTE *******************
This E-Mail/telefax message and any documents accompanying this
transmission may contain privileged and/or confidential information and is
intended solely for the addressee(s) named above. If you are not the
intended addressee/recipient, you are hereby notified that any use of,
disclosure, copying, distribution, or reliance on the contents of this
E-Mail/telefax information is strictly prohibited and may result in legal
action against you. Please reply to the sender advising of the error in
transmission and immediately delete/destroy the message and any
accompanying documents. Thank you.
Steve Comstock
robert...@DISCOVERFINANCIAL.COM writes:
> Well, first of all, my remark wasn't an attitude but a confession. If
> you're saying we should CONCEAL our weaknesses so as not to be downsized
> or outsourced, I'm sure you'll find many to agree but I won't be one of
> them.
>
> What you probably meant, though, is that we should FIX the weaknesses, and
> with that I heartily agree. That's why what I said was a confession, you
> see. Now that I know about IF/THEN, I agree it's a better feature than
> COND codes. Likewise other things I run across occasionally in the IBM
> manuals.
>
Fix yes, conceal no. Right. That was my intent.
> The fact is, I got into contracting fearing I wouldn't have as much
> opportunity to learn new things ("they won't hire contractors to learn
> something, they'll hire contractors to hit the ground running"), but have
> found with pleasure that contracting requires me to keep on adding new
> skills all the time. So I haven't a guilty conscience in that regard, and
> feel free to ring out a hearty "hear him!" concerning your speech, without
> a twinge of conscience. I do have a question, though: How many do you
> think really ARE just coasting along on what they learned 20 years ago?
> Some, surely. But do you think there are many of them?
>
>
Yes. But, of course, you won't meet them on usenet's and
listserv's. <g>
I appreciate your perspective, and I'm glad you didn't
take my rant in other than the spirit in which it was,
uhhh, ranted.
Kind regards,
-Steve Comstock
Hartmut.Beckmann
We often had the same problem: Which is the right SYSAFF statement normally
in one parallel sysplex env.?
In our environment we have 4 boxes, 30 LPARs, some parallel sysplexes, stand
alone LPARs.
In former days we used and we still use the CLASS parm starting and stopping
initiators for CLASSES on several machines.
But try the SCHENV parm (schedule environment) in the job card. Define
ressources, combine them to SCHENVs and decide by stopping and starting
ressources on which machines special SCHENVs are "active", exactly all
ressources for the SCHENV are "ON". Use the same CLASSes on all machines and
the WLM will route the job.
You have to consider
- to break jobs into several jobs perhaps with onyl 1 step because they are
dependent on different ressources
Examples:
The DB2 part of a job runs on a well tunes production machine.
Then ENDEVOR or PKZIP or ... step runs on a small box where ENDEVOR or
PKZIP or ... is lizensed.)
A FTP step runs on the machine where FTPs are allowed.
- You have to organize which dataset should have the same name with
different content like TCPIP datasets,
provide additional PROC parms like DB2 subsystem name to get the correct
STEPLIB concat and so on.
- In general your automation should start / stop the ressources. After an
IPL the ressource for the DB2 prod system is set to "ON" from initially
"RESET" by automation if the DB2 system is up and running.
A few days ago we migrated on production LPAR to z/OS 1.4 and had some
problems we hadn't seen before in the test environment or other production
machines. So we toggled the relevant ressources to "OFF" on this machines
and all jobs ran on other LPARs without any problems. We fixed the situation
an toggled "ON".
SCHENV is great!
And we are using JCL "IF-THEN-ELSE-ENDIF" coding like this
//SET STEP=TSOBAT.LASTSTEP
// IF ( &STEP..RUN EQ TRUE AND &STEP..RC LE 4 ) THEN
// ....
// ENDIF
Hartmut
-----Original Message-----
From: owner-t...@VM.MARIST.EDU [mailto:owner-t...@VM.MARIST.EDU] On
Behalf Of Bill Turner, WB4ALM
Sent: Tuesday, December 21, 2004 8:07 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: JCL return code in REXX
Robert Zenuk
Hartmut....@WEB.DE writes:
Perhaps SCHENV is not right here, but we solved many problems in this way.
Sounds interesting, we will have to look into this.
Thanks,
Rob
Jeremy C B Nicoll
Paul Gilmartin <gil...@UNIX.STORTEK.COM> wrote:
> In a recent note, Jeremy C B Nicoll said:
> > Date: Tue, 21 Dec 2004 13:31:39 +0000
> > >
> > > I have submitted JCL from REXX. After that I need to know the Job got
> > > completed successfully and then I need to process some other part in
> > > my REXX code.
> >
> > It's a bad idea; the submitted job might never run (eg if the jes
> > initiators are drained), and meantime your tso session will be
> > wasting time waiting for something that won't happen.
> >
> You're jumping to a conclusion: the original poster never said a TSO
> session was involved.
Yes, true.
> (I know; this is the TSO-REXX list, but is there a separate forum
> which is preferred for "z/OS Rexx outside TSO"?)
Well ibm-main, and comp.lang.rexx both do, to some extent.
> My question, though, is whether submitting a batch job is necessary:
I wondered that too...
--
Jeremy C B Nicoll - my opinions are my own.
Jim Harrison
manual, along with about 10 others, is all that is left of my once massive
collection of hardcopy documentation. They are some of the books I managed to
box up and take with me when I landed at this shop many years ago. I guess it
really is time to let go of them and reclaim some space. A brief sample:
MVS/XA JCL
MVS/XA Messages & codes (vol 1 & 2)
FileAid 5.2
COBOL II
CICS MVS 2.1 Application Pgmr Reference
OS/VS2/MVS Supervisor Services & Macro Instructions
Syncsort 3.2
Dialog Manager 3.3
I have pretty much everything I need on CD now-a-days which is quite handy when
I'm away from my desk. It's just nice now and then to pull out a real manual
and start turning pages.
Quoting Paul Gilmartin <gil...@UNIX.STORTEK.COM>:
>
> Buy a new book.
>
> -- gil
----------------------------------------------------------------------
pjfarley3
This is in reply to your note on defining VSAM datasets with JCL only
(I'm responding from the web, so I don't know how much of your original
message will get quoted).
I quote below from the z/OS JCL Reference manual, in the section on the
DATACLAS parameter. Note the last item in the list:
"A data class defines the following data set allocation attributes:
Data set organization
Record organization (RECORG) or
Record format (RECFM)
Record length (LRECL)
Key length (KEYLEN)
Key offset (KEYOFF)
Type, PDS or PDSE (DSNTYPE)
Space allocation (AVGREC and SPACE)
Retention period (RETPD) or expiration date (EXPDT)
Volume-count (VOLUME)
Compaction
Media interchange type
Space constraint relief
Block size limit
For VSAM data sets (IMBED or REPLICATE, CISIZE, FREESPACE,
SHAREOPTIONS, REUSE, INITIAL LOAD, SPANNED/NONSPANNED, BWO (backup
while open), and LOGGING OPTIONS)"
NONE of those VSAM parameters can be coded directly in JCL, your
Storage Admin must have coded DATACLAS's for you with values you might
want to use.
Yes, you *can* define a VSAM dataset in JCL, but you cannot control
it's parameters completely. That is a failure from a programmer's
point of view, though it is probably a plus to Storage Admins.
Peter