Create Member



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Re: Create Member

Postby Gustav » Thu May 07, 2020 11:49 am

Dear steve-myers,

thanks a lot for your detailed explanation!
Gustav
 
Posts: 5
Joined: Wed May 06, 2020 1:50 pm
Has thanked: 4 times
Been thanked: 0 time

Re: Re: Create Member

 

Re: Create Member

Postby sergeyken » Fri May 08, 2020 7:18 pm

steve-myers wrote:I created this JCL example for you. Except for the use of &SYSUID in the data set name it would have worked 52 years ago!
//A       EXEC PGM=IEFBR14
//GUSTAV   DD  DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0),
//             DSN=&SYSUID..GUSTAV.DATA(GUSTAV)


I would say this part is misleading, especially for beginners. For some reason 99.99% of beginners are sure that the member GUSTAV to be deleted from the library &SYSUID..GUSTAV.DATA here. But actually the whole dataset &SYSUID..GUSTAV.DATA is deleted; while the part '(GUSTAV)' plays no role in this step, at all.

To be more accurate I would change it as follows
//A       EXEC PGM=IEFBR14
//GUSTAV   DD  DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0),
//             DSN=&SYSUID..GUSTAV.DATA
//B       EXEC PGM=IEFBR14
//GUSTAV   DD  DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(TRK,(1,1,1)),
//             DCB=(RECFM=FB,LRECL=80),
//             DSN=*.A.GUSTAV
//C       EXEC PGM=IEBGENER
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  DUMMY
//SYSUT2   DD  DISP=OLD,
//             DSN=&SYSUID..GUSTAV.DATA(GUSTAV)
//SYSUT1   DD  *
THIS IS MEMBER GUSTAV

Besides of this I recommend to get used from the first steps in mainframe, and to do it AUTOMATICALLY while coding: always use PDSE datasets instead of simple PDS, to avoid more headache in the future
. . . . . . .
//B       EXEC PGM=IEFBR14
//GUSTAV   DD  DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(TRK,(ppp,sss,ddd)),
//             DCB=(RECFM=FB,LRECL=80),DSNTYPE=LIBRARY,  <== PDSE instead of PDS!
//             DSN=*.A.GUSTAV
. . . . . . . . . . . .
 
sergeyken
 
Posts: 86
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 2 times
Been thanked: 9 times

Re: Create Member

Postby steve-myers » Sat May 09, 2020 4:01 am

Sergeyken - I agree the DD statement in the first step is misleading. I should have said the statement deletes the entire data set; it does not delete just the member. The member is there for later use. Truth be told, when I first prepared the JCL I wasn't sure the member name would be propagated to the third step through the *.DD reference. Yes, I really ran the JCL.

I am not a big fan of PDSE. I only use it where its data management benefits outweigh the serious performance and space utilization penalties PDSE enacts. Yes, PDSE always uses more space than PDS, at least until you start adding, deleting and replacing members. Don't forget PDSE is based on HFS, which has been entirely replaced with zFS because of HFS performance.

To illustrate the space utilization and performance issues I prepared and ran this JCL.
//A       EXEC PGM=IEFBR14
//PDS      DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
//             DSN=&SYSUID..PDSETEST.PDS
//PDSE     DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
//             DSN=&SYSUID..PDSETEST.PDSE
//EXECSUM  DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
//             DSN=&SYSUID..PDSETEST.EXECSUM
//B       EXEC PGM=IEBCOPY
//SYSPRINT DD  SYSOUT=*
//INPUT    DD  DISP=SHR,DSN=&SYSUID..ASM
//PDS      DD  DISP=(,CATLG),UNIT=SYSDA,SPACE=(TRK,(180,36,35),RLSE),
//             DSN=*.A.PDS
//PDSE     DD  DISP=(,CATLG),UNIT=SYSDA,SPACE=(TRK,(300,60,1),RLSE),
//             DSNTYPE=LIBRARY,DSN=*.A.PDSE
//SYSIN    DD  *
 C I=INPUT,O=PDS
 C I=INPUT,O=PDSE
//C       EXEC PGM=IKJEFT01
//STEPLIB  DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  *
DSSTAT (PDSETEST.PDS PDSETEST.PDSE) DIRSTAT
//D       EXEC PGM=EXECSUM,PARM=IEBPTPCH
//STEPLIB  DD  DISP=(SHR,PASS),DSN=*.C.STEPLIB
//EXECSUM  DD  DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,(1,1)),
//             DSN=*.A.EXECSUM
//SYSPRINT DD  DUMMY
//SYSUT1   DD  DISP=OLD,DSN=*.A.PDS
//SYSUT2   DD  DUMMY
//SYSIN    DD  *
 PRINT TYPORG=PO,MAXFLDS=1
 RECORD FIELD=(80,1,,21)
//E       EXEC PGM=EXECSUM,PARM=IEBPTPCH
//STEPLIB  DD  DISP=(SHR,PASS),DSN=*.C.STEPLIB
//EXECSUM  DD  DISP=(MOD,PASS),DSN=*.A.EXECSUM
//SYSPRINT DD  DUMMY
//SYSUT1   DD  DISP=OLD,DSN=*.A.PDSE
//SYSUT2   DD  DUMMY
//SYSIN    DD  *
 PRINT TYPORG=PO,MAXFLDS=1
 RECORD FIELD=(80,1,,21)
