>Why do you want a VB data set with all the records the same length? You've answered a different question.
The reason for asking was not "that's an impossible scenario, no-one in their right mind would ever want to do that", it was an attempt to elicit what the requirement at hand is. The "same length" is a little pokey-bit for Paul. With Paul, there often seems to be a particular elephant around somewhere. And, although there are two reasons given for the use of IEBGENER (accident (should have been IDCAMS REPRO) and IEBGENER's potential to edit records (which exists, but which doesn't exist for REPRO)), even before the second reason appeared, I thought I could hear faint trumpeting and catch a whiff of peanuts. Now, to copy FB (say LRECL 80, for fun) to VB (LRECL 84, needs those extra four bytes (even though only two of them are directly relevant) to tell everything there are 80 bytes of data) you could use REPRO. You could also typo to VB using REPRO, and all will continue happily until something fails down the line with an "oh, my goodness, how could that possibly have happened, I got RC=0". Or you could use IEBGENER. Where you could also typo to VB. To put it another way, all things being equal (or equivalently equal, the data being the same length) you can just toss in IDCAMS REPRO or IEBGENER and hope that what you want them to do (in this particular case) is what you've asked them to do, because you are getting RC=0 whether the output RECFM happens at the time to contain F or V. Remembering that you yourself may have to look at this step some time in the future, as may others. Blind waste of time. Or, TAAA-RRRAAHHH-TO-WOOOH!!, ground shakes and you manage to croak "if that's the way your breath smells, it's fine with me. Sir. Your Lordship. You Lordship, Sir". DFSORT. Not really a typo, just using the wrong JCL and failing to use any control cards (the stuff REPRO needs), yet the result is the same (RC=0, file looks OK). How did that happen? Consult the manual. Unclear, but not precluded. Yet. It's probably DFSORT wot dun it all wrong. Yep, I'm sure of it. Certain. Now, how to prove I'm right! Instead, DFSORT would be my first choice for the task (and second through 20th as well). OPTION COPY OUTFIL FTOV If you wanted to exclude trailing blanks (or something else) there's VLTRIM. OPTION COPY OUTFIL FTOV,VLTRIM=C' ' Drops trailing blanks. There is extensive further editing available (much more extensive than provided by IEBGENER). You can go "the other way" (although in that case you need a BUILD/OUTREC on the OUTFIL as well) and also use VLFILL to pad with whatever byte-value you want. I'm not saying it is foolproof, but the intent is clearer and the potential enormously expanded. By the way, Charles, if you want to MOD, why convert to V in one step and MOD to a V in another, when it can be done in one step, with one pass of the data? (or when, just for fun, you could MOD it as F anyway... and then process as U. No, that's not a real question either). And, if testing a program which requires variable-length records would you really use records which are all the same length but which just happen to be V/VB? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
