Edit version and modification level are used as you see fit. In the old days before source comparison and source maint (e.g. SCLM & Endeavour), we would use these fields to identify changes and levels. VERSION sets version which is manually maintained. MODLVL automatically increments but you may override it using the LEVEL command. LEVEL is inserted into the line numbering..
As for PDS directory entries, each member has a user area. It is not used by PDS but it ensures it is propagated properly (e.g. IEBCOPY). It can be anything you want as long as it fits into this area. The ISPF group uses this area for ISPF statistics. The linkage editor group uses this area this for loading information (amode, rmode, ac, rent, reuse, ...). PDS does not require any specific information in the user area so you could put any information you wanted in this area. The downside is that for load modules, the loader expects specific information in this area to load the module. I don't know what would happen if ISPF found garbage in this area but I suspect it would run with STATS OFF. ISPF stats and load module attributes are the most supported information in the user area. Specialized programs could use and maintain user data as they feel but if they interact with ISPF, users will feel it should contain ISPF supported information that does not require the product to display this information. ISPF chose not support EDIT for RECFM=U. Browse (load module and non-load module) does support it so it is possible to support it for edit. Since RECFM=U is most often load modules, why take the risk of someone damaging a load module. Why allow ISPF stat the ability to overlay load module attributes? I think that ISPF does not support RECFM=VBS or FBS for edit either (not positive about this). RECFM=U is undefined record format. It simply means that some attributes may be ignored (e.g. lrecl and blocksize). We see it mostly as load libraries. You can't specifically say it's a load module. The member user area may contain what looks like load module attributes but it's an assumption that it is valid load module attributes. I don't recommend mixing data members and load modules in a single PDS but you can do it today without a problem. Just don't try loading a data member. With RECFM=U, the LRECL is usually ignored. Most people omit LRECL which is why you usually see 0. It is not an indication of a load model. The linkage editor and loader is a good example. The load library may have an LRECL but it does not have meaning. There are some products that use RECFM=U and ignore both LRECL and BLKSIZE. In these case, they use track size as their buffer size and use physical records instead of logical records (recfm=fb / recfm=vb). In z/OS 2.1 REXX, it will most likely use physical records on the disk as long as they don't exceed REXX variable size. As for the user data, it will most likely be 0's. I think it will work in a similar manner as IEBGENER RECFM=U support. Jon Perryman. >________________________________ > From: Thomas Berg <[email protected]> > > >> -----Original Message----- >> Behalf Of [email protected] >> >> > It's certainly possible to have DSORG=PS,RECFM=U data set that does >> > not contain load modules. I've used them. I believe it's also >> > possible to have DSORG=PO,DSNTYPE=PDS,RECFM=U with content other than >> > load modules, but ISPF refuses to recognize this fact. I don't know >> > whether DSORG=PO,DSNTYPE=LIBRARY,RECFM=U can have content other than >> > program objects. >> Yes, it can. I just ran my IEBDG job that allocated a PDS to allocate a >> PDSE instead, and it gets filled with text data by iebdg without a >> problem. ISPF does NOT support editing recfm=u data sets, which is >> clearly indicated in the ISPF books. ISPF statistics are *only* >> supported for fixed or variable record format. >> >> This is the root of my first question: Application developers apparently >> call 'ISPF statistics' what they see for recfm=u data sets (and most of >> them have never encountered a recfm=u data set that was NOT a load >> library). I believe the data shown by ISPF are stored in the directory >> entry itself mapped by IHAPDS owned by DFP. Unfortunately ISPF itself >> seems to call these directory data 'ISPF statistics', at least in the >> ISPF user guide(s). >> >> ISPF just *assumes* that any RECFM=U data set is a load module, when in >> fact it isn't. As far as I can see 'real' load libraries always have an >> lrecl of zero. Which ISPF does not test. When I use a RECFM=U data set >> in ISPF (with LRECL other than zero), I get 'browse substituted' on any >> edit attempt. >> >> > It has been announced that in 2.1 Rexx EXECIO will support RECFM=U. >> > When we get 2.1 I'll need to experiment to discover the restrictions. >> I believe what that means is that execio will make sure that the data in >> the directory entry IHAPDS are filled in correctly for a recfm=u data >> set, too. I do NOT believe that mixing of load modules and data members >> will be possible. >> >> >ISPF might use this information to format the headers of the member >> >list. >> No. For fixed and variable length records in a PO data set the user >> field of the directory entry IHAPDS points to the ISPF statistics, which >> can be 30 or 40 byte long. They are mapped by ISPDSTAT and owned by >> ISPF. As I said before, ISPF clearly states that it does not maintain >> PDF statistics for recfm=u data sets. I also found some references to >> 'non-pdf form of statistics'. I'd dearly like to know who writes those >> (well, other than a dedicated program using STOW to put *something* into >> the user field). >> >> Does anyone have an answer for my second question: How does the version >> in the pdf statistics get incremented (other than by some form of the >> VERSION command)? > >By any (?) ISPF program (e g ISPF SERVICES etc). Do any other (IBM) "utility" >update it ? I don't know. >E g rexx EXECIO do not update the version or any other field in the >statistics. >Presumable not any DFS utility either. > > > >Best Regards >Thomas Berg >___________________________________________________________________ >Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
