I wondered what was wrong until I noticed the "71"
![Smile :-)](https://www.ibmmainframeforum.com/images/smilies/icon_e_smile.gif)
The point I was trying to make was that although TS had copied the example from the manual, the manual does not intend that the data be represented in that specific way shown. It is just data, your data, there are no "rules" for it except the sequence number, 71, whoops, backspace, 73 to 80.
The Fine Manual wrote:10.6.4 Example 4: Update a Library Member
In this example, a member (MODMEMB) is updated within the space it actually occupies. Two existing logical records are replaced, and the entire member is renumbered.
//UPDATE JOB ...
//STEP1 EXEC PGM=IEBUPDTE,PARM=MOD
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD DSNAME=PDS,UNIT=disk,DISP=(OLD,KEEP),
// VOLUME=SER=111112
//SYSIN DD *
./ CHANGE NAME=MODMEMB,LIST=ALL,UPDATE=INPLACE
./ NUMBER SEQ1=ALL,NEW1=10,INCR=5
(Data statement 1, sequence number 00000020)
(Data statement 2, sequence number 00000035)
/*
The control statements are as follows:
SYSUT1 DD defines the partitioned data set that is updated in place. (Note that the member name need not be specified in the DD statement.)
SYSIN DD defines the control data set, which follows in the input stream.
The CHANGE function statement indicates the name of the member to be updated (MODMEMB) and specifies the UPDATE=INPLACE operation. The entire member is listed in the message data set. Note that, as renumbering is being done, and since UPDATE=INPLACE was specified, the listing would have been provided even if the LIST=ALL parameter had not been specified. See the LIST parameter for more information.
The NUMBER detail statement indicates that the entire member is to be renumbered, and specifies the first sequence number to be assigned and the increment value (5) for successive sequence numbers.
The data statements replace existing logical records having sequence numbers of 20 and 35.
An interesting point is the "updated within the space it actually occupies". I didn't know that a PDS member can be updated literally where it exists, rather than through the directory entry pointing to a new place where the new life of the member continues. I wonder if I should "fill" a PDS and then try to use IEBUPDTE to change something in place when there is no room for extension
![Smile :-)](https://www.ibmmainframeforum.com/images/smilies/icon_e_smile.gif)