View previous topic :: View next topic
|
Author |
Message |
prino
Senior Member
Joined: 07 Feb 2009 Posts: 1314 Location: Vilnius, Lithuania
|
|
|
|
I needed to rename 3,228 PDS members. The member names are of the format 'TnnnAA##' and 'nnn' had to be incremented by 3. Also, they reside in PDS'es with names xxxx.Txx1xy0 (xx=00/01/02, xy=01/02/03 etc), i.e. for nnn = 001-010, the members reside in xxxx.t001010 etc. My first thought was to use the LMMREN service, but sadly, LMMLIST cannot retrieve members in reverse order, so in the end I saved the memberlists to the ISPF list dataset, massaged that a little and sorted it in reverse order, and added a bit of REXX around:
Code: |
/* REXX */
call filler
do i = 1 to m.0
o = m.i
n = overlay(right(substr(o, 2, 3) + 3, 3, '0'), o, 2)
l = left(right(substr(o, 2, 3) - 1, 3, '0'), 2)'1'
l = 'T' || l || right(l + 9, 3, '0')
"ren xxxx."l"("o") xxxx."l"("n")"
if i // 50 = 1 then
say time('L') '"ren xxxx.'l'('o') xxxx.'l'('n')"'
end
exit
filler:
signal go
/*
T136TP99
- - - - - - - - - - - - - - - - - - -
T054DP25
*/
go:
p = 0
do i = sigl + 2 while left(sourceline(i), 2) \= '*/'
p = p + 1
m.p = strip(sourceline(i))
end
m.0 = p
return |
This worked flawlessly, but can anyone think of a more automated solution? Yes, I know that doing a LMMLIST and processing the members in reverse order is an option, but that requires the names of all PDS'es to be present, whereas now they are generated on-the fly. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
hello Robert,
probably I missed something ...
whY the need for the reverse order ?[/quote] |
|
Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009 Posts: 1314 Location: Vilnius, Lithuania
|
|
|
|
enrico-sorichetti wrote: |
hello Robert,
probably I missed something ...
whY the need for the reverse order ? |
Because you cannot rename T123xxxx to T126xxxx before renaming T126xxxx to T129xxxx. |
|
Back to top |
|
|
Pandora-Box
Global Moderator
Joined: 07 Sep 2006 Posts: 1592 Location: Andromeda Galaxy
|
|
|
|
I am not sure if its a wise solution but
why not
rename T123xxxx to @126xxxx and @126xxxx to T126xxxx? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
Quote: |
T123xxxx to T126xxxx before renaming T126xxxx to T129xxxx. |
crossing with Pandora suggestion ...
I did it with a double rename |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
I do not understand that
call Filler -> signal GO -> return
thing. Why not just Call GO? |
|
Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009 Posts: 1314 Location: Vilnius, Lithuania
|
|
|
|
Pedro wrote: |
I do not understand that
call Filler -> signal GO -> return
thing. Why not just Call GO? |
Because that would require the data to be moved away from where it's actually being used. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
|
|
|
|
IIRC, SIGNAL is equivalent to GO TO when used with a label or an expression that evaluates to a label. |
|
Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009 Posts: 1314 Location: Vilnius, Lithuania
|
|
|
|
Akatsukami wrote: |
IIRC, SIGNAL is equivalent to GO TO when used with a label or an expression that evaluates to a label. |
Have been sitting behind a screen for about ten hours now, so I may be tired, but what's the relevance of the fact that signal is for all intents and purposes equal to goto? |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
|
|
|
|
prino wrote: |
Akatsukami wrote: |
IIRC, SIGNAL is equivalent to GO TO when used with a label or an expression that evaluates to a label. |
Have been sitting behind a screen for about ten hours now, so I may be tired, but what's the relevance of the fact that signal is for all intents and purposes equal to goto? |
Our last posts were almost simultaneous, which obscured the fact that I was replying to Pedro's question. |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
My question was not about SIGNAL GO. My question was why use 'CALL FILLER' when you can just use 'CALL GO' instead? I do not understand the need for an indirect call. I am assuming I can learn something from Robert. |
|
Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009 Posts: 1314 Location: Vilnius, Lithuania
|
|
|
|
Pedro wrote: |
My question was not about SIGNAL GO. My question was why use 'CALL FILLER' when you can just use 'CALL GO' instead? I do not understand the need for an indirect call. I am assuming I can learn something from Robert. |
The key is in the loop after the label 'go',
Code: |
do i = sigl + 2 while left(sourceline(i), 2) \= '*/'
/* ^^^^ */ |
If I had used 'call filler' it would have been necessary to put the commented out list of member names directly after the call, and that makes the code far less readable, at least for me. Plus, this approach makes it (theoretically) possible to move the 'filler' routine into an externally callable routine, where using 'sigl' without the intermediate 'signal' instruction would be impossible. |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
I had to study your code a bit now that I understand what you are doing. Thanks for sharing |
|
Back to top |
|
|
Stefan
Active User
Joined: 12 Jan 2006 Posts: 110 Location: Germany
|
|
|
|
prino wrote: |
enrico-sorichetti wrote: |
hello Robert,
probably I missed something ...
whY the need for the reverse order ? |
Because you cannot rename T123xxxx to T126xxxx before renaming T126xxxx to T129xxxx. |
Instead of looping through the reverse member list you might rename the members twice.
In the above mentioned example this means that you first rename T123xxxx to R126xxxx and T126xxxx to R129xxxx, and in the second run you rename R126xxxx back to T126xxxx and R129xxxx back to T129xxxx. |
|
Back to top |
|
|
|