Input and output filenames in the SYSIN rather than DDnames

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Hi all,

I was trying to copy a file using IDCAMS REPRO command.

Is it possible to give input and output filenames in the SYSIN card rather than the ddnames for copying.

==> If the above is possible with any other SORT command also, please
let me know. Thanks

Regards,
Karthi.

Gnanas N · Posted: Tue Feb 24, 2009 9:38 am

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Hi,

Ths SYSIN card that we give for REPRO is
//SYSIN DD *
REPRO -
INFILE(INDD) -
OUTFILE(OUTDD)
/*

Is it possible to give
//SYSIN DD *
REPRO -
INFILE(Input dataset name) -
OUTFILE(Output dataset name)
/*

Thanks,
Karthi

Gnanas N · Posted: Tue Feb 24, 2009 9:48 am

This will do it.

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Hi Gnans,

Thanks a lot !! It works for me.

Regards,
Karthi.

Terry Heinze · Posted: Tue Feb 24, 2009 10:02 am

The manual entitled DFSMS/MVS V1R5 Access Method Services for VSAM Catalogs has your answer. Also, I think you'll find that your site's SORT product will perform better than IDCAMS REPRO when it comes to copying files.

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Hi Terry,

Thanks. Please let me know if we can use SORT for the same.

Is it possible to specify the input and output datasets in the SORT
SYSIN card for copying ????

Regards,
Karthi

Terry Heinze · Posted: Tue Feb 24, 2009 10:35 am

Not in SYSIN. See the JCL syntax for your site's SORT product.

dick scherrer · Posted: Tue Feb 24, 2009 10:35 am

Hello,

Typically, when a file is copied using the sort, the SORTIN and SORTOUT dd statements contain the input and output dataset names. If the dcb info is not specified, the input dcb info is copied onto the output file.

The only sysin data needed is

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Thanks Dick and Terry.

I am aware of OPTION copy in SORT.

My filenames are dynamic. I cannot directly give it in the SORTIN
and SORTOUT. I have to mention them in the SYSIN only.

That the reason i checked with IDCAMS.

Thanks a lot of all ur input!!

Regards,
Karthi

dick scherrer · Posted: Tue Feb 24, 2009 11:06 am

Hello,

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Hi Dick,

My output filename of copy is dynamic
The output filename looks like APCD.APCD###.APCD ,Where ### -is a sequence number

I have a pgm where this sequence number for the file is arrived upon. In this program itself, I will create a temp file with contents as
REPRO INDATASET(‘My original file name’)
OUTDATASET(‘APCD.APCD###.APCD)

I will then use the temp file as SYSIN to the next IDCAMS step.
Step1- Program where the temp file with seq # replaced is created
Step2 – IDCAMS for copying.

Regards,
Karthi

expat · Posted: Tue Feb 24, 2009 1:08 pm

Why do people insist on using manually generated sequence numbers instead of a GDG. Why reinvent the wheel when the wheel works perfectly well in the first place.

dick scherrer · Posted: Tue Feb 24, 2009 9:02 pm

Hello,

If you can generate the sysin, you can generate the entire step including the dd/dsns. Once generated, these would be submitted via the internal reader.

If you are copying a few records, which utility you use will not much matter. If you are copying hundreds of millions of records, you want to use sort rather than idcams regardless if it takes a bit more implementation work.

Also, as Expat mentions, is there some business reason to implement your own mechanics for "generations". GDGs have worked well for a long, long time. . .

Peter Poole · New User Joined: 07 Jan 2009 Posts: 50 Location: Scotland

Devil's Advocate mode='On'

I've seen a number of cases where a 'sequence number' within a DSN does not equate to GDG generation;

Customer statement processing where >150 million records need splitting out to allow parallel processing of the data within the overnight batch window; this went out to either 17 'sectional' files or 58 'sub-sectionalised' files. Allocation to file was based on branch sort code.

Extraction of test data - a production file was copied to test files, some of which were then aged to allow for 14 different test run dates, some of which had specific test cases created within the data. We used a very convoluted 2LQ which allowed us to group datasets to be loaded for each test date set-up process.

Not forgetting what the Adam Smith institue defines as "the Lego scenario"; sometimes a system is so convoluted that you can not practically take it apart to make changes, all you can do is add on more bricks around the edges. If the files are referenced and used extensively as flat files it may be impractical to convert them to GDGs, however desirable that might be.

Cheers.

dick scherrer · Posted: Wed Feb 25, 2009 12:27 am

Yup, which is why i mentioned the internal reader alternative.

This preserves the current naming/numbering scheme yet still allows using a better utility for large volumes

d

DKartiya · New User Joined: 30 Jan 2008 Posts: 26 Location: Chennai

Dick,

That right. We need to have flat files only. The reason being parallel processing.

I can submit thru internal reader. But that means i need to have a code in place to save the JCL submitted to internal reader for restart reasons
which will again be an overload.

Already i have couple of such JCLs submitted through internal reader in the same job. That the reason i didnt go for the option of changing the dsn names in JCLs.

Regards,
Karthi.