How to get a member name from JCL?
Bob Bridges
pile; feel free to check my thinking as I go, for I may have missed
something:
I'm writing a REXX to run in batch, and for no very compelling reason I've
elected not to invoke ISPF. At some point in the logic I need to assemble
some JCL and submit it. FTetc would make that easy, but as I said I'm not
using ISPSTART; that leaves me no way to submit a job but the TSO SUBMIT
command (right?). So broadly speaking my logic does this:
'EXECIO * DISKR ARCJCL (STEM ARC. FINIS' /* read the master JCL
*/
do ij=1 to arc.0; /* tailor arc.ij as needed */; end
'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS' /* wrt the
modified JCL */
'SUB /* ...the modified JCL */'
But the SUB command won't take a DD name, only a DSN (right?). So somehow
I must get MVS to tell me what DSN the user supplied. LISTDSI will do
that, so I can do a listdsi and SUB the sysdsname.
But what if the user supplies a PDS member for the purpose?
//ARCSUB DD DSN=HIS.ISPF.DATASET(MEMBER),DISP=SHR
LISTDSI gets me the DSN but not the member, so although I can EXECIO the
modified JCL to the DD name, I can't submit it afterward. This is for use
in a small department so it isn't the end of the world if I just tell the
users they're not allowed to supply a member name -- or rather if they do,
my logic will ignore their member and impose a hard-coded one in the same
library -- but I'd like it to be smarter than that, and it seems to me
there must be some way to do so simple a thing.
Some ideas:
1) Is there an MVS data area I can check?
2) I know there's an alternate "SUB *" form of the command, but I haven't
been able to make it work in REXX (batch OR online). Maybe I'm just not
holding my mouth right?
3) If the user doesn't supply that DD at all, my code allocates and uses a
temporary dataset, getting the system-assigned DSN from LISTALC STATUS
SYSNAMES. It occurs to me belatedly that LISTALC might tell me the member
name, too; it's worth a try at least.
4) Is there another way to submit a job beside TSO SUBMIT? given that I'm
not invoking ISPF, I mean.
5) Here's a weird idea: I'm running this in IKJEFT01 and I'm not using
//SYSTSIN for anything. What if we use that DD name instead of //ARCSUB,
and after writing the modified JCL to //SYSTSIN I try SUB *? It's screwy,
but it might work.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Don't ask yourself what the world needs. Ask yourself what makes you
come alive, and go do that, because what the world needs is people who have
come alive. -Gil Bailie, quoted in "Wild at Heart" by John Eldredge */
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Lizette Koehler
/* My Temp Data set to submit the JCL from */
ADDRESS TSO "ALLOC DD(ARCSUB) DA(AARCSUB.DSN) NEW CATALOG SPACE(1 1) RECFM(F
B) LRECL(80) BLKSIZE(0)"
'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS'
'SUB ARCSUB.DSN'
Other option is to call IEBGENER from the REXX and then submit via the
INTRDR on the SYSUT2 DD statement: //SYSUT2 DD SYSOUT=(A,INTRDR)
Lizette
--
--
--I'm writing a REXX to run in batch, and for no very compelling reason
I've
--elected not to invoke ISPF. At some point in the logic I need to
assemble
--some JCL and submit it. FTetc would make that easy, but as I said I'm
not
--using ISPSTART; that leaves me no way to submit a job but the TSO SUBMIT
--command (right?). So broadly speaking my logic does this:
--
--
--
-- 'EXECIO * DISKR ARCJCL (STEM ARC. FINIS' /* read the master
JCL
--*/
--
-- do ij=1 to arc.0; /* tailor arc.ij as needed */; end
--
-- 'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS' /* wrt the
--modified JCL */
--
-- 'SUB /* ...the modified JCL */'
--
--
Horacio Villa
stack (queue the sentences), put a last queue '' (an empty one) and
address tso 'submit *'
Cheers,
Horacio Villa
Lizette Koehler <star...@MINDSPRING.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
28/04/2007 11:28
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] How to get a member name from JCL?
Bob Bridges
can't give cut-and-paste the code exactly, but you described it exactly:
1) Queue all my JCL statements in order.
2) One last queue command to put a null string on the end of the stack.
3) 'SUB *'
I get an OC4 abend every time, though I've tried a few desperate things
like making sure each line is exactly 80 bytes long etc. I've also tested
the JCL to be sure it works when I just submit it from an Edit session.
I thought it should be that simple. Must be something else I'm doing
wrong, eh?
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Don't ask yourself what the world needs. Ask yourself what makes you
come alive, and go do that, because what the world needs is people who have
come alive. -Gil Bailie, quoted in "Wild at Heart" by John Eldredge */
-----Original Message-----
From: Horacio Villa
Sent: Saturday, April 28, 2007 10:35
If you don't need to allocate a dataset, you can put all the JCL in the
stack (queue the sentences), put a last queue '' (an empty one) and
address tso 'submit *'
----------------------------------------------------------------------
Bob Bridges
option I wanted to leave open to the users. But the internal reader is
more the kind of thing I wanted.
...Or is it? Ah, I see the problem; I can use it to submit the JCL, but
not to save the JCL in a dataset (if the user so indicates) so he can see
afterward what JCL I constructed. Not your fault -- I did ask what
alternatives there might be to the SUBMIT command -- but one of my
requirements is that the user be able to specify a DD for it if desired.
(Not that it's a requirement of the project -- only of this question. If I
can't find a way to do it in the JCL, I already know of a way to do it
without bothering the user for a DD. I just think there must be a way to
get a member name from a DDN, somehow.)
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Don't ask yourself what the world needs. Ask yourself what makes you
come alive, and go do that, because what the world needs is people who have
come alive. -Gil Bailie, quoted in "Wild at Heart" by John Eldredge */
-----Original Message-----
From: Lizette Koehler
Sent: Saturday, April 28, 2007 10:29
How about preallocating the ARCSUB data set
/* My Temp Data set to submit the JCL from */
ADDRESS TSO "ALLOC DD(ARCSUB) DA(AARCSUB.DSN) NEW CATALOG SPACE(1 1)
RECFM(F B) LRECL(80) BLKSIZE(0)"
'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS'
'SUB ARCSUB.DSN'
Other option is to call IEBGENER from the REXX and then submit via the
INTRDR on the SYSUT2 DD statement: //SYSUT2 DD SYSOUT=(A,INTRDR)
----------------------------------------------------------------------
Lizette Koehler
review the JCL prior to submit, include the EDIT 'dns' command and then the
resulting JCL can be browsed. But since this is batch, you may just wish to
LIST the output of the modified JCL from the REXX for later review. Or
produce a message that states where the output of the modified JCL can be
found. But wait - you said batch process. So to review the JCL prior to
submit will not work. But a native REXX without ISPF can use TSO EDIT under
TSO to review the JCL prior to submit.
I am not certain how much control you wish your user to have. Sometimes too
much flexibility is as bad as not enough.
The specs should be sufficient for the user and you to maintain the
function. You could state that the member name must begin with certain
prefix (ARC) and that you will generate a member name based on time or date
or something agreeable to the process. Then you will always know the member
name or be able to find it. To use the "I am thinking of a member name and
you need to guess" does not make the process easier, only harder in my
opinion. And remember - who will maintain this function after you are long
gone and buried under a stack of TSO and REXX manuals?
Lizette
-------
--
--...Or is it? Ah, I see the problem; I can use it to submit the JCL, but
--not to save the JCL in a dataset (if the user so indicates) so he can see
--afterward what JCL I constructed. Not your fault -- I did ask what
--alternatives there might be to the SUBMIT command -- but one of my
--requirements is that the user be able to specify a DD for it if desired.
--
--(Not that it's a requirement of the project -- only of this question. If
I
--can't find a way to do it in the JCL, I already know of a way to do it
--without bothering the user for a DD. I just think there must be a way to
--get a member name from a DDN, somehow.)
--
-----
Robert Zenuk
LISTALC STATUS will display the member name for outtrap scraping, so you can
get the member name if that's truly what you need. By the way, it also
nicely displays USS paths if you ever need that.
As far as keeping and submitting the JCL, you have several options (some
have been mentioned already):
Use LISTALC STATUS, outtrap the output, scrape the target DD and use the
DSN(MEM) in a SUBMIT. I like this option because you can outtrap the submit and
record the jobname and jobnmuber in the batch job's SYSOUT. This gives an
audit trail of what was submitted. I also like to issue an undirected TSO
SEND with the job details so there is an audit trail in the SYSLOG as well.
Following along with that approach, I would also SAY the generated JCL into the
SYSTSPRT, so the job's SYSOUT has the audit trail of the JCL, submit time,
jobname and jobnumber (and any other pertinent details from this process).
This makes it easy and convenient for the submitter to find all the details in
one place. Once you have the member name, you can have a "SAVE" DD in the JCL
(no member name) and simply ALLOC REUSE with a new DSN(MEM) and EXECIO your
generated JCL there as well.
Another option that does not require the member name is to dynamically ALLOC
a new "temporary" dataset (short living userid().execname.Dmmddyy.Thhmmss
dataset) and use a static (or generated) member name. Obviously, it could also
be a simple sequential dataset. You then EXECIO the generated JCL to your
new dynamically allocated DD. This also allows you to use TSO SUBMIT
effectively (and outtrap for jobname and jobnmuber). These "temporary" datasets
could also be left around for your audit trail (I still like the idea of putting
all the details in SYSTSPRT, but output does get purged from the spool).
Using a common DSN prefix and imbedded date and timestamps allows an effective
use of 3.4 to review prior runs, see dates and times and allows HSM to
cleanup them up independently.
I also occasionally like using EXECIO to an INTRDR DD. This also
accomplishes a submit. Unfortunately, there is no jobname and jobnumber provided back.
This technique is faster than TSO SUBMIT and is appropriate when you do not
care about capturing the jobname and jobnumber. This does not require an
intervening IEBGENER like previously suggested. Here is a bare bones example:
jcl.1 = '//'userid()'A JOB (0000),TESTJOB,MSGCLASS=T,NOTIFY='userid()
jcl.2 = '//STEP1 EXEC PGM=IEFBR14'
"ALLOC F(SUBMIT) SYSOUT WRITER(INTRDR)"
if RC<> 0 then say 'ALLOC error on INTRDR'
"EXECIO * DISKW SUBMIT (STEM JCL. FINIS"
if RC<> 0 then say 'EXECIO error on INTRDR'
Hope This Helps,
Rob
************************************** See what's free at http://www.aol.com.
Horst Gfrerer
> If you don't need to allocate a dataset, you can put all the JCL in the
> stack (queue the sentences), put a last queue '' (an empty one) and
> address tso 'submit *'
>
> Cheers,
>
> Horacio Villa
>
Horacio Villa
Are you getting the 0C4 abend in the REXX?
Cheers,
Horacio Villa
Bob Bridges <rhb...@ATTGLOBAL.NET>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
28/04/2007 11:42
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] How to get a member name from JCL?
Dave Salt
Here's a quick-and-dirty REXX I just threw together that returns the name of
a data set and member (if any) that's allocated to a DDNAME:
/* REXX to determine data set and member allocated to a ddname. */
parse upper arg ddname
if ddname = "" then do
ddname = "SYSEXEC"
say "No ddname entered, using "ddname" as a default"
end
rc=OUTTRAP("LINE.")
"LISTALC STATUS"
rc=OUTTRAP("OFF")
do i = 1 to line.0
if left(line.i,2) = " " then do
if left(line.i,3) = " " then iterate
parse var line.i dd disp
if dd = ddname then do
i = i - 1
say "The first data set (and member, if any)"
say "allocated to ddname "ddname" is: "line.i
leave
end
end
end
EXIT
Hope that helps,
Dave Salt
See the new SimpList(tm) rollover image at:
http://www.mackinney.com/products/SIM/simplist.htm
_________________________________________________________________
Check Out Our List Of Trendy Restaurants. You'll Eat It Up!
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!378
Ron MacRae
write to an internal reader using this DD
ADDRESS "TSO" "ALLOCATE FI(SYSUT1) SYSOUT(A) SPIN(UNALLOC)",
"REUSE RECFM(F B) LRECL(80) BLKSIZE(3120)",
"WRITER(INTRDR)"
IF RC <> 0 THEN EXIT RC
EXECIO OUT.0 "DISKW SYSUT1 (STEM OUT. FINIS"
IF RC = 0 THEN SAY "JOB SUBMITTED."
ELSE SAY "SUBMITTED RC="RC
ADDRESS "TSO" "FREE FI(SYSUT1)"
Ron MacRae.
Paul Gilmartin
> Date: Sat, 28 Apr 2007 10:10:34 -0400
>
> do ij=1 to arc.0; /* tailor arc.ij as needed */; end
>
> 'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS' /* wrt the modified JCL */
>
> 'SUB /* ...the modified JCL */'
>
> 4) Is there another way to submit a job beside TSO SUBMIT? given that I'm
> not invoking ISPF, I mean.
>
My favorite (untested in this instance; hammer and file to fit):
RC = BXPWDYN( 'alloc rtddn(MYREADER) sysout(B) writer(INTRDR) msg(WTP)' )
address 'MVS' 'EXECIO' arc.0 'DISKW' MYREADER '(STEM ARC. FINIS'
RC = BXPWDYN( 'free dd('MYREADER') msg(WTP)' )
Doesn't need ISPF; doesn't need TSO; runs alike under:
TSO
IKJEFT01
IRXJCL
UNIX shell
etc.
-- gil
--
StorageTek
INFORMATION made POWERFUL
Paul Gilmartin
> Date: Sat, 28 Apr 2007 10:45:39 -0400
>
> ...Or is it? Ah, I see the problem; I can use it to submit the JCL, but
> not to save the JCL in a dataset (if the user so indicates) so he can see
> afterward what JCL I constructed. Not your fault -- I did ask what
> alternatives there might be to the SUBMIT command -- but one of my
> requirements is that the user be able to specify a DD for it if desired.
>
You can do both for the attractive price of a second EXECIO:
'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS'
'EXECIO' arc.0 'DISKW INTRDR (STEM ARC. FINIS'
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Dunkel, Martin
Why do you need to issue the SUB command from within the Rexx? Why
can't you just EXECIO it out to a SYSOUT DD in you JCL that goes to the
INTRDR?
In your JCL code:
//JCLOUT DD SYSOUT=(A,INTRDR)
In your Rexx code:
"EXECIO * DISKW JCLOUT (STEM JCLO. FINIS)"
Works for me every time!
Thanks! MPD
Martin Dunkel
National City Corporation
Turnover Support / ChangeMan ZMF
(w) 216-257-5354
(p) 80053...@archwireless.net
//ARCSUB DD DSN=HIS.ISPF.DATASET(MEMBER),DISP=SHR
Some ideas:
-------------------------------------------------------------------------------------------
***National City made the following annotations
-------------------------------------------------------------------------------------------
This communication is a confidential and proprietary business communication.
It is intended solely for the use of the designated recipient(s). If this
communication is received in error, please contact the sender and delete
this communication.
===========================================================================================
Ryerse, Robin
Since you are executing in batch, why do you need TSO? Try to fulfill
the requirements using IRXJCL.
You will need 3 functional pieces:
- a routine to chase down the TIOT and JFCB control blocks. I have
posted DSN4DD several times.
- a mechanism to access the INTRDR writer task. Pre-allocate it in the
batch JCL
- EXECIO is availble outside of the TSO Rexx environment
Robin Ryerse
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Bob Bridges
Sent: April 28, 2007 10:11 AM
To: TSO-...@VM.MARIST.EDU
McKown, John
> From: TSO REXX Discussion List
> [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Ryerse, Robin
> Sent: Monday, April 30, 2007 12:28 PM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] How to get a member name from JCL?
>
>
> I've somewhat followed this thread and lay down the next challenge.
> Since you are executing in batch, why do you need TSO? Try to fulfill
> the requirements using IRXJCL.
<snip>
>
> Robin Ryerse
>
Robin,
I've said that before, too. But most people seem to feel that IRXJCL is
simply not worth the effort to program to. I guess they feel that they
might as well run under batch TSO "just in case" they decide to use some
TSO facility. Also (and I have this problem), it is sometimes difficult
to remember, off hand, if a function requires TSO or not. I'm getting
even worse. I'm trying to mix REXX, TSO, and UNIX stuff in the same
exec!
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.
Bob Bridges
simple and completely obviates the need to figure out a DSN -- very good!
Thanks, Paul; I'll keep this one in mind.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Don't ask yourself what the world needs. Ask yourself what makes you
come alive, and go do that, because what the world needs is people who have
come alive. -Gil Bailie, quoted in "Wild at Heart" by John Eldredge */
-----Original Message-----
From: Paul Gilmartin
Sent: Saturday, April 28, 2007 16:49
You can do both for the attractive price of a second EXECIO:
'EXECIO' arc.0 'DISKW ARCSUB (STEM ARC. FINIS'
'EXECIO' arc.0 'DISKW INTRDR (STEM ARC. FINIS'
--- In a recent note, Bob Bridges said:
> ...Or is it? Ah, I see the problem; I can use it to submit the JCL, but
> not to save the JCL in a dataset (if the user so indicates) so he can see
> afterward what JCL I constructed. Not your fault -- I did ask what
> alternatives there might be to the SUBMIT command -- but one of my
> requirements is that the user be able to specify a DD for it if desired.
----------------------------------------------------------------------
Bob Bridges
extra "queue" command in at the end then after the SUBMIT command it asks
me at the terminal for more input; when I hit <Enter> it displays the 0C4
error, hangs up a few seconds and then displays a dump along with it. I
must be holding my mouth wrong, but so far I haven't figured out how.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Vegetables aren't food. Vegetables are what food eats. -from Shoe,
1999-10-08 */
-----Original Message-----
From: Horacio Villa
Sent: Saturday, April 28, 2007 13:24
I've done it many times. It must be something else you're doing wrong.
Are you getting the 0C4 abend in the REXX?
--- Bob Bridges <rhb...@ATTGLOBAL.NET>, 28/04/2007 11:42
Yeah, I tried that. For some reason it doesn't work. I'm not at work so
I can't give cut-and-paste the code exactly, but you described it exactly:
1) Queue all my JCL statements in order.
2) One last queue command to put a null string on the end of the stack.
3) 'SUB *'
I get an OC4 abend every time, though I've tried a few desperate things
like making sure each line is exactly 80 bytes long etc. I've also tested
the JCL to be sure it works when I just submit it from an Edit session.
I thought it should be that simple. Must be something else I'm doing
wrong, eh?
-----Original Message-----
Bob Bridges
suggested here: If the DD is missing, I allocate a temporary DS, get the
DSN from LISTALC and use that in the SUB command. Still, once I had the
idea of letting the user specify the DD in case she wants to see the JCL
that was submitted, I'd have liked to be able to do it for her without
worrying that a PDS(MEMBER) wouldn't work properly.
Turns out LISTALC works for that purpose, too. And for that plus yet
another reason, I'm beginning to be discontented with LISTDSI, until today
a mainstay of my programming tools. More later.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* God blesses or afflicts us with people according to our needs. -Bob
Mumford */
-----Original Message-----
From: Dunkel, Martin
Sent: Monday, April 30, 2007 10:00
Here's my two cents, going back to the original question: Why do you need
to issue the SUB command from within the Rexx? Why can't you just EXECIO
it out to a SYSOUT DD in you JCL that goes to the INTRDR?
In your JCL code:
//JCLOUT DD SYSOUT=(A,INTRDR)
In your Rexx code:
"EXECIO * DISKW JCLOUT (STEM JCLO. FINIS)"
Works for me every time!
//ARCSUB DD DSN=HIS.ISPF.DATASET(MEMBER),DISP=SHR
Some ideas:
----------------------------------------------------------------------
David S Speake
David
------------------( Forwarded letter 1 follows )---------------------
Date: Tue, 1 May 2007 19:58:20 -0400
Reply-To: TSO.REXX.Discussion.List[TSO-REXX]@VM.MARIST.EDU.INET
Sender: TSO.REXX.Discussion.List[TSO-REXX]@VM.MARIST.EDU.INET
From: Bob.Bridges[rhbridg]@ATTGLOBAL.NET.INET
Subject: Re: SUB * (was "How to get a member name from JCL?"
To: TSO-...@VM.MARIST.EDU.INET
X-HDT-HopCount: 1
Yeah, that's what I'm saying. When I test it on-line, if I don't put the
extra "queue" command in at the end then after the SUBMIT command it asks
me at the terminal for more input; when I hit <Enter> it displays the 0C4
error, hangs up a few seconds and then displays a dump along with it. I
must be holding my mouth wrong, but so far I haven't figured out how.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Vegetables aren't food. Vegetables are what food eats. -from Shoe,
1999-10-08 */
-----Original Message-----
From: Horacio Villa
Sent: Saturday, April 28, 2007 13:24
I've done it many times. It must be something else you're doing wrong.
Are you getting the 0C4 abend in the REXX?
--- Bob Bridges <rhb...@ATTGLOBAL.NET>, 28/04/2007 11:42
Yeah, I tried that. For some reason it doesn't work. I'm not at work so
I can't give cut-and-paste the code exactly, but you described it exactly:
1) Queue all my JCL statements in order.
2) One last queue command to put a null string on the end of the stack.
3) 'SUB *'
I get an OC4 abend every time, though I've tried a few desperate things
like making sure each line is exactly 80 bytes long etc. I've also tested
the JCL to be sure it works when I just submit it from an Edit session.
I thought it should be that simple. Must be something else I'm doing
wrong, eh?
-----Original Message-----
From: Horacio Villa
Sent: Saturday, April 28, 2007 10:35
If you don't need to allocate a dataset, you can put all the JCL in the
stack (queue the sentences), put a last queue '' (an empty one) and
address tso 'submit *'
----------------------------------------------------------------------
Bob Bridges
probably have use for in the future. For this app I've discovered, as
Robert says below and others also mentioned, that LISTALC gives me the
member name. So in my logic I use 'LISTDSI <ddname> FILE' to find out
whether the DD exists; if it doesn't, I allocate a DS with no DSN, and then
use LISTALC to find out what DSN is attached to it, either the one the user
specified in the JCL or the sysname assigned during my allocation.
Now the next shortcoming of LISTDSI: I have a handy little Boolean
function named DSDD which I've been calling for years to determine the
status of a DSN or DDN. It uses LISTDSI (with or without the 'FILE'
argument) to tell me whether a DS exists, or whether a certain DD name is
currently allocated. I've been using it liberally in the application I
described earlier.
But today I discovered something I never suspected before: In batch,
'LISTDSI ddname FILE' returns rc=16, sysreason=0002 if the DD isn't
specified in the JCL, and it returns the EXACT SAME RESULTS if the DD
specifies a GDG with +1 generation!
How can this be?! Is there another way to check whether a DD is supplied
in a batch REXX that won't mislead me this way?
In the event I changed my whole approach: At the beginning of the run I do
a LISTALC, make a table of all DDs available and refer to the table
(instead of to DSDD/LISTDSI) whenever my logic needs to know whether a DD
is offered. But sheesh! I'm suddenly growing disenchanted with LISTDSI.
I'd thought it a reliable tool. Am I missing something obvious? Did
everyone else already know about this limitation?
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* ...if you move, you'll end up like us: surrounded by hundreds of
cardboard boxes packed by strangers....Virtually every box will be labeled
with some mutant spelling of the word "miscellaneous." You will not be
able to find ANYTHING. For example, I'm pretty sure that, before we moved,
we had a seven-month-old daughter. -Dave Barry, Miami Herald 2000-11-05 */
-----Original Message-----
From: Robert Zenuk
Sent: Saturday, April 28, 2007 12:51
A couple things...
LISTALC STATUS will display the member name for outtrap scraping, so you
can get the member name if that's truly what you need. By the way, it also
nicely displays USS paths if you ever need that.
As far as keeping and submitting the JCL, you have several options (some
have been mentioned already):
Use LISTALC STATUS, outtrap the output, scrape the target DD and use the
DSN(MEM) in a SUBMIT. I like this option because you can outtrap the
submit and record the jobname and jobnmuber in the batch job's SYSOUT.
This gives an audit trail of what was submitted. I also like to issue an
undirected TSO SEND with the job details so there is an audit trail in the
SYSLOG as well.
----------------------------------------------------------------------
Robert Zenuk
EXEC, JCL and output.
EXEC:
/* rexx LISTDSIT */
call ddstat 'SYSOUT'
call ddstat 'SYSTSPRT'
call ddstat 'SYSEXEC'
call ddstat 'NEWGDG'
say copies('-',78)
exit 0
ddstat: arg ddname
drop sysdsname
LRC = listdsi(ddname 'FILE')
say copies('-',78)
if LRC <> 0 then
do
say 'DD:' ddname
say sysdsname
say 'RC:' LRC 'Reason:' sysreason
say sysmsglvl1
say sysmsglvl2
end
else
do
say 'DD:' ddname 'is OK RC='LRC
say sysdsname
say 'RC:' LRC 'Reason:' sysreason
say sysmsglvl1
say sysmsglvl2
end
return
JCL:
//jobcard...
//TESTER EXEC PGM=IKJEFT01,PARM=LISTDSIT
//SYSEXEC DD DSN=MY.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//NEWGDG DD DSN=MY.TEST.GDG(+1),DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(TRK,1)
Output:
-----------------------------------------------------------------
DD: SYSOUT
RC: 16 Reason: 0002
IKJ58400I LISTDSI FAILED. SEE REASON CODE IN VARIABLE SYSREASON.
IKJ56247I FILE INFO-RETRIEVAL NOT PERFORMED, IS NOT ALLOCATED
-----------------------------------------------------------------
DD: SYSTSPRT
RC: 16 Reason: 0003
IKJ58400I LISTDSI FAILED. SEE REASON CODE IN VARIABLE SYSREASON.
IKJ58403I THE DATA SET IS A TYPE THAT CAN NOT BE PROCESSED.
-----------------------------------------------------------------
DD: SYSEXEC is OK RC=0
MY.EXEC
RC: 0 Reason: 0000
-----------------------------------------------------------------
DD: NEWGDG is OK RC=0
MY.TEST.GDG.G0005V00
RC: 0 Reason: 0000
-----------------------------------------------------------------
Rob
In a message dated 5/1/2007 8:39:49 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
A couple things...
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
Hamilton, Robert L
step.
???
bobh
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Paul Gilmartin
> Date: Wed, 2 May 2007 10:19:54 -0500
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
> Of Bob Bridges
> Sent: Tuesday, May 01, 2007 10:39 PM
>
> member name. So in my logic I use 'LISTDSI <ddname> FILE' to find out
> whether the DD exists; if it doesn't, I allocate a DS with no DSN, and then
> use LISTALC to find out what DSN is attached to it, either the one the user
> specified in the JCL or the sysname assigned during my allocation.
>
I use BPXWDYN with the RTDSN keyword and thereby bypass the LISTALC and
a possible assignment statement.
> is offered. But sheesh! I'm suddenly growing disenchanted with LISTDSI.
> I'd thought it a reliable tool. Am I missing something obvious? Did
> everyone else already know about this limitation?
>
Suddenly? I grew disenchanted with LISTDSI( ddname FILE ) years ago
when I discovered several of the following (I may misremember some):
o It reports attributes from the DSCB label, not overriding attributes
that may have been supplied on the DD statement.
o It reports little or nothing if ddname is allocated to SYSOUT or to
an HFS file, even though attributes are specified on the DD statement.
o All in all, it appears that LISTDSI( ddname FILE ) operates by looking
up the associated dsname in the TIOT and proceeding as if the programmer
used LISTDSI( dsname ) instead of giving information about the FILE.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
J.D. Hill
J.D. Hill
At 11:19 AM 5/2/2007, Hamilton, Robert L wrote:
>+1 won't be in the catalog until it's 'rolled' in at the end of the
>step.
>
>???
>
>bobh
>
>-----Original Message-----
>From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
>Of Bob Bridges
>Sent: Tuesday, May 01, 2007 10:39 PM
>To: TSO-...@VM.MARIST.EDU
>Subject: Further trials of LISTDSI -- doesn't work for GDG(+1)!
>
Horacio Villa
Cheers,
Horacio Villa
David S Speake <DAVID....@BCBSSC.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
01/05/2007 23:02
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] SUB * (was "How to get a member name from JCL?"
Bob Bridges
SUBmit command) but not in this DD nor even this step.
Bob Hamilton, yesterday I would have responded to your guess (about the +1
generation not being catalogued yet) by pointing out that I'd asked it
about the FILE, not the DSN. But given your other complaints about
LISTDSI, and considering the fact that it's called "LISTDSI" not "LISTDDI",
it's possible it does exactly what you said it appears to, "operates by
looking up the associated dsname in the TIOT and proceeding as if the
programmer used LISTDSI <dsname> instead of giving information about the
FILE". Yet if that's the case, why did Rob not get the same result?
Rob, have you any pithy questions to ask me that might point up the
relevant difference between us? Shall I post more exact code and JCL?
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Most people are not avoiding our gospel, they are avoiding US. -from
"Shame off You" by Alan D Wright */
-----Original Message-----
From: J.D. Hill
Sent: Wednesday, May 2, 2007 11:52
Is your output on tape? LISTDSI won't work on tape datasets.
--- At 11:19 AM 5/2/2007, Hamilton, Robert L wrote:
>+1 won't be in the catalog until it's 'rolled' in at the end of the
>step.
>
>-----Original Message-----
>From: Bob Bridges
>Sent: Tuesday, May 01, 2007 10:39 PM
>
>I have a handy little Boolean function named DSDD which I've been calling
>for years to determine the status of a DSN or DDN. It uses LISTDSI (with
>or without the 'FILE' argument) to tell me whether a DS exists, or whether
>a certain DD name is currently allocated. I've been using it liberally in
>the application I described earlier.
>
>But today I discovered something I never suspected before: In batch,
>'LISTDSI ddname FILE' returns rc=16, sysreason=0002 if the DD isn't
>specified in the JCL, and it returns the EXACT SAME RESULTS if the DD
>specifies a GDG with +1 generation!
>
>How can this be?! Is there another way to check whether a DD is
>supplied in a batch REXX that won't mislead me this way?
>
>In the event I changed my whole approach: At the beginning of the run I
>do a LISTALC, make a table of all DDs available and refer to the table
>(instead of to DSDD/LISTDSI) whenever my logic needs to know whether a
>DD is offered. But sheesh! I'm suddenly growing disenchanted with
>LISTDSI. I'd thought it a reliable tool. Am I missing something obvious?
>Did everyone else already know about this limitation?
----------------------------------------------------------------------
Robert Zenuk
Rob
In a message dated 5/4/2007 6:10:49 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
Rob, have you any pithy questions to ask me that might point up the
relevant difference between us? Shall I post more exact code and JCL?
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
Barney Badass
But we all recognize there are some subtle differences between common
allocation (JCL) and dynamic allocation of GDG's correct?
Could that be the differences your results?
Bob Bridges
EDIT TRXB005.CLIST.CLIST(X) - 01.10
Command ===>
****** ***************************** Top of Data ************
000001 /* This REXX tests LISTDSI. */
000002 call chkdsi 'NEWCATP' /* "personal" DS */
000003 call chkdsi 'NEWCATG' /* New GDG DS */
000004 call chkdsi 'NEWCATX' /* Non-existent DD */
000005 exit
000006
000007 /* Check LISTDSI operation */
000008 chkdsi: arg dd
000009 call listdsi dd 'FILE'
000010 say 'LISTDSI of' dd': rc='result', reason='sysreason
000011 return
JCL:
//MyIDA JOB ('...'),'TEST JCL',
// CLASS=X,MSGCLASS=Y,NOTIFY=&SYSUID,
//**********************************************************
// EXEC PGM=IKJEFT01,PARM='%X'
//SYSPROC DD DSN=MyID.CLIST.CLIST,DISP=SHR
//SYSTSIN DD DUMMY
//NEWCATP DD DSN=MyID.X.X,DISP=(,CATLG),
// SPACE=(TRK,1),DCB=(DSORG=PS,RECFM=FB,LRECL=80)
//NEWCATG DD DSN=HLQ.DSEQD.DELLIST(+1),DISP=(,CATLG),
// DCB=(DSORG=PS,RECFM=FB,LRECL=80),SPACE=(CYL,1)
//SYSTSPRT DD SYSOUT=*
Output in SDSF:
SDSF OUTPUT DISPLAY...
********************************* TOP OF DATA
ACF0C038 ACF2 LOGONID ATTRIBUTES HAVE REPLACED DEFAULT USER ATTRIBUTES
LISTDSI of NEWCATP: rc=0, reason=0000
LISTDSI of NEWCATG: rc=16, reason=0002
LISTDSI of NEWCATX: rc=16, reason=0002
READY
END
******************************** BOTTOM OF DATA
Pretty simple, really.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* People seem to insist on making games that make it ever more difficult
for me to desire a life of my own. -Phillip Bridges */
-----Original Message-----
From: Robert Zenuk
Sent: Saturday, May 5, 2007 01:05
Sure, post the code. It will make it easier to see what may be different.
--- In a message dated 5/4/2007 6:10:49 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
Rob, have you any pithy questions to ask me that might point up the
relevant difference between us? Shall I post more exact code and JCL?
----------------------------------------------------------------------
Robert Zenuk
LISTDSI of NEWCATP: rc=0, reason=0000
LISTDSI of NEWCATG: rc=0, reason=0000
LISTDSI of NEWCATX: rc=16, reason=0002
Possibly maintenance... Any weird products in use that alter the GDG bias?
CA-11 used to have an option to do that. I'm not sure if it would manifest
itself that way, but it's worth looking into...
Rob
In a message dated 5/7/2007 2:58:19 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
My REXX code:
Pretty simple, really.
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
Bob Bridges
down from me, very accessible; the issue isn't as urgent for me as it was,
since I can use LISTALC, but I'll probably bring it up anyway.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* People seem to insist on making games that make it ever more difficult
for me to desire a life of my own. -Phillip Bridges */
-----Original Message-----
From: Robert Zenuk
Sent: Monday, May 7, 2007 19:28
I ran your code on my z/OS 1.6 system and it worked for me...
LISTDSI of NEWCATP: rc=0, reason=0000
LISTDSI of NEWCATG: rc=0, reason=0000
LISTDSI of NEWCATX: rc=16, reason=0002
Possibly maintenance... Any weird products in use that alter the GDG
bias? CA-11 used to have an option to do that. I'm not sure if it would
manifest itself that way, but it's worth looking into...
--- In a message dated 5/7/2007 2:58:19 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
My REXX code:
Pretty simple, really.
----------------------------------------------------------------------
Bob Bridges
later with a page from an IBM manual -- one of the TSO manuals, he said,
section 4.2.2 as I recall, but not the TSO Command Ref -- stating that
LISTDSI doesn't work for tape, nor for GDGs with relative numbers.
Absolute G0000V00 numbers, yes, but not relatives.
So how did YOU get it to work?
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* The horror of the Same Old Thing is one of the most valuable passions we
have produced in the human heart -- an endless source of heresies in
religion, folly in counsel, infidelity in marriage, and inconstancy in
friendship. -advice to a tempter, from The Screwtape Letters by C S Lewis
*/
-----Original Message-----
From: Robert Zenuk
Sent: Monday, May 7, 2007 19:28
I ran your code on my z/OS 1.6 system and it worked for me...
LISTDSI of NEWCATP: rc=0, reason=0000
LISTDSI of NEWCATG: rc=0, reason=0000
LISTDSI of NEWCATX: rc=16, reason=0002
Possibly maintenance... Any weird products in use that alter the GDG
bias? CA-11 used to have an option to do that. I'm not sure if it would
manifest itself that way, but it's worth looking into...
--- In a message dated 5/7/2007 2:58:19 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
My REXX code:
-----Original Message-----
Robert Zenuk
datasets. He is absolutely right, LISTDSI does not work agianst tape datasets. My
example was against disk datasets. However, the GDG's will resolve fine with
disk datasets (relative or absolute).
Rob
In a message dated 5/16/2007 5:37:09 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
My REXX code:
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
Poni, Nick N
Is there a batch utility to list all datasets with prefix
xxxxxxx.yyyyyyyy.* for example.
Thanks,
Nick
__________________________________________________________________________________________________________________________________
Standard Bank Disclaimer and Confidentiality Note
This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Standard Bank Group Limited
and/or its subsidiaries ("the Group"). It is confidential, private and intended for the addressee only. Should you not be the addressee and receive this e-mail by
mistake, kindly notify the sender, and delete this e-mail, immediately and do not disclose or use same in any manner whatsoever. Views and opinions
expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or
damages whatsoever and howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. The Group does not warrant the integrity
of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers
in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS).
For information about the Standard Bank Group Limited visit our website http://www.standardbank.co.za
___________________________________________________________________________________________________________________________________
Jeffrey C Benson
I'm just doing the same sort of thing - use LMDLIST see link below
http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci971021,00.html
Jeffrey C. Benson
Mainframe Security
Guardian Life Insurance Company
"Poni, Nick N" <Nick...@STANDARDBANK.CO.ZA>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
05/18/2007 11:19 AM
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
[TSO-REXX] List dataset with prefix
Thanks,
Nick
__________________________________________________________________________________________________________________________________
-----------------------------------------
This message, and any attachments to it, may contain information
that is privileged, confidential, and exempt from disclosure under
applicable law. If the reader of this message is not the intended
recipient, you are notified that any use, dissemination,
distribution, copying, or communication of this message is strictly
prohibited. If you have received this message in error, please
notify the sender immediately by return e-mail and delete the
message and any attachments. Thank you.
Imbriale, Donald
LISTC LVL(xxxxxxxx.yyyyyyyy)
This assumes you want cataloged data sets.
Don Imbriale
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Poni, Nick N
Sent: Friday, May 18, 2007 11:20 AM
To: TSO-...@VM.MARIST.EDU
Subject: List dataset with prefix
Is there a batch utility to list all datasets with prefix
xxxxxxx.yyyyyyyy.* for example.
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
brucem...@lombard.ca
faster version of LISTCAT - if you wish, I can send a sample for your use
============
Bruce Cooke
416-350-4387
"Poni, Nick N"
<Nick.Poni@STANDA
RDBANK.CO.ZA> To
Sent by: "TSO TSO-...@VM.MARIST.EDU
REXX Discussion cc
List"
<TSO-...@VM.MARI Fax to
ST.EDU>
Subject
[TSO-REXX] List dataset with prefix
05/18/2007 11:19
AM
Please respond to
"TSO REXX
Discussion List"
<TSO-...@VM.MARI
ST.EDU>
Is there a batch utility to list all datasets with prefix
xxxxxxx.yyyyyyyy.* for example.
Thanks,
Nick
__________________________________________________________________________________________________________________________________
------------------------------------------------------------------------------
This email is confidential.
If you are not the intended recipient, please notify
the sender by return email and delete this message
from your mail box without reading or copying it or
any attachments. While Lombard Canada Ltd. runs
anti-virus software on all servers and all PCs, it
cannot be held responsible for any infected files that
you may receive. Lombard Canada Ltd. advises all
recipients to virus scan any file attachments.
==============================================================================
Paul Gilmartin
> Date: Fri, 18 May 2007 12:34:26 -0400
>
> using CSI via REXX or Batch REXX is fast and reliable - CSI is a much
> faster version of LISTCAT - if you wish, I can send a sample for your use
>
Does "Batch REXX" mean IRXJCL?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
pdc
//LISTDSN EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN'
//DUMPFILE DD DUMMY
//SYSPRINT DD DISP=(,PASS),
// DSN=&&DFDSSRPT,
// UNIT=SYSDA,
// DCB=(LRECL=250,RECFM=VBA,DSORG=PS),
// SPACE=(TRK,(15,15))
//SYSIN DD *
DUMP OUTDDNAME(DUMPFILE) -
DATASET(INCLUDE( -
xxxxxxxx.yyyyyyyy.** -
))-
ALLDATA(*) -
CANCELERROR -
DELETE -
PURGE -
WAIT(2,99)
/*
"Imbriale, Donald" <DIMB...@BEAR.COM> wrote in message
news:59BCEA76BD5078489183...@whexchmb02.bsna.bsroot.bear.com...
Bob Bridges
mentioned tape as a side issue; my GDG{+1) is on disk, as you originally
understood.
I don't have the exact wording of the snippet my guy gave me, but here's
what I could find myself (once I knew to look for it). It's not mentioned
in all the places where LISTDSI is described, but it is here:
TSO CLISTs,
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj3b820/13.15:
The LISTDSI statement does not support data that is on tape. The LISTDSI
statement supports generation data group (GDG) data sets, but does not
support relative GDG names. LISTDSI does not support hierarchical file
systems (HFS) data sets. Unpredictable results may occur.
REXX Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj3a330/4.4.2:
You can use LISTDSI to obtain information about a data set that is
available on DASD. LISTDSI does not directly support data that is on tape.
LISTDSI supports generation data group (GDG) data sets when using absolute
generation names, but does not support relative GDG names. LISTDSI does not
support hierarchical file system (HFS) data sets. Unpredictable results may
occur.
So for me the question is no longer How come mine doesn't work?, because
the manual says it won't handle GDG relative numbers -- the question is now
How come it works for you?.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
Robert...@westfieldgrp.com, 330 791-6576
/* Normal people believe "if it ain't broke, don't fix it". Engineers
believe that if it ain't broke, it doesn't have enough features yet. -from
_The Dilbert Principal_ by Scott Adams */
-----Original Message-----
From: TRobert Zenuk
Sent: Thursday, May 17, 2007 10:41
Ahhhh... Either I missed it or you neglected to say these were tape
datasets. He is absolutely right, LISTDSI does not work agianst tape
datasets. My example was against disk datasets. However, the GDG's will
resolve fine with disk datasets (relative or absolute).
--- In a message dated 5/16/2007 5:37:09 PM US Mountain Standard Time,
rhb...@ATTGLOBAL.NET writes:
Rob, I ran this by a sysprog here at WG and he came back an hour or so
later with a page from an IBM manual -- one of the TSO manuals, he said,
section 4.2.2 as I recall, but not the TSO Command Ref -- stating that
LISTDSI doesn't work for tape, nor for GDGs with relative numbers.
Absolute G0000V00 numbers, yes, but not relatives.
So how did YOU get it to work?
-----Original Message-----
brucem...@lombard.ca
------------------------------------------------------------
This email is confidential.
If you are not the intended recipient, please notify
the sender by return email and delete this message
from your mail box without reading or copying it or
any attachments. While Lombard Canada Ltd. runs
anti-virus software on all servers and all PCs, it
cannot be held responsible for any infected files that
you may receive. Lombard Canada Ltd. advises all
recipients to virus scan any file attachments.
Robert Zenuk
JCL DD statement and LISTDSI will always return the full absolute GDS.
Rob
In a message dated 5/19/2007 2:29:24 PM US Mountain Standard Time,
brucem...@LOMBARD.CA writes:
My REXX code:
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
Paul Gilmartin
> Date: Sat, 19 May 2007 17:28:58 -0400
>
> Just to add - CSI under REXX, does either or both tape and dasd
>
HFS?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Bill Turner, WB4ALM
Depending on how the Systems Support staff has defined things,
you may or may not get what you want -
especially if the GDG is "in use" in another batch job.
Furthermore, there is a possibility that you might "lock out" a
production batch job from starting
while you have a GDG dataset "allocated".
There is no problem with absolute GDG numbers (G000V00), but there can
be a problem with
resolving relative ones.
There were some real reasons why GDG's are NOT supported from TSO - not
the least of which
has to do with the Operating Systems "defaults" of cataloging (or
deleting) GDG's at (1) step end or (2) Job end.
(Your friendly System Programmer made that choice for you - and probably
did so many years ago.)
And in the case of TSO both of those points are AFTER you log off.
and MY.PERSONAL.GDG(0) is a considered a relative value.
/s/ Bill Turner, wb4alm
Robert Zenuk
HFS are obviously not known to the catalog and CSI would not be any help.
Rob
In a message dated 5/19/2007 7:12:10 PM US Mountain Standard Time,
gil...@UNIX.STORTEK.COM writes:
In a recent note, <Bruce Cooke> said:
> Date: Sat, 19 May 2007 17:28:58 -0400
>
> Just to add - CSI under REXX, does either or both tape and dasd
>
HFS?
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------
Paul Gilmartin
> Date: Sun, 20 May 2007 10:25:12 EDT
>
> An HFS is a cataloged dataset, so CSI should work fine. Files within the
> HFS are obviously not known to the catalog and CSI would not be any help.
>
No, I meant, not the cataloged data set, but a DDNAME allocated to an HFS member
pathname. For example, after:
//SYSUT1 DD PATH='/etc/rc'
... what information will CSI supply about "SYSUT1 FILE"? Is it any more
useful than RC = LISTDSI( 'SYSUT1 FILE' )?
Also, what about spool data sets? E.g. "SYSPRINT FILE"?
Robert Zenuk
HFS LISTDSI RC=16 SYSREASON=2
Rob
In a message dated 5/20/2007 7:43:40 AM US Mountain Standard Time,
gil...@UNIX.STORTEK.COM writes:
//SYSUT1 DD PATH='/etc/rc'
************************************** See what's free at http://www.aol.com.
----------------------------------------------------------------------