How Do You Do That With RDi? Part 1: Copy A Source Member

I’m an RDi fan. I make no secret about that. Even so I occasionally find things that I need to do that just seem easier or faster to do with PDM in the green screen. I don’t really mind that. I nearly always have a green screen session sitting just next to my RDi workbench anyway. But when I can find a way to do a function as easily in RDi, I prefer to do that so that I don’t need to switch modes as much.

This tip is the first in a series on things that I find some people seem to prefer doing in PDM but that I’ve found some good ways to do with RDi. I’m hoping that perhaps you might learn one or two tips that will allow you to spend more time with RDi rather than switching back to the green screen as often. Please send in any suggestions you may have for things that you find yourself going back to PDM to do.

I have often been asked the easiest way to copy a source member with RDi. There are several ways to do this, but I have to admit that it is hard to compete with PDM option 3, which is both simple and fast. While I occasionally still copy members using PDM, these days I’m much more likely to use one of several options in RDi. The “easiest” way depends a lot on the particular situation.

Some people open the original source member and then do Save as. . . to copy it. I’m not wild about the Save as. . . interface, so I don’t use that option much. It’s especially cumbersome if the member you want to edit is the original one–you’re just making a backup copy before making your changes. So let’s look at some other options to do this in RDi.

To me, the most obvious solution is to use copy/paste in the Remote Systems view. You can do this a couple of ways. I typically right click on the original member, select Copy, then right click on the source file where I want the copy to go (the same source file or a different one) and select Paste. If the copy is in the same source file, RDi prompts me for a new member name. It will then prompt me for the Copy Source File (CPYSRCF) command that it plans to use to do the copy. Typically, I simply press Enter on the prompted command dialog. I wish there were a “silent” option for the copy/paste so that I could skip the prompted command. But aside from the extra Enter key for that dialog, that option works very well for me.

Copy/paste can also be done via a drag and drop: drag the member and drop it on to the target source file. When the member to be copied and the source file to receive it are fairly close to one another in the Remote Systems view, I prefer the drag/drop approach. Otherwise, I use copy/paste.

A common issue that some have with drag and drop is that they work from a filtered member list. Since the source file name doesn’t appear in the filter, finding the source file name to do the paste can be cumbersome. I sometimes create a separate filter containing only my source files in a library just for the purpose of pasting members. But it can be tough to scroll around to find that filter. Similarly, even if you work directly from a source file member list in Remote Systems, and it’s a very long list of members, there’s a similar issue making your way to the source file to do the paste. Fortunately, there are other ways.

Hopefully you have the free iSphere plugin installed, because it has a wealth of RDi goodies that I use every day. If you haven’t installed iSphere, take a look at one of my earlier tips to learn more about it.

One of those goodies is a Copy Members to. . . option in the context menu of source members. This is a much more PDM-like way to copy one or more members in RDi, and avoids the need to locate the source file in a Remote Systems list. Simply right click on a source mem-ber–or on multiple source members selected by holding the Ctrl key–and choose Copy Members to. . .. A dialog then pops up where you can key in the target source file and op-tionally change the names of the member(s). Press Enter and the member(s) are copied.

The only issue I’ve ever run into with using this option is that I get an error message when copying between source files of different record lengths, even if the target record length is longer. Aside from that, I find this option simple and fast, especially when I need to copy several members at once. This avoids the prompting that the built-in Copy/Paste option does for every copy source file command when copying multiples!

There’s one other option that I’ve also used to make copies of source members. If I’m simply making a backup copy of the member for safe-keeping while I’m editing the “real” member, then I typically put those backup copies into a specific source file just for that purpose, something like MYLIB/BACKUPSRC. I put all the backup source members in there regardless of type.

For that very specific situation, I like to create a user action that copies the selected member to MYLIB/BACKUPSRC. For more information on how to create user actions in RDi, see Dealing With Li-brary Lists In RSE/RDP. Once I create the user action, I can then simply right click on the member to be backed up, choose User Actions > Backup Source and know that the original member has been copied to BACKUPSRC in case I need to retrieve it.

To do this, the user action to back up a member might look something like the following. (The same could also be used to create a PDM user-defined option.)

CPYSRCF FROMFILE(&L/&F) TOFILE(PARTNER400/ITJTIPSRC)
        FROMMBR(&N) TOMBR(*FROMMBR)
        TEXT(*FROMMBR) SRCTYPE(*FROMMBR) SRCOPT(*SAME)

Those are the ways that I make copies of source members with RDi. Depending on the situation, I’d tend to use one of these techniques vs. another. But in most cases, I do prefer to have RDi copy my source members.

In future tips I’ll address how to do other tasks in RDi that sometimes seem easier to do in PDM. Don’t forget to let me know if there are specific things you’d like to know how to do in RDi.

Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.

RELATED STORIES

iSphere Plug-in Expands RSE/RDi Toolset

Dealing With Library Lists In RSE/RDP