views:

756

answers:

5
+2  Q: 

IEBGENER Help

Ok, so I am having some trouble figuring out how to get IEBGENER working in the way that I want it to. I should preface all this by saying that I am running IEBGENER in a z/OS environment on an academic mainframe.

Now, I have three JCL procedures (PROC) inline to some COBOL code that I am working with, and I need to stick IEBGENER in as one of the first steps to put my PROC into a "permanent procedure library under [my] MVS ID" as well as put my COBOL source "into a permanent sequential data set under [my] MVS ID".

The instructor mentions to "remember to code the correct LRECL and BLKSIZE information for these data sets."

I am not very familiar with IEBGENER and haven't found anything that really explains to me how to do what I am trying to do.

Any "Big Iron" people able to help?

Thanks in advance.

+2  A: 

this is how to use IEBGENER (as mentioned, should be on the IBM docs site):

//COPY EXEC PGM=IEBGENER
//SYSUT1 DD DSN=MY.INPUT.FILE,DISP=SHR
//SYSUT2 DD DSN=MY.OUTPUT.FILE,DISP=NEW,SPACE=....
//SYSIN DD DUMMY

IEBGENER is "just a" copy program and about all it takes is an input file, output file, and a control file

I'm not sure what you think is "specific", isn't it just a matter of knowing which names to use?

edit: if what you want is defining your input inline, try this:

//SYSUT1 DD *
...
/*

or better yet, if your input contains JCL as well:

//SYSUT1 DD DATA,DELIMITER=XX
...
XX

Still not exceptional JCL, though.

Albert Visser
We are supposed to run IEBGENER from within the source file as a step; the same file that also has the source COBOL and the PROC steps. What was throwing me is that, in that case, I do not have an input file. Also, aren't the SYSUT1-2 use for I/O (not SYSIN/OUT)?
Enyalius
My bad, I should have noticed the double sysin
Albert Visser
+3  A: 

As mentioned, IEBGENER is a copy program. It takes an input on SYSUT1 and "generates" it to output dataset SYSUT2. In your instance, since you are copying 2 files, its easiest to have 2 GENER steps, each one producing one output dataset.

The only tricky part here is to get the output datasets in the right format. So, to gener into the proclib, assuming that it is not currently cataloged, your SYSUT2 would look something like this:

//SYSUT2  DD  DSN=&SYSUID.PROCLIB,
//            DISP=(NEW,CATLG,DELETE),
//            DCB=(RECFM=FB,LRECL=80,DSORG=PO)

The sequential dataset for the source output would look similar, but no DSORG subparameter on the DCB option. The option of PO there says to create a PDS as opposed to a QSAM file. On modern z/OS installations, BLKSIZE is not necessary to code, as the system will calculate the optimum size if you don't specify it.

Jeff Shattock
+2  A: 

Here is the link to IBM Z/OS manuals http://www-03.ibm.com/systems/z/os/zos/bkserv/v1r10books.html search for JCL and you will find the manuals for JCL. IEBGENER is a IBM supplied copy program to copy data from one dataset (file) to another dataset. You will have input file, output file and control file. LRECL and BLKSIZe are dataset parameters. If the input file and output file parameters do not match, data may not get copied correctly. I didn't understand your questions completely. Can you elaborate on what exactly you need to do with IEBGENER.

kishore
+1  A: 

It sounds as if your instructor is reminding you to give the correct LRECL and BLKSIZE to the "permanent procedure library" and "permanent sequential data set". Historically, such data sets are RECFM=FB, LRECL=80.

Because the records are fixed-format, the BLKSIZE must be an even multiple of 80. Very often, people use a value of 3120. The reasons for this are hidden in the mists of antiquity. I tend to use 27920, to get the most efficient space usage on a 3390 device.

Tony
A: 

A couple of minor points:

DCB=(RECFM=FB,LRECL=80,DSORG=PO)

DCB= is not required anymore, just code

RECFM=FB,LRECL=80,DSORG=PO

Also:

Because the records are fixed-format, the BLKSIZE must be an even multiple of 80. Very often, people use a value of 3120. The reasons for this are hidden in the mists of antiquity. I tend to use 27920, to get the most efficient space usage on a 3390 device.

It should not be necessary to specify a blocksize for a new DASD (disc) dataset. System determined blocksize will automatically give you the best blocksize (which would indeed be 27920 for a LRECL of 80 on a 3390)