Page 1 of 1

IEBUPDTE utility

PostPosted: Tue May 15, 2012 12:30 pm
by kandrepavan
Hi All,


REQ: By using IEBUPDTE i need to change a particuler existing record with HELLO and that record is in sequence no 00080001.

CODE:
//STEP1 EXEC PGM=IEBUPDTE,PARM=MOD
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSNAME=TCHN635.JCL.IEUPDTE,DISP=(OLD,KEEP)
//SYSIN DD *
./ CHANGE NAME=MEMB1,LIST=ALL,UPDATE=INPLACE
./ NUMBER SEQ1=ALL,NEW1=10,INCR=5
(HELLO,sequence number 00080001)
/*
//

In The above code i am getting error at
(HELLO,sequence number 00080001)
as invalid operation.
How to give that data ? is there any syntax error?

Thanx and regards.

Re: iebupdte utility

PostPosted: Tue May 15, 2012 1:11 pm
by enrico-sorichetti
what would be wrong in looking at the manuals Yourself ? :evil:

starting from here
http://publibz.boulder.ibm.com/cgi-bin/ ... 0615142149
and proceeding to
http://publibz.boulder.ibm.com/cgi-bin/ ... 0615142149

for example ... :ugeek:

Re: iebupdte utility

PostPosted: Tue May 15, 2012 1:30 pm
by BillyBoyo
I think that you have been at the manual, but misunderstood.

The bit in parentheses/brackets is not a control card, it is your data with a sequence number that should be in the same relative location to match the input record. So, typically:

SOME DATA YOU WANT TO REPLACE, then spaces up to col 71, then SEQNOTOREPLACE

Re: iebupdte utility

PostPosted: Tue May 15, 2012 5:45 pm
by steve-myers
Enrico is correct: read the fine manual, or as we often say here, RTFM. I had never seen the ./ NUMBER statement used as you are using it, but after consulting the manual myself I think it is correct; you are replacing all the sequence numbers. The ./ NUMBER statement is usually used to insert new lines into a dataset or PDS member, which you cannot do with UPDATE=INPLACE. The manual states this, but not as clearly as one would like. I grant that you can use ./ NUMBER INSERT=YES coupled with ./ DELETE to replace lines, but I doubt that IEBUPDTE would accept this when using UPDATE=INPLACE

Billyboyo is incorrect. When you replace a record you specify the changes in columns 1 through 72, and the sequence number of the record you are replacing in columns 73 through 80. This is hard to do when you are building the job using ISPF, but it can be done. We cannot do this using a code block in this forum because this forum does not allow 80 byte wide lines.

Re: iebupdte utility

PostPosted: Tue May 15, 2012 6:09 pm
by BillyBoyo
I wondered what was wrong until I noticed the "71" :-)

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 :-)

Re: iebupdte utility

PostPosted: Tue May 15, 2012 6:43 pm
by steve-myers
BillyBoyo wrote:...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 :-)
An interesting idea, though "filling" the PDS with members to update in place night prove to be frustrating. I always found the idea of UPDATE=INPLACE potentially useful, but because you cannot add data, so limiting as to be nearly useless. In 40+ years, when I did a lot of using ./ NUMBER INSERT=YES, I never actually tried to use UPDATE=INPLACE.

Re: iebupdte utility

PostPosted: Tue May 15, 2012 7:13 pm
by BillyBoyo
I was thinking it was going to be easy :-)

I was thinking If I have one member which occupies just over half the PDS, with no secondary extents, that would satisfy the requirement to know whether the update-in-place is actually in-place. If it blows-up, it is not in-place. If it doesn't, then I need to check :-)

If I get a chance to try it, I'll let you know.

Re: iebupdte utility

PostPosted: Wed May 16, 2012 12:31 am
by steve-myers
I did something more challenging. I created a 2 track 1 member PDS. No secondary. I then constructed an in place update to change the last logical record in the first real physical record of the member and the first logical record of the second physical record of the member. Worked like a charm . This is the before image.
  ** COUNT 002D000703006D10   TTR 00000003 **
...
6CC0 27840  40404040 40404040  40D3E3D9 404040F1  *         LTR   1*
6CD0 27856  F56BF1F5 40404040  40404040 40404040  *5,15            *
6CE0 27872  404040E3 C5E2E340  E3C8C540 D9C5E3E4  *   TEST THE RETU*
6CF0 27888  D9D540C3 D6C4C540  40404040 40404040  *RN CODE         *
6D00 27904  40404040 40404040  F3F4F9F0 F0F0F0F0  *        34900000*

     **** TRACK 000001       1 ****

  ** COUNT 002D000801006D10   TTR 00000101 **

0000     0  40404040 40404040  40D1D5E9 404040E2  *         JNZ   S*
0010    16  C3D7F0F4 F0F04040  40404040 40404040  *CP0400          *
0020    32  404040C5 E7C9E340  C9C640C4 C440D5D6  *   EXIT IF DD NO*
0030    48  E340D7D9 C5E2C5D5  E3404040 40404040  *T PRESENT       *
0040    64  40404040 40404040  F3F5F0F0 F0F0F0F0  *        35000000*
The second physical record had to start on the 2nd physical track because it would not fit on the first physical track because the directory occupied space that would otherwise be used by the record.