//F       EXEC PGM=IEBGENER
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=(OLD,CATLG),DSN=*.A.EXECSUM
//SYSUT2   DD  SYSOUT=*
//SYSIN    DD  DUMMY
 

I wrote the DSSTAT command almost 30 years ago to create more usable output than IBM's LISTDS command. The DIRSTAT keyword gathers PDS directory statistics. The output from the step is -
DSSTAT (PDSETEST.PDS PDSETEST.PDSE) DIRSTAT
XXXXXX.PDSETEST.PDS
--UNIT---DEVICE---VOLUME--RECFM--LRECL--BLKSIZE--DSORG--ALLOCATED---USED
  0A74   3390     XXXX24  FB        80   27920    PO        143      143
--ALLOCATED--LAST USED---EXPIRES--ALTERED-STORCLAS-DATACLAS-MGMTCLAS    
   05/08/20  05/08/20     ------    YES   USER
DIRECTORY BLOCKS:    35 ALLOCATED,    34 USED
XXXXXX.PDSETEST.PDSE
--UNIT---DEVICE---VOLUME--RECFM--LRECL--BLKSIZE--DSORG--ALLOCATED---USED
  0A73   3390     XXXX23  FB        80   32720    POE       154        0
--ALLOCATED--LAST USED---EXPIRES--ALTERED-STORCLAS-DATACLAS-MGMTCLAS    
   05/08/20  05/08/20     ------    YES   USER
DIRECTORY BLOCKS:    34 ALLOCATED,    34 USED
READY
The EXECSUM program gathers execution statistics, including EXCP counts and CPU time. Its output is -
EXECSUM (V1L1 11/23/10 15.58)                                                                      2020/05/08 PAGE     1
EXECSUM IEBPTPCH
IEBPTPCH  XXXXXXJ D   STARTED AT 16:53:39 ENDED AT 16:53:39, 0.49 CPU, 0.66 ELAPSED, RC = 0
DDNAME   ADDRESS  EXCPS VOLUME  DATA SET
STEPLIB    0A38       2 XXXX08 XXXXXX.LOAD
EXECSUM    0A77       0 XXXX27 XXXXXX.PDSETEST.EXECSUM
SYSPRINT   DUMY       0        NULLFILE
SYSUT1     0A74     619 XXXX24 XXXXXX.PDSETEST.PDS
SYSUT2     DUMY       0        NULLFILE
SYSIN      DUMY       0        XXXXXX.XXXXXXJ.JOB11589.D0000103.?
EXECSUM (V1L1 11/23/10 15.58)                                                                      2020/05/08 PAGE     1
EXECSUM IEBPTPCH
IEBPTPCH  XXXXXXJ E   STARTED AT 16:53:39 ENDED AT 16:53:41, 1.69 CPU, 1.81 ELAPSED, RC = 0
DDNAME   ADDRESS  EXCPS VOLUME  DATA SET
STEPLIB    0A38       2 XXXX08 XXXXXX.LOAD
EXECSUM    0A77       0 XXXX27 XXXXXX.PDSETEST.EXECSUM
SYSPRINT   DUMY       0        NULLFILE
SYSUT1     0A73    2238 XXXX23 XXXXXX.PDSETEST.PDSE
SYSUT2     DUMY       0        NULLFILE
SYSIN      DUMY       0        XXXXXX.XXXXXXJ.JOB11589.D0000104.?

I grant the CPU and elapsed time statistics are basically trivial for this relatively small data set, but they add up for larger data sets. Note the difference in EXCP counts between the PDS and PDSE versions of the data set.
steve-myers
Global moderator
 
Posts: 2066
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 228 times

Re: Create Member

Postby sergeyken » Sat May 09, 2020 6:24 am

steve-myers wrote:I am not a big fan of PDSE. I only use it where its data management benefits outweigh the serious performance and space utilization penalties PDSE enacts. Yes, PDSE always uses more space than PDS, at least until you start adding, deleting and replacing members. Don't forget PDSE is based on HFS, which has been entirely replaced with zFS because of HFS performance.

This is all true, but all those disadvantages are overweighted 100500 times by the PDSE benefits.

1) increase in size of PDSE is miserable compared to modern size of available storage devices
2) in general, the total size of all used PDS+PDSE (load modules, source codes, control statements, REXX/CLIST/SQL scripts, etc.etc.) is miserable compared to the total amount of data needed to be stored, and handled
3) the performance degradation when using PDSE is really non-important based on the 99.99% of all types of activity they are involved into; that is: code editing, program compilation, module binding, etc.
4) the total CPU usage spent on any handling of PDS+PDSE is typically below 1% of the whole data processing performed with huge datasets, and databases by using standard utilities, proprietary applications, and DBMS

So, any problem caused by using PDSE is merely a sort of a fairy tale.

P.S.
In the same way one could recommend to never use neither DB2, nor COBOL, nor REXX, because of “ineffective use of storage, and CPU time”
sergeyken
 
Posts: 86
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 2 times
Been thanked: 9 times

Previous

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post