update files stored in RTC from TSO
We're managing a z/os PDS library with RTC.
We've created a repository workspace and we've zloaded the library on a PDS.
The issue is the following:
the PDS members are modified with a host procedure and, after the run of this procedure, I do not see the changes on "Pending Changes" view.
I can see them only when I open the modified files from RDz z/os project (I suppose that at this moment there is a synchronization check from the file stored on repository wrkspc and the PDS member zloaded to z/os).
Is there another method in order to have these informations on pending changes view?
Thanks in advance.
Bye
We've created a repository workspace and we've zloaded the library on a PDS.
The issue is the following:
the PDS members are modified with a host procedure and, after the run of this procedure, I do not see the changes on "Pending Changes" view.
I can see them only when I open the modified files from RDz z/os project (I suppose that at this moment there is a synchronization check from the file stored on repository wrkspc and the PDS member zloaded to z/os).
Is there another method in order to have these informations on pending changes view?
Thanks in advance.
Bye
7 answers
Hi
Given your description I have to guess a bit at what you have done. Sounds like you have decided to go your own route by using some scripting perhaps to invoke the zLoad CLI.
The two obvious answers to your question are....
1. Use the ISPF client that we have written and release as of RTC v3.0. This client, in combination with the web client gives a z/OS developer almost the same functionality as they get in the Eclipse client without having to have the z/OS developer move themselves into an Eclipse IDE development environment.
2. Use the RDz/RTC Integration feature that we have implemented. This allows you to load RTC managed artifacts into an RDz remote project. Then you can use the RDz functionality to edit the files. Any changes you make will appear in the pending changes view and you can check in and deliver them like normal using the Eclipse client. The integration feature is shipped as part of the RDz product and based on your description it sounds like you do have the RDz product.
Guy
Given your description I have to guess a bit at what you have done. Sounds like you have decided to go your own route by using some scripting perhaps to invoke the zLoad CLI.
The two obvious answers to your question are....
1. Use the ISPF client that we have written and release as of RTC v3.0. This client, in combination with the web client gives a z/OS developer almost the same functionality as they get in the Eclipse client without having to have the z/OS developer move themselves into an Eclipse IDE development environment.
2. Use the RDz/RTC Integration feature that we have implemented. This allows you to load RTC managed artifacts into an RDz remote project. Then you can use the RDz functionality to edit the files. Any changes you make will appear in the pending changes view and you can check in and deliver them like normal using the Eclipse client. The integration feature is shipped as part of the RDz product and based on your description it sounds like you do have the RDz product.
Guy
Hi
I understand the issue. My two solutions are your two easy options. Either use our ISPF client to go everything .... load, edit, and checkin and deliver. Or use the RDz integration feature where you can add RTC managed artifacts to a remote project and edit them using the RDz editor. In the RDz case you will see the pending changes.
I don't know why you have chosen to manually load the files into z?OS using zLoad and perhaps you have a perfectly good reason for doing this. But as you have discovered, once they are loaded onto z/OS using this method there is no tie back to the Eclipse client and there is no way the Eclipse client is aware of what is happening on the z/OS system.
Guy
I understand the issue. My two solutions are your two easy options. Either use our ISPF client to go everything .... load, edit, and checkin and deliver. Or use the RDz integration feature where you can add RTC managed artifacts to a remote project and edit them using the RDz editor. In the RDz case you will see the pending changes.
I don't know why you have chosen to manually load the files into z?OS using zLoad and perhaps you have a perfectly good reason for doing this. But as you have discovered, once they are loaded onto z/OS using this method there is no tie back to the Eclipse client and there is no way the Eclipse client is aware of what is happening on the z/OS system.
Guy
On Unix/Windows file systems, there is a "refresh sandbox" command on
the Pending Changes view, for handling the case where files have been
modified by non-integrated editors.
Angelo: Would that handle your use case?
Guy: Would it be reasonable to submit a work item requesting for support
for that operation on z/OS PDS files?
Cheers,
Geoff
On 8/3/2011 11:38 AM, gslade wrote:
the Pending Changes view, for handling the case where files have been
modified by non-integrated editors.
Angelo: Would that handle your use case?
Guy: Would it be reasonable to submit a work item requesting for support
for that operation on z/OS PDS files?
Cheers,
Geoff
On 8/3/2011 11:38 AM, gslade wrote:
Hi
I understand the issue. My two solutions are your two easy options.
Either use our ISPF client to go everything .... load, edit, and
checkin and deliver. Or use the RDz integration feature where you can
add RTC managed artifacts to a remote project and edit them using the
RDz editor. In the RDz case you will see the pending changes.
I don't know why you have chosen to manually load the files into z?OS
using zLoad and perhaps you have a perfectly good reason for doing
this. But as you have discovered, once they are loaded onto z/OS
using this method there is no tie back to the Eclipse client and
there is no way the Eclipse client is aware of what is happening on
the z/OS system.
Guy
Hi Geoff
I don't think we have a case here that is applicable for this "refresh sandbox" idea. What they have done is used the CLI zLoad command to extract files from the SCM and lay them out on z/OS. There is no concept of a sandbox going on here and RTC is completely clueless about the fact this has happened.
However, we are actually looking into this concept. Where you would be able to load a workspace to a remote file system and have the eclipse client operate directly against those files. But this is down the road.
So, I still say that the workable options are ISPF client and/or the RDz/RTC integration feature.
Guy
I don't think we have a case here that is applicable for this "refresh sandbox" idea. What they have done is used the CLI zLoad command to extract files from the SCM and lay them out on z/OS. There is no concept of a sandbox going on here and RTC is completely clueless about the fact this has happened.
However, we are actually looking into this concept. Where you would be able to load a workspace to a remote file system and have the eclipse client operate directly against those files. But this is down the road.
So, I still say that the workable options are ISPF client and/or the RDz/RTC integration feature.
Guy
Guy,
the problem is not to load the files from RTC to z/os.
the problem is to modify the files from TSO AFTER the zload.
We need to modify these files from TSO and we want to see on RTC "Pending Changes" view the changes made on TSO without reopen the files.
Is it possible?
If you modify the code "outside" RTC ISPF Client, you can still use "refresh" command to make RTC aware of the changes. After you modify some members, launch RTC ISPF client, Jump to the Dataset including the changes. Then type "refresh" in the the command line. You will see the SCM filed marked with * for those files changed. I have no idea if there is an API providing equivalent function as refresh in RTC ISPF Client.
Hi Joseph
I think you may be getting a little confused here. Use of the ISPF client was one of the originally suggested work arounds, so yes, there are options when using this client. However, this particular scenario is using the Eclipse client and not the ISPF client ( ... you can tell since 'pending changes view' was mentioned. )
Guy
I think you may be getting a little confused here. Use of the ISPF client was one of the originally suggested work arounds, so yes, there are options when using this client. However, this particular scenario is using the Eclipse client and not the ISPF client ( ... you can tell since 'pending changes view' was mentioned. )
Guy