IBM Mainframe Forum

Heelo,

we use a home made programm to allocate a sequential dataset :



Here is an example in the JCL



I would like to know what is the différence with the ibm program : IEFBR14 which allow te create a sequential dataset too.

IEFBR14 does nothing in the program.

Your little program effectively writes a DASD end of data to the data set. This is entirely unnecessary with an SMS managed data set; allocation already does this, but it is moderately useful with non-SMS managed sequential data sets as it will prevent ordinary programs from reading any previous contents of the data set.

You are missing a point here ....
it is JCl ( as the set of system functions that process the JCL statements ) that does it

when processing the DDs JCL does not care about the program that is executed later on

a bit of history ...

once upon a time when allocating a PS dataset only CATALOG and VTOC were <updated>
so the data extent was left untouched with nasty consequences ( like processing later on leftover data )

with SMS now when allocating a PS dataset data management writes an end of file leaving things in a clean state

probably Your program was a circumvention for the above problem

OK,

thank's for your help.

It is a very old program we are using actually to allocate dataset.
But i wonder if it is useful yet.

By reading your answers, il anderstand we don't have to continue using this program because of SMS.

By reading your answers, il anderstand we don't have to continue using this program because of SMS.

remember ... the EOF write works only for SMS managed datasets

samb01 wrote:... It is a very old program we are using actually to allocate dataset. ...

Your little program does not actually allocate the data set; your JCL actually allocates the data set; Mr. Sorichetti and I have described the effect of what your little program actually does. Nevertheless, your little program has some actual problems.

• It can actually ABEND. For example,
  Select all

  //INIT    EXEC PGM=Q0009         
  //OUT      DD  DISP=(,CATLG,KEEP),
  //             DSN=FILE.DATASET, 
  //             SPACE=(TRK,(1,1)),
  //             UNIT=SYSDA
  will ABEND because the data set has no DCB attributes.
• This is a minor problem; it has no effect in the real world because end of task processing does the equivalent. The program does not free the buffer pool allocated when it opened the data set. The reason is something appreciated (or, mostly, remembered) by us dinosaurs. One of the truly odd capabilities of OS/360 data management is the ability for several DCBs to share a buffer pool. Since another DCB might be using the buffers, CLOSE can't free them; your program must free them. IBM provides a macro, FREEPOOL, that actually frees the buffer pool. Now life isn't perfect. Until fairly recently FREEPOOL didn't bother to test if there was a buffer pool to free, and it would ABEND, usually while trying to calculate the size of the non existent buffer pool, so us dinosaurs usually add two lines of code before the FREEPOOL macro to see if there is a buffer pool to free.