JCL-Question
tschw...@nvag.de
Hello,
I hope I'm in the right group for my question ...
I want to write a job in JCL which
first step: check for the presence of a dataset
second step: just to be started, if dataset was there
third step: delete the dataset
I think it's an easy task, but I don't know if there are special
utils for checking for the presence of a dataset.
Tia
Thomas Schwickert
--
tschw...@nvag.de
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
James Anthony Williams
tschw...@nvag.de wrote:
>Hello,
>I hope I'm in the right group for my question ...
>I want to write a job in JCL which
>first step: check for the presence of a dataset
>second step: just to be started, if dataset was there
>third step: delete the dataset
>I think it's an easy task, but I don't know if there are special
>utils for checking for the presence of a dataset.
>Tia
> Thomas Schwickert
>--
>tschw...@nvag.de
Assuming your on MVS 4.1 or greater which introduced IF/ENDIF and
other useful JCL syntax you could use the below pueudocode. First of
all, if you code a DSN= in JCL the DSN must exist therefore you can
use the ability of IDCAMS to allocate datasets defined in a control
card library.
STEP1 EXEC IDCAMS and do a simple listcat. If the dataset is
cataloged and exists you will get a RC=0 else you get a RC=4 or
greater.
IF (RC=0) THEN
STEP2 EXEC PGM=XXX
DSN,(NEW,CATLG)
ENDIF
IF (STEP2.RC = 0)
STEP3 EXEC IDCAMS with an unconditional delete.
ENDIF
It should run like a scalded dog.
Josef Steinbach
tschw...@nvag.de wrote:
>
> Hello,
>
> I hope I'm in the right group for my question ...
>
> I want to write a job in JCL which
> first step: check for the presence of a dataset
> second step: just to be started, if dataset was there
> third step: delete the dataset
>
> I think it's an easy task, but I don't know if there are special
> utils for checking for the presence of a dataset.
>
> Tia
> Thomas Schwickert
> --
> tschw...@nvag.de
//LIST EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSIN DD *
//SYSTSIN DD *
LISTDS 'D620.V227'
//* WENN DSN NICHT DA GIBT ES RC 4
//*
//* IF (RC > 7) THEN
//*
//* ABBRUCH EXEC PGM=P400ABBR
//*
//* ELSE
//*
//* DATEI IST VORHANDEN
//*
//* ENDIF
//*-
Boyce G. Williams, Jr.
tschw...@nvag.de wrote:
>Hello,
>
>I hope I'm in the right group for my question ...
>
>I want to write a job in JCL which
>first step: check for the presence of a dataset
>second step: just to be started, if dataset was there
>third step: delete the dataset
>
>I think it's an easy task, but I don't know if there are special
>utils for checking for the presence of a dataset.
>
>Tia
> Thomas Schwickert
>--
>tschw...@nvag.de
>
>-------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
Simple, using JCL for MVS/ESA version 4:
//USERID1 JOB (9999,9999,99,999), ACCOUNTING INFORMATION
// 'USER NAME EXAMPLE', PROGRAMMER NAME AND JOB ID
// CLASS=A, INPUT QUEUE CLASS
// MSGLEVEL=(1,1), HOW MUCH MVS SYSTEM PRINT DESIRED
// MSGCLASS=D, PRINT DESTINATION
// NOTIFY=USERID WHO TO TELL WHEN JOB IS DONE
/*ROUTE PRINT RMT15
//*-------------------------------------------------------------------
//* EXAMPLE OF JCL
//*--------------------------------------------------------------------
//*- SET JCL SYMBOLIC PARAMETERS
//*-
// SET TPEIN01='AN.INPUT.FILE', INPUT FILE
// SET TPEUT01='AN.OUTPUT.FILE', OUTPUT FILE
//*
//*--------------------------------------------------------------------
//*- DELETE OUTPUT FILES
//*-
//USER0001 EXEC PGM=IEFBR14
//DSN01 DD DSN=&TPEUT01., OUTPUT FILE
// DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0)
//*--------------------------------------------------------------------
//*- CHECK INPUT FILES
//*-
//USER0002 EXEC PGM=IEFBR14
//DSN01 DD DISP=SHR,DSN=&TPEIN01. INPUT FILE
//*--------------------------------------------------------------------
//*- IF OK, COPY INPUT TO OUTPUT
//*-
// IF ( RC = 0 ) THEN
//USER0003 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=* STATUS REPORT
//SYSIN DD DUMMY INSTRUCTIONS
//SYSUT1 DD DISP=SHR,DSN=&TPEIN01. INPUT
//SYSUT2 DD DISP=(NEW,CATLG),DSN=&TPEUT01. OUTPUT
// ENDIF
//*--------------------------------------------------------------------
//*- IF OK, DELETE INPUT FILES
//*-
// IF ( RC = 0 ) THEN
//USER0004 EXEC PGM=IEFBR14
//DSN01 DD DSN=&DSNIN01., INPUT FILE
// DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0)
// ENDIF
//*--------------------------------------------------------------------
//
Hope this helps,
Boyce G. Williams, Jr.
.--------------------------------------------------------------------.
| "People should have two virtues: purpose- the courage to envisage |
| and pursue valued goals uninhibited by the defeat of infantile |
| fantasies, by guilt and the failing fear punishment; and wisdom- a|
| detached concern with life itself, in the face of death itself." |
| Norman F. Dixon|
'--------------------------------------------------------------------'
Jon Perryman
Can IEFBR14 really set a return code or do you have a modified IEFBR14 that
verifies the DSN's?
I would suggest using IDCAMS to do a listcat on the specific dataset.
Listcat will set the return code and the next step can check that return
code.
I'm not positive but I believe that IDCAMS can use a parm that has the
listcat command. This would allow you to use this facility easily in an stc
or create a proc that has the dsn in the jcl.
Boyce G. Williams, Jr. <bowil...@hsc.vcu.edu> wrote in article
<342f9f1...@usenet.acw.vcu.edu>...
tschw...@nvag.de
Hi,
thanks to all people helping me.
I've made it with the IKJEFT01 and LISTDS and then
with the COND parameter.
Thank you very much
Greetings
Thomas Schwickert
In article <8755200...@dejanews.com>,
Boyce G. Williams, Jr.
"Jon Perryman" <jon.pe...@worldnet.att.net> wrote:
>Can IEFBR14 really set a return code or do you have a modified IEFBR14 that
>verifies the DSN's?
>
>I would suggest using IDCAMS to do a listcat on the specific dataset.
>Listcat will set the return code and the next step can check that return
>code.
>
>I'm not positive but I believe that IDCAMS can use a parm that has the
>listcat command. This would allow you to use this facility easily in an stc
>or create a proc that has the dsn in the jcl.
>
>jon.pe...@att.worldnet.net
As I recalled your post, you wanted a job that a) checks whether a
dataset exists; b) run a program if the dataset does exists and c)
delete the dataset if b) runs successfully. IEFBR14 is the
time-honoured method for that checking and deleting.
IEFBR14 in itself does nothing. It calls on no resources and takes up
very little core memory. It's just an exit (BR 14 is assembler code
for BRANCH TO REGISTER 14, whichs exits the program). Its power is
forcing the rest of the IBM operating system to act on what you
specified in the DD statement. If you specified DISP=SHR and the
dataset doesn't exits then the operating system returns an 806 error
message with an error code 12 saying the dataset doesn't exist.
DISP=(MOD,DELETE) deletes a PDS or sequential dataset whether or not
it exists (deleting VSAMs requires IDCAMS).
Now if you want to reset condition codes, say creating a user-named
GDG base if the user has never ran the job before and have the job add
a generation in a later jobstep, then IDCAMS comes onto its own:
//JOBSTEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
VERIFY (&ZUSER..YOUR.GDG)
IF LASTCC > 0 THEN -
SET LASTCC = 0 -
SET MAXCC = 0 -
DEFINE GDG ( NAME (&ZUSER..YOUR.GDG)-
LIMIT (3) -
NOEMPTY -
SCRATCH )
IF LASTCC > 0 THEN SET MAXCC = 16
/*
//JOBSTEP2 EXEC PGM=PROGRAM,COND=(0,LT)
//DDNAME DD &ZUSER..YOUR.GDG(+1),DISP=(NEW,CATLG)
// AVGREC=U,RECFM=FB,LRECL=80,
// SPACE=(80,(200,10),RLSE)
//
In the above example one has to have the IDCAMS instructions in a ISPF
skeleton to tailor the userid onto the JCL. One can also set up the
instructions in a CLIST, use "&SYSUID." instead of "&ZUSER.". IDCAMS
can be used just to VERIFY a file; like determining whether the file
is a VSAM file or not. IEFBR14 justs checks it existance.
Choose the right tools for the right job,
Jim Van Sickle
Boyce G. Williams, Jr. wrote:
>
> "Jon Perryman" <jon.pe...@worldnet.att.net> wrote:
>
> >Can IEFBR14 really set a return code or do you have a modified IEFBR14 that
> >verifies the DSN's?
> >
>
> As I recalled your post, you wanted a job that a) checks whether a
> dataset exists; b) run a program if the dataset does exists and c)
> delete the dataset if b) runs successfully. IEFBR14 is the
> time-honoured method for that checking and deleting.
>
> IEFBR14 in itself does nothing. It calls on no resources and takes up
> very little core memory. It's just an exit (BR 14 is assembler code
> for BRANCH TO REGISTER 14, whichs exits the program). Its power is
> forcing the rest of the IBM operating system to act on what you
> specified in the DD statement. If you specified DISP=SHR and the
> dataset doesn't exits then the operating system returns an 806 error
> message with an error code 12 saying the dataset doesn't exist.
> DISP=(MOD,DELETE) deletes a PDS or sequential dataset whether or not
> it exists (deleting VSAMs requires IDCAMS).
>
Hmph!
I don't know what operating system or JES y'all are using, but I have never seen
anything like this work. When I try this on my current system (MVS/ESA 5.2
w/JES2 & SMS) the job FLUSHes when it gets to the IEFBR14 step with the
nonexistent dataset, as I would expect and hope it would, and none of the
subsequent steps are executed, even with COND=EVEN. Furthermore, AFAIK the only
way to get a S806 is when you try to load or attach a module that can't be
LOCATEd. Finally, I checked the AMS for ICF manuals and it seems the only think
you can pass to IDCAMS via exec parm is diagnostic settings.
I've seen a lot of seemingly bogus replies in this thread (and others as
well)...
Did anyone actually *test* before posting here???????
--
***********************************************
* Jim Van Sickle <mailto:jim...@ibm.net> *
* Manager, Operations and Tech Support *
* United Retail, Inc. *
*---------------------------------------------*
* visit my meager web site at: *
* <http://mypage.ihost.com/jimswebsite/> *
***********************************************
Metz, Seymour
1.) IEFBR14 does more than BR 14, although that's all that was in the first
version. Ever since Old Man Noach cornered the market in Gopher wood IEFBR14
has also set a return code of 0. That's not conditional; it's always zero.
2.) If you have a reference (DISP=OLD or SHR) to a cataloged data set that
doesn't exist, the step will be allocated and will complete normally.
3.) If you have a reference (DISP=OLD or SHR) to a data set that isn't
cataloged and no explicit volser, allocation will fail.
4.) If you have a reference (DISP=OLD or SHR) to a cataloged data set or
have an explicit volser, and the volume is not available, allocation will
fail.
Note that 2-4 have nothing to do with the fact that PGM=IEFBR14; the same
processing would occur for any program. And, as noted, there's not S806
ABEND involved.
Shmuel (Seymour J.) Metz
----------
From: Jim Van Sickle
To: smetz; IBM-MAIN
Subject: Re: JCL-Question
Date: Tuesday, September 30, 1997 12:52PM
Edward(Ed) J. Finnell,III
Don't remember the level, but FDR would fake an 806 for DSN not allocatable
even with BR14.
EDWARD J. FINNELL,III(EFIN...@UA1VM.UA.EDU)
MVS/Proj. Mgr.
http://www.ua.edu
Bob Halpern
IEFBR14 has more apar activity than lines of code.
1. As stated below, to do the SR 15,15 before the BR 14.
2. To be marked re-entrant (I used it to stub off some modules
for testing, and got 17 copies of a rather large module before
the 80A. I did the second apar.
John Wolf wrote:
>
> In <0CA3...@gsg.eds.com>, on 09/30/97
> at 04:13 PM, "Metz, Seymour" <sm...@GSG.EDS.COM> said:
>
> >1.) IEFBR14 does more than BR 14, although that's all that was in the
> >first version. Ever since Old Man Noach cornered the market in Gopher
> >wood IEFBR14 has also set a return code of 0. That's not conditional;
> >it's always zero.
>
> > ----------
> >>
> >> >Can IEFBR14 really set a return code or do you have a modified IEFBR14
> >that
> >> >verifies the DSN's?
> >> >
> > --snip--
> IEFBR14 is the ONLY one instruction program, that I know of, that had an
> APAR made up for it. Way back like ten years ago IBM changed how R15 was
> setup on return and BR14 started to give non zero return codes. This of
> course changed how some JCL streams worked. So IBM had to change BR14 so
> that it zeroed out R15 before it returned via R14.
> -----------------------------------------------------------
> wol...@ibm.net
> -----------------------------------------------------------
John Wolf
Edward(Ed) J. Finnell,III
I think it's had four against it. Some are old and I didn't write them
down. 1)No eye-catcher 2) Not fullword aligned 3)RC ne 0 4)Left it out of
HBB4410 altogether.
Boyce G. Williams, Jr.
Jim Van Sickle <jim...@ibm.net> wrote:
>Boyce G. Williams, Jr. wrote:
>>
>> "Jon Perryman" <jon.pe...@worldnet.att.net> wrote:
>>
>> >Can IEFBR14 really set a return code or do you have a modified IEFBR14 that
>> >verifies the DSN's?
>> >
>--snip--
>>
I just did and the jcl worked as advertised. If the file didn't
exist, the job stoped. But I stand corrected on the 806 error (it
been awhile since this situation came up, a comment on how good my
coding has gotten).
If one wants to perform selective running of jobsteps, then one must
use IDCAMS or some other utility to manipulate the condition code; as
this "tested" example shows:
********************** TOP OF DATA ***********************************
J E S 2 J O B L O G -- S Y S T E M V 1 P 1 -- N O D
10:18:06 JOB08164 ---- WEDNESDAY, 01 OCT 1997 ----
10.18.06 JOB08164 $HASP373 CWILLIA5 STARTED- INIT 1- CLASS A- SYS V1P1
10.18.06 JOB08164 ACF9CCCD USERID CWILLIA IS ASSIGNED TO THIS JOB-
CWILLIA5
10.18.06 JOB08164- --TIMINGS (M
10.18.06 JOB08164-JOBNAME STEPNAME PROCSTEP RC EXCP CONN TCB SRB
10.18.06 JOB08164-CWILLIA5 USER0001 16 9 7 .00 .00
10.18.07 JOB08164-CWILLIA5 STEP0002 FLUSH 0 0 .00 .00
10.18.07 JOB08164-CWILLIA5 STEP0003 00 9 19 .00 .00
10.18.07 JOB08164-CWILLIA5 ENDED. NAME-BWILLIAMS IDCAMS15 TOTAL TCB
CPU TIM
10.18.07 JOB08164 $HASP395 CWILLIA5 ENDED
------ JES2 JOB STATISTICS ------
01 OCT 1997 JOB EXECUTION DATE
30 CARDS READ
83 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
5 SYSOUT SPOOL KBYTES
0.02 MINUTES EXECUTION TIME
1 //CWILLIA5 JOB (5500,2710,99,999),'BWILLIAMS IDCAMS15',
// CLASS=A,MSGCLASS=D,MSGLEVEL=(1,1),NOTIFY=CWILLIA
/*ROUTE PRINT RMT15
//* $ACFJ219 ACF2 ACTIVE VCUMVS
//*-------------------------------------------------------
//* TEST VERIFY STATEMENT
//*-------------------------------------------------------
2 //USER0001 EXEC PGM=IDCAMS
3 //SYSPRINT DD SYSOUT=*
4 //SYSUDUMP DD SYSOUT=*
5 //SYSIN DD *
//*-------------------------------------------------------
6 //STEP0002 EXEC PGM=IKJEFT01,DYNAMNBR=30,
// COND=(0,LT)
7 //SYSUDUMP DD SYSOUT=*
8 //SYSTSPRT DD SYSOUT=*
9 //SYSTSIN DD *
//*-------------------------------------------------------
10 //STEP0003 EXEC PGM=IKJEFT01,DYNAMNBR=30,
// COND=(EVEN,(0,EQ,STEP0002))
11 //SYSUDUMP DD SYSOUT=*
12 //SYSTSPRT DD SYSOUT=*
13 //SYSTSIN DD *
IEF236I ALLOC. FOR CWILLIA5 USER0001
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF237I JES2 ALLOCATED TO SYSUDUMP
IEF237I JES2 ALLOCATED TO SYSIN
IEF142I CWILLIA5 USER0001 - STEP WAS EXECUTED - COND CODE 0016
IEF285I CWILLIA.CWILLIA5.JOB08164.D0000104.? SYSOUT
IEF285I CWILLIA.CWILLIA5.JOB08164.D0000105.? SYSOUT
IEF285I CWILLIA.CWILLIA5.JOB08164.D0000101.? SYSIN
IEF373I STEP/USER0001/START 1997274.1018
IEF374I STEP/USER0001/STOP 1997274.1018 CPU 0MIN 00.09SEC SRB 0MIN
00.00S
IEF202I CWILLIA5 STEP0002 - STEP WAS NOT RUN BECAUSE OF CONDITION
CODES
IEF272I CWILLIA5 STEP0002 - STEP WAS NOT EXECUTED.
IEF373I STEP/STEP0002/START 1997274.1018
IEF374I STEP/STEP0002/STOP 1997274.1018 CPU 0MIN 00.00SEC SRB 0MIN
00.00S
IEF236I ALLOC. FOR CWILLIA5 STEP0003
IEF237I JES2 ALLOCATED TO SYSUDUMP
IEF237I JES2 ALLOCATED TO SYSTSPRT
IEF237I JES2 ALLOCATED TO SYSTSIN
IEF142I CWILLIA5 STEP0003 - STEP WAS EXECUTED - COND CODE 0000
IEF285I CWILLIA.CWILLIA5.JOB08164.D0000108.? SYSOUT
IEF285I CWILLIA.CWILLIA5.JOB08164.D0000109.? SYSOUT
IEF285I CWILLIA.CWILLIA5.JOB08164.D0000103.? SYSIN
IEF373I STEP/STEP0003/START 1997274.1018
IEF374I STEP/STEP0003/STOP 1997274.1018 CPU 0MIN 00.21SEC SRB 0MIN
00.00S
IEF375I JOB/CWILLIA5/START 1997274.1018
IEF376I JOB/CWILLIA5/STOP 1997274.1018 CPU 0MIN 00.30SEC SRB 0MIN
00.00S
IDCAMS SYSTEM SERVICES
TIME: 10:18:06
VERIFY DATASET (CWILLIA.NONEXIST.FILE)
IKJ56228I DATA SET CWILLIA.NONEXIST.FILE NOT IN CATALOG OR CATALOG CAN
IKJ56228I NOT BE ACCESSED
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
IF LASTCC > 0 THEN SET MAXCC = 16
IDC3207I REMAINDER OF COMMAND INPUT STREAM IGNORED
IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 16
ACF0C038 ACF2 LOGONID ATTRIBUTES HAVE REPLACED DEFAULT USER ATTRIBUTES
READY
SEND 'THE FILE DOES NOT EXISTS.' U(CWILLIA) LOGON
READY
END
************************* BOTTOM OF DATA *****************************
Just my two cents worth, adjusted for inflation,
. . . . . . . . . . . . . . . . . . . . . . .
. . . .
Kenneth J. Kripke
TMP to interrogate the existenece of the dataset and set an appropriate
return code?
Tom Marchant
//ddn DD DSN=dsname,DISP=(MOD,DELETE),UNIT=unit,SPACE=space-allocation...
It failed for you because you didn't give the parameters needed to allocate a
new one if it didn't exist. It works because MOD means to write on the end
_IF_ the data set already exists, otherwise allocate a new one. Make the space
allocation one track.
Tom Marchant
John P. Kalinich
Better yet, make the space allocation no tracks: SPACE=(TRK,0)
---
Michael Weintraub
This is a multi-part message in MIME format.
--------------E63B98A35757BD28B72076EA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas,
this is really a job for a scheduler. No easy way to do that with MVS means
only, unless you want to code in assembler. One "solution" that comes to
mind is to use IDCAMS repro with the file (that you want to know if it
exists) name in the control cards and have a cond condition on the following
step. Again, if the file is large.....
If you want more info, please contact me via private mail, we sell a
scheduler which dos things like that...
tschw...@nvag.de wrote:
> Hello,
>
> I hope I'm in the right group for my question ...
>
> I want to write a job in JCL which
> first step: check for the presence of a dataset
> second step: just to be started, if dataset was there
> third step: delete the dataset
>
> I think it's an easy task, but I don't know if there are special
> utils for checking for the presence of a dataset.
>
> Tia
> Thomas Schwickert
> --
> tschw...@nvag.de
>
> -------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
--
=============================================================================
Michael Weintraub (mwei) Phone : +49 (2102) 400-700
Product Manager Fax : +49 (2102) 400-755
Boole & Babbage Deutschland GmbH CIS : 70033,751
Email: Office: mw...@bbedus.mhs.compuserve.com/Privat: mw...@usa.net
--------------E63B98A35757BD28B72076EA
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Michael Weintraub
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Michael Weintraub
n: Weintraub;Michael
adr: Kaiserswertherstr. 105;;;Ratingen;NRW;40880;Germany
email;internet: mw...@usa.net
tel;work: +492102400500
tel;fax: +492102400500
tel;home: +491714391901
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
--------------E63B98A35757BD28B72076EA--
William Ball
I've been using a clist to execute a DELETE and DELETE noscratch for quite a
while
now. I have a proc I call BR14 that takes the dataset name in as a symbolic and
passes it to the clist. I has the advantage of not having to code space
parameters
and worry about disp=mod and it doesn't care if the dataset is there or just
catalogued, either way when the step is done, the dataset is history and ready
to
be realocated again AND it's a one liner to the execution JCL.
It works well for most deletes but if you're trying to delete a specific
generation of a GDG, clists can't interprut the relative generation. For run of
the mill permanent work files etc., it works very well.
//DELETE EXEC BR14,DSN='ANY. OLD. DATASET'
John P. Kalinich wrote:
--
Bill Ball
Email: WB...@KENT.EDU
()_() ()*()
(_) (_)
Have a Disney day.
Jim Van Sickle
> //ddn DD DSN=dsname,DISP=(MOD,DELETE),UNIT=unit,SPACE=space-allocation...
>
> It failed for you because you didn't give the parameters needed to allocate a
> new one if it didn't exist. It works because MOD means to write on the end
> _IF_ the data set already exists, otherwise allocate a new one. Make the space
> allocation one track.
>
> Tom Marchant
The initial intent was to check if the dataset in question existed or not and
set a completion code that would be tested in a subsequent JCL step. I maintain
that this cannot be accomplished with IEFBR14 or JCL DISP checking itself. The
(MOD,DELETE) does work when the intent is to unconditionally delete the dataset
if it is cataloged (which was the last requirement in the original post) but
again no condition codes are set. Wouldn't it be nice if the JCL 'IF' construct
were expanded to include such a test, something to the effect of: IF
'my.dataset' CATALOGED.... (do I smell a SHARE requirement?). This has been
do-able in DOS .BAT files for a hundred years!
Not to get off the subject, but the biggest problem with using the IEFBR14
(MOD,DELETE) method to delete datasets--especially in a development environment
when running infrequently used jobs--is HSM recalls. I've seen some developers
who have IEFBR14's with 20-30 datasets or more, and they wonder why their job is
swapped-out for 1/2 hour. It's all those damned recalls. I did the same thing
that William did - wrote a REXX procedure (which I called SCRATCH) that checks
the whereabouts of one or more specified datasets and does DELETEs (DASD),
DELETE NOSCRATCHes (TAPE), or HDELETEs (MLx) appropriately, but like William
said, relative GDG's are still a problem. To allow execution from within a proc,
it can accept a single DSN via execution parm, or multiple via DD input.
I think the IDCAMS LISTCAT method is the best, seconded by IKJEFT01 w/LISTDS
(but I'm pretty sure he will result in an HSM recall if the dataset is
migrated).
Just another $0.02 :-)
John Wolf
In <3431BCC3...@cpuperform.com>, on 09/30/97
at 08:00 PM, Bob Halpern <b...@CPUPERFORM.COM> said:
>IEFBR14 has more apar activity than lines of code.
> 1. As stated below, to do the SR 15,15 before the BR 14.
> 2. To be marked re-entrant (I used it to stub off some modules
> for testing, and got 17 copies of a rather large module before
> the 80A. I did the second apar.
>John Wolf wrote:
>>
>> > ----------
>> >>
>> >> >Can IEFBR14 really set a return code or do you have a modified IEFBR14
>> >that
>> >> >verifies the DSN's?
>> >> >
>> > --snip--
>> IEFBR14 is the ONLY one instruction program, that I know of, that had an
>> APAR made up for it. Way back like ten years ago IBM changed how R15 was
>> setup on return and BR14 started to give non zero return codes. This of
>> course changed how some JCL streams worked. So IBM had to change BR14 so
>> that it zeroed out R15 before it returned via R14.
>> -----------------------------------------------------------
>> wol...@ibm.net
>> -----------------------------------------------------------
As has been pointed out to me I misspoke. The first cut of IEFBR14 had
ONLY ONE instruction in it BR R14.
When IBM fixed it they ADDED a SR R15,R15 before the BR R14 so the return
code would be zero. IEFBR14 does NOTHING but send your JCL through
allocation. The resulting data set,assuming you are allocating a new
dataset, will not be opened and therefore will not have any DCB stuff set
up ie: LRECL BLKSIZE RECFM.
--
-----------------------------------------------------------
wol...@ibm.net
-----------------------------------------------------------
Robinson, Jesse "Skip" O
We've had shorter threads on major subsystems!
From: J.O. Skip Robinson
Enterprise System Support, PAX 2-7535
Rosemead GO-2, 626-302-7535 (or 818-)
robi...@sce.com
>----------
>From: Jim Van Sickle[SMTP:jim...@IBM.NET]
>Sent: Thursday, October 02, 1997 10:38 AM
>To: IBM-...@UA1VM.UA.EDU
>Subject: Re: JCL-Question
>
>Tom Marchant wrote:
>>
>> "Jim Van Sickle" <jim...@IBM.NET> wrote:
>> >
>> >Boyce G. Williams, Jr. wrote:
>> >>
>> >> "Jon Perryman" <jon.pe...@worldnet.att.net> wrote:
>> >>
>> >> >Can IEFBR14 really set a return code or do you have a modified IEFBR14
>that
>> >> >verifies the DSN's?
>> >> >
>> >--snip--
>> >>
Gilbert Saint-flour
In <3433DC19...@ibm.net>, on 10/02/97
at 01, Jim Van Sickle <jim...@ibm.net> said:
>Tom Marchant wrote:
>Wouldn't it be nice if the JCL 'IF' construct were expanded to include
>such a test, something to the effect of: IF 'my.dataset' CATALOGED....
Don't hold your breath . . .
IF is a thin coat of paint on top of the old COND, nothing more. It's
processed when the JCL is converted, way too early to check for the
existence of a data set. You need a live program, CLIST or REXX EXEC to
check the catalog and set a return code.
>Not to get off the subject, but the biggest problem with using the
>IEFBR14 (MOD,DELETE) method to delete datasets--especially in a
>development environment when running infrequently used jobs--is HSM
>recalls. I've seen some developers who have IEFBR14's with 20-30 datasets
>or more, and they wonder why their job is swapped-out for 1/2 hour. It's
>all those damned recalls.
A couple of years ago, I was so pissed off by this problem that I wrote
the CLEANUP and RECALL utilities programs that can be found on file 183 of
the CBT tape. You execute them as the 1st step of your job; CLEANUP
deletes (or HDELETEs) data sets that are created (DISP=(NEW,CATLG) in
subsequent steps of the job, and RECALL HRECALLs migrated data sets "en
masse".
The nice thing is that both programs automatically retrieve dsnames from
in-storage images of the JCL, you don't have to pass a parm or a SYSIN.
The other nice thing is that, when RECALL issues HRECALLs for 20 data sets
that happen to be on the same ML2 volume, the tape only has to be mounted
once. Tremendous time savers.
Just another $0.02 :-)
Gilbert Saint-flour <g...@ibm.net>
Leonard D. Woren
Gilbert Saint-flour wrote:
> >Tom Marchant wrote:
> >Wouldn't it be nice if the JCL 'IF' construct were expanded to include
> >such a test, something to the effect of: IF 'my.dataset' CATALOGED....
>
> Don't hold your breath . . .
Like, say, in unix csh: if (-e filename) ...
> IF is a thin coat of paint on top of the old COND, nothing more. It's
> processed when the JCL is converted, way too early to check for the
> existence of a data set. You need a live program, CLIST or REXX EXEC to
> check the catalog and set a return code.
How about this one:
// exec pgm=ikjeft1a,parm='listcat entries(xxx)'
//systsprt dd dummy
//systsin dd dummy
You get rc=0 if it's cataloged, rc=4 if not. IKJEFT1A is an alternate
entry point for the TMP which passes through the return code from the
invoked command.
/Leonard
Jim Van Sickle
Gilbert,
I've seen CLEANUP but I'm scared to death to unleash it on my development staff!
They'd accidentally delete their own Mother if you let them... The best part
about getting the DSN's from the JCT(?) is that you don't have to worry about
absolute GDG's, isn't that right?
I also agree that the 'IF' construct will probably never be able to handle
anything so advanced as checking the catalog (and how would you tell it *which*
catalog in the first place? JOBCAT? Not likely)...this was more wishful thinking
than anything else.
Lastly, I've noticed that newer releases of HSM *seem* to 'consolidate' ML2
recall requests so as to minimize tape access--I don't think he always did this.
Can anyone confirm?
Cheers :-)
Gilbert Saint-flour wrote:
>
> In <3433DC19...@ibm.net>, on 10/02/97
> at 01, Jim Van Sickle <jim...@ibm.net> said:
>
> >Tom Marchant wrote:
> >Wouldn't it be nice if the JCL 'IF' construct were expanded to include
> >such a test, something to the effect of: IF 'my.dataset' CATALOGED....
>
> Don't hold your breath . . .
>
> IF is a thin coat of paint on top of the old COND, nothing more. It's
> processed when the JCL is converted, way too early to check for the
> existence of a data set. You need a live program, CLIST or REXX EXEC to
> check the catalog and set a return code.
>
> >Not to get off the subject, but the biggest problem with using the
> >IEFBR14 (MOD,DELETE) method to delete datasets--especially in a
> >development environment when running infrequently used jobs--is HSM
> >recalls. I've seen some developers who have IEFBR14's with 20-30 datasets
> >or more, and they wonder why their job is swapped-out for 1/2 hour. It's
> >all those damned recalls.
>
> A couple of years ago, I was so pissed off by this problem that I wrote
> the CLEANUP and RECALL utilities programs that can be found on file 183 of
> the CBT tape. You execute them as the 1st step of your job; CLEANUP
> deletes (or HDELETEs) data sets that are created (DISP=(NEW,CATLG) in
> subsequent steps of the job, and RECALL HRECALLs migrated data sets "en
> masse".
>
> The nice thing is that both programs automatically retrieve dsnames from
> in-storage images of the JCL, you don't have to pass a parm or a SYSIN.
> The other nice thing is that, when RECALL issues HRECALLs for 20 data sets
> that happen to be on the same ML2 volume, the tape only has to be mounted
> once. Tremendous time savers.
>
> Just another $0.02 :-)
>
> Gilbert Saint-flour <g...@ibm.net>
--
Frank Clarke
"Robinson, Jesse \"Skip\" O" <ROBI...@SCE.COM> wrote:
>We've had shorter threads on major subsystems!
...and longer ones on topics not nearly as interesting ;-)
Gilbert Saint-flour
On 10/03/97, Jim Van Sickle <jim...@ibm.net> said:
>I've seen CLEANUP but I'm scared to death to unleash it on my development
>staff! They'd accidentally delete their own Mother if you let them... The
>best part about getting the DSN's from the JCT(?) is that you don't have
>to worry about absolute GDG's, isn't that right?
Sorry Jim, but CLEANUP does NOT handle GDSs (it was designed originally to
prevent NOT CATLG 2 errors). And, by the way, you get the DSNs from the
JFCBs.
>Lastly, I've noticed that newer releases of HSM *seem* to 'consolidate'
>ML2 recall requests so as to minimize tape access--I don't think he
>always did this. Can anyone confirm?
This is not just an HSM problem, it's more caused by the fact that the
initiator and HSM don't talk to each other. As far as I understand it,
the INIT issues a LOCATE with the RECALL bit on, which is converted to an
HRECALL WAIT by catalog management. Because of the WAIT, there is one and
only one RECALL active for a given job at a time, and the INIT is stuck
(non-cancellable) until SVC 26 comes back. HSM changed in 2.5 or 2.6 (I
think) to check its MWE queue for additional RECALL requests on the tape
volume it's about to dismount, but that only has an effect on RECALLs
issued by other jobs.
If the initiator was made aware of migrated data sets (AFAIK it isn't), it
could issue ARCHRCAL in ASYNC mode then do a WAITM until all the RECALLs
are complete.
--
-----------------------------------------------------------
Gilbert Saint-flour <g...@ibm.net>
-----------------------------------------------------------
Barry Rowan
In message <60o3l0$7...@camel4.mindspring.com> - tec...@mindspring.com
(James Anthony Williams)Mon, 29 Sep 1997 11:32:46 GMT writes:
:>
:>Assuming your on MVS 4.1 or greater which introduced IF/ENDIF and
:>other useful JCL syntax you could use the below pueudocode. First of
:>all, if you code a DSN= in JCL the DSN must exist therefore you can
:>use the ability of IDCAMS to allocate datasets defined in a control
:>card library.
:>
:>STEP1 EXEC IDCAMS and do a simple listcat. If the dataset is
:>cataloged and exists you will get a RC=0 else you get a RC=4 or
:>greater.
:> IF (RC=0) THEN
:>STEP2 EXEC PGM=XXX
:>DSN,(NEW,CATLG)
:> ENDIF
:>IF (STEP2.RC = 0)
:>STEP3 EXEC IDCAMS with an unconditional delete.
:>ENDIF
:>
:>It should run like a scalded dog.
:>>-------------------==== Posted via Deja News ====-----------------------
Mine barfed like a very sick puppy...
My only difference was that if the dataset was there, I used IEBGENER
to copy it to a GDG. In the test environment, it worked great, but in
production we use ZEKE for our scheduler and it barfed when it saw the
reference to the dataset that wasn't there despite the fact it was
surrounded by the IF based on the RC from IDCAMS/LISTCAT.
It didn't even try to execute it, it failed during the scan.
My newest idea is to do the copying in a separate proc. When IDCAMS
sees that it's not there, we'll tell ZEKE to mark the copying proc
complete so it doesn't try to execute it. I may have to go that route
since our standards do not allow us to call procs from procs.
Barry
Metz, Seymour
It's trivial with MVS means. The first step call a REXX that uses LISTDSI or
SYSDSN to test whether the data set exists and sets a return code.
Shmuel (Seymour J.) Metz
----------
From: Michael Weintraub
To: smetz; IBM-MAIN
Subject: Re: JCL-Question
Date: Thursday, October 02, 1997 12:34PM
<<File Attachment: VCARD.VCF>>
Thomas,
this is really a job for a scheduler. No easy way to do that with MVS means
only, unless you want to code in assembler. One "solution" that comes to
mind is to use IDCAMS repro with the file (that you want to know if it
exists) name in the control cards and have a cond condition on the following
step. Again, if the file is large.....
If you want more info, please contact me via private mail, we sell a
scheduler which dos things like that...
tschw...@nvag.de wrote:
> Hello,
>
> I hope I'm in the right group for my question ...
>
> I want to write a job in JCL which
> first step: check for the presence of a dataset
> second step: just to be started, if dataset was there
> third step: delete the dataset
>
> I think it's an easy task, but I don't know if there are special
> utils for checking for the presence of a dataset.
>
> Tia
> Thomas Schwickert
> --
> tschw...@nvag.de
>
> -------------------==== Posted via Deja News ====-----------------------