What’s new (and old) with RTC-RDz integration

I was playing with Rational Developer for System z (RDz) today and thought this might be a good time to give you a brief overview of the integration between RTC and RDz, tell you about a new feature offered with RTC 4.0 and RDz 8.5,  and share some gotchas that tripped me up some along the way. I will not even begin to try to tell you about all of the features and benefits of using RDz as your individual development environment for mainframe applications, both because there are so many and because I don’t begin to claim to know them all. Check out this overview of the Rational Developer for System z family for an understanding of all that RDz has to offer.

RDz supports both local projects, where your source code is located on your workstation, and remote projects, where your source code is located on the host. Since RTC came about, you have been able to share your RDz local projects in the SCM; they are just eclipse projects with a specific RDz local project nature. With V2.0.0.1 of RTC, you could also share your remote projects in the SCM.  This was done by establishing a local copy of the remote source files under the covers, keeping the two copies in sync, and using the local copies to interact with RTC. This needed to be done because RTC does not yet provide first class support for remote projects, RDz or otherwise. Until this support comes along, the recommended course of action when using RTC and RDz in combination is to use RDz local projects.  As such, that is what we are focusing on today. If you’d like to take a look at the RDz remote project support in RTC, you can visit the help here.

As I said above, you don’t need to do anything special to share your RDz local project in the RTC SCM. However, in order to take full advantage of some of the RDz functionality, such as Show Dependencies, Open Copy Member, and Local Syntax Check, you need to use a property group to allow RDz to resolve the location of the loaded dependencies referenced by your source. Starting in an RDz 8.0.3 fixpack, a wizard is provided that allows you to automatically generate this property group. The correct SYSLIB is constructed by analyzing the system definitions utilized by your zComponent projects.  A nice video demonstration of this feature and the integration between these products can be seen here.

But what about those system copybooks that aren’t under SCM control? And what if I don’t want to load all of my dependent copybooks to my workstation? New in RDz 8.5 and RTC 4.0, when you generate your property group, you have the option to specify a remote connection, and a remote SYSLIB will be generated to resolve dependencies on files residing on the selected system. In addition, if you specify a build definition (used previously only to resolve any substitution variables found in the system definitions), the team build data sets (located by the resource prefix in the build definition) will also be included in the remote SYSLIB. This means that any copybooks loaded to the host during a prior build will be available to resolve dependencies, even if they are not loaded to your workstation. Cool!

Now, here are a few questions I had while playing with these features that you may have as well…

Q: I generated a property group for my zComponent project, and now I need to load another zComponent project that contains some of the dependent copybooks. Will my property group by chance magically pick these up?

A: Nope. You need to regenerate the property group or manually update the one you already have to include the new local copybook folder.

Q: How does all this new generated property group function relate to that “Use for Syntax Check” box I’ve seen in my Translators (only appears when RTC and RDz are shell sharing)?

A: It doesn’t. That option is for our remote RDz project support, to allow us to show dependencies, perform syntax checks, etc.

Q: I generated a property group and I’m happy to see that my remote copybook is opening right up when I do a Show Copybook from my main program. But why are all these warnings about not being able to resolve my copybooks still showing in the editor?

A: You may need to close and re-open your file after generating the property group. I think I also had to do a refresh on the file once, but I’m not going to swear by it…

Q: I generated a property group and specified a remote connection, and now Local Syntax Check and Show Dependencies are grayed out. What did I do wrong??

A: Nothing. RDz is explicitly filtering out those actions when you specify remote libraries in your property group. Recall that you can always use the Enterprise Extensions->Impact Analysis action to see your dependencies instead.

One last word before I go… As I re-read this post, I realize I am using the terms “RDz local project” and “zComponent project” interchangeably. Recall that the zComponent project is a specialized eclipse project used by the Enterprise Extensions for build, loading files to the host, etc. It has its own nature and a specific folder structure that is required. When you create your zComponent project (via zimport or the wizard in the eclipse client), the RDz local project nature will be automatically added to it.

That’s all for now! As always, feel free to share your own tips and gotchas, and I’ll update this post as we go.

This entry was posted in Enterprise Extensions, Rational Team Concert, System z. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s