Dynamic allocation of files? 6

[crackerjack109]

On an IBM Mainframe I need to be able to read a single input file and create an unknown number of output files based on the data in the input file. My problem is that the file names of the output files need to be based on the data from the input file (i.e. if the input file contains ABC756 in a specific input field I need to create a file called ABC756.xxxxx.nnnnnn. The input and output files will both be used on an IBM Mainframe with (I think) MVS OS.

I have done this quite easily on a Unisys mainframe but can't seem to discover how to do it on the IBM. Has anyone done anything like this before.

I appreciate any help you can give.

Thanks

Crackerjack

 

[etom]

The only way I have seen it done requires you to write an assembler routine or find one already written that you can call from your Cobol program. There may be some inventive way to do this and maybe someone out there has an idea.

etom

 

[WMK]

If you have a *CURRENT* IBM compiler, it is a "piece of cake" - using "putenv" and dynamic file allocation.

See:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/3.4.2.4

and

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/4.2.3.1

amd

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/4.2.3

Bill Klein

 

[etom]

Interesting reading WMK. I will have to try this myself.

etom

 

[crackerjack109]

Thanks ETOM and WMK. I discovered we have an assembler routine available here that supposedly works (Ican't find anybody who has used it), so I will give this a try first. However I'm very interested in WMK's solution. I will check it out also. It sounds very interesting and perhaps more flexible than our in-house solution. Thanks again to both of you for your help.

 

[MarcLodge]

Crackerjack,
Just as a further potential method, I believe that it may be possible to do this using ISPF dialog manager services such as have the cobol call the LMINIT service. I hasten to add that I've not tried this (and cannot find my manuals on Dialog Manager) but believe this may be possible.
Marc

 

[crackerjack109]

Thanks for everyones help and guidance. I ended us using WMK's suggestions. I initially tried using the inhouse assembler routines but it was real messy. I then looked at the method WMK suggested and did a little research on the internet, coming up with this link:

http://www.naspa.com/PDF/2001/1201 PDF/T0112005.pdf

After a little experimenting, I was able to convert the example from creating dynamically named input files to output files. It works like a charm. The best part of it is that it only adds a few lines to my code, while the assembler option was going to add lots.

The only problem I have run into, and I haven't had time to think about a possible solution, is that in my JCL i normally have a delete step just prior to running a production step. This step deletes any files that are named the same as what the next step will be creating. Since I don't know in advance what the names of the files will be (because they are based on data contained in the input file) I don't know the names of the files to delete.

Anyone have any ideas on this?

Again thanks for the help.

CrackerJack

 

[MarcLodge]

Crackerjack,
A number of possible ways around this occur.....
[ul][li]From within your Cobol program, once you have determined the names of the files, submit JCL through the internal reader to delete the files.[/li]
[li]Using the dynamic allocation described in your link, is it possible to delete the files, similar to NEW,DELETE,DELETE?[/li]
[li]Using the dynamic allocation described in your link could you overwrite the file if it existed or create it if it didn't[/li][/ul]

These are all just theoreticals that occur to me off the top of my head with just a small amount of thought. Treat therefore with caution! But I hope they may help a bit.
Marc

 

[slade]

Hi CJ,

I'm not sure, but I don't think you can dynamically delete the files in the same step that you find them.

Here's a thought to add to Mark's.

You could write another pgm using similar logic to find the file names, then create IDCAMS cntl cards to delete them and execute IDCAMS in the next step using the cntl cards as input. Those that don't exist will be bypassed with an IDCAMS error. The others will be deleted.

Your jobsteps will look something like this:

//S1 EXEC PGM=BLDCCDS
//S2 EXEC PGM=IDCAMS
//S3 EXEC PGM=DELFILES

Steps 1 and 3, of course, will use the same IP file.

Regards, Jack.

 

[WMK]

If you want to "empty" a dataset that might already exist, how about (after you use PUTENV), doing an:

Open Output
Close
then do your existing logic.

That will "create" the file if it doesn't already exist and leave it "empty" and will empty it if it does exist

Bill Klein

 

[MarcLodge]

All,
Found a link

http://www.naspa.com/PDF/2000/0100 TS PDFs/T0001006.pdf

that describes how to call Idcams from within a Cobol program and gives a sample of code to do it! Now I find that pretty neat as it means you wouldn't have to submit extra jobs or have preceding steps or programs as you could do it all in-flight.

Not sure if it works, but assume it does, and am going to try the code out as soon as I can!

Marc

 

[slade]

Hi Marc,

I have a source re. batch IDCAMS and forgot all about it, until your post. Your souce is much superior to mine, though. Thanx for sharing.

Catch a star, Jack.

 

[crackerjack109]

Thanks for everybodys help. I am studying the article suggested by MarcLodge and hope to get it implemented in the next couple of days. This project was suppose to just take a day or two - ha ha - and I still need to keep my main projects going. Again I appreciate everybodys help - you're a great group.

 

[schristi69]

How do you pss the LRECL, BLKSIZE and RECFM to PUTENV? These variables are not in the variable list. So how do you tell it the size fo file you want?

 

[WMK]

You put all that in the environment variable. See:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/4.2.3.1

Bill Klein

 

[schristi69]

As I stated, these variables are not in the variable list for the DSN option of the referenced document and will not compile properly if they are added. I have managed to get the process to work using only the variables in the list. The file seems to default to FB due to the DSN option and LRECL seems to default to the length of the output record you write. Blksize also seems to default to 0. Thanks

 

[WMK]

Sorry, it gets LRECL and BLOCKSIZE from the

RECORD CONTAINS
and
BLOCK CONTAINS

clauses in the FD

If you want an "odd" RECFM, codee the

Record Format

clause in the FD.


Bill Klein

 

[schristi69]

AHHHHHH! Now I see. Great! Thanks!!

Scott Christian