Topic
  • 9 replies
  • Latest Post - ‏2012-12-05T15:31:59Z by chellmayr
RDzPowerUser
RDzPowerUser
43 Posts

Pinned topic RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

‏2012-03-14T16:41:11Z |
When you open a program in RDz, it downloads the copybooks to a temporary files folder within your workspace. From that point forward, if you open a program with that copybook again, it will check the temporary workspace for the copybook, and use that to parse the program. If you use "open declaration" or "open copy member," RDz will open the copybook from your temporary file. It does not actively access the mainframe if the file exists. If you open the copybook directly from the PDS, it downloads a fresh copy to your workspace.

The issue...
You are not always looking at the most recent copybook. This issue will come up if a copybook gets turned over or changed by someone and you already have a "temporary" copybook downloaded from that dataset. I am not sure how often the temporary files are erased, but it seems like never based on the amount of files I have in my workspace from downloaded copybooks.

I understand this saves on MIPs by downloading copybooks and accessing them locally, but we run the risk of viewing old copybooks without knowing it, or receiving syntax errors based on parsing with old copybooks without knowing it.

The resolution...?
Automatically delete the temporary files every so often, so we start fresh with downloading copybooks from production and such after releases.

Has anyone else shared the woes of this shortcoming? This seems like a significant risk since we never open most of our copybooks... they will never get "refreshed"
Updated on 2012-12-05T15:31:59Z at 2012-12-05T15:31:59Z by chellmayr
  • MattUnsworth
    MattUnsworth
    22 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-03-14T19:37:17Z  
    I've noticed this and other similar behavior related to the code parsing. For example, if I open my source for the first time and don't have any libraries set up in my property group I get all the warnings due to RDz not resolving the copybooks. However if I go into the property group and add the copybook libraries, RDz still gives me the warning that it can't resolve the copybook even though I can highlight it and select open member and it opens up just fine.

    I'm just used to clearing the cache when this happens and everything gets re-parsed correctly.
  • akkina9
    akkina9
    124 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-03-15T15:55:01Z  
    I've noticed this and other similar behavior related to the code parsing. For example, if I open my source for the first time and don't have any libraries set up in my property group I get all the warnings due to RDz not resolving the copybooks. However if I go into the property group and add the copybook libraries, RDz still gives me the warning that it can't resolve the copybook even though I can highlight it and select open member and it opens up just fine.

    I'm just used to clearing the cache when this happens and everything gets re-parsed correctly.
    The behavior where the copybooks are not downloaded again when opening the parent program is the intended behavior that we document (http://pic.dhe.ibm.com/infocenter/ratdevz/v8r0/index.jsp?topic=/com.ibm.etools.rdz.language.editors.doc/topics/czddown_lpex.html)

    If the user wants the copybooks to be refreshed, they can do several things:
    • Clear the file cache from the RSE view.
    • Use the Refresh Copy member action for an individual copybook (available only in LPEX)
    • Disconnect from the system, connect again, and open the parent program.

    We agree that having Open Declaration and Open Copybook open a stale version of the copybook is a bad bug that needs to be fixed, please open a PMR to get this addressed.

    Thanks
  • RDzPowerUser
    RDzPowerUser
    43 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-03-15T16:42:19Z  
    • akkina9
    • ‏2012-03-15T15:55:01Z
    The behavior where the copybooks are not downloaded again when opening the parent program is the intended behavior that we document (http://pic.dhe.ibm.com/infocenter/ratdevz/v8r0/index.jsp?topic=/com.ibm.etools.rdz.language.editors.doc/topics/czddown_lpex.html)

    If the user wants the copybooks to be refreshed, they can do several things:
    • Clear the file cache from the RSE view.
    • Use the Refresh Copy member action for an individual copybook (available only in LPEX)
    • Disconnect from the system, connect again, and open the parent program.

    We agree that having Open Declaration and Open Copybook open a stale version of the copybook is a bad bug that needs to be fixed, please open a PMR to get this addressed.

    Thanks
    Akkina9,

    I believe refreshing the cache is not working as expected...

    The cache is not being cleared and/or the copybooks are not redownloading from the original mainframe source when I reopen the parent program after disconnecting/reconnecting.

    I do not see any preferences around this scenario. So, if a copybook has changed since the last time I opened (from the mainframe) the copybook, I will not see those changes. Unless, I manually click on each copybook and "refresh" OR clear the cache from in the preferences menu.

    Any thoughts? Your document is helpful, but RDz 8.0.3 is not working as the document states.
  • akkina9
    akkina9
    124 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-03-15T23:49:57Z  
    Akkina9,

    I believe refreshing the cache is not working as expected...

    The cache is not being cleared and/or the copybooks are not redownloading from the original mainframe source when I reopen the parent program after disconnecting/reconnecting.

    I do not see any preferences around this scenario. So, if a copybook has changed since the last time I opened (from the mainframe) the copybook, I will not see those changes. Unless, I manually click on each copybook and "refresh" OR clear the cache from in the preferences menu.

    Any thoughts? Your document is helpful, but RDz 8.0.3 is not working as the document states.
    Using the Refresh Cached copy member action for an individual copybook (available only in LPEX)
    • I tried this in LPEX editor and it works. Say you have the following statement:

    COPY COPYBOOK.

    Select COPYBOOK, and in the context menu (via RMB) you should see an action called "Refresh Cached Copy". After you perform this action, open copy member should open up the updated copybook.

    >> The cache is not being cleared and/or the copybooks are not redownloading from the original mainframe source when I reopen the parent program after disconnecting/reconnecting.
    Sounds like a bug. It is not working at my end in 803. Please open a PMR for this to be addressed.
  • RDzPowerUser
    RDzPowerUser
    43 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-03-20T13:27:50Z  
    • akkina9
    • ‏2012-03-15T23:49:57Z
    Using the Refresh Cached copy member action for an individual copybook (available only in LPEX)
    • I tried this in LPEX editor and it works. Say you have the following statement:

    COPY COPYBOOK.

    Select COPYBOOK, and in the context menu (via RMB) you should see an action called "Refresh Cached Copy". After you perform this action, open copy member should open up the updated copybook.

    >> The cache is not being cleared and/or the copybooks are not redownloading from the original mainframe source when I reopen the parent program after disconnecting/reconnecting.
    Sounds like a bug. It is not working at my end in 803. Please open a PMR for this to be addressed.
    The refresh cached copy function works. The copybooks are not refreshed after a disconnect/reconnect, however.

    So, developers would have to right-click every copybook and "refresh cached copy."
  • J_Ham
    J_Ham
    17 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-05-25T14:33:44Z  
    IS THIS STILL TRUE on 8.0.3.2???

    Here's the scenario I just tried.

    1. I created a brand COPYLIB PDS and added a new member MACPHAMP
    added a working storage element WS-CACHING-FIELD1 PIC X VALUE 'N'.

    2. I took a program I have in a z/OS Subproject and changed my Property Group' COBOL Compile Step Copylib Libraries: to include this new PDS first.

    3. I added the COPYBOOK in working storage and added a single line to change the vaule in WS-CACHING-FIELD1 to a 'Y'.

    4. I closed the programs and reopened it and there were no COBOL issues.

    5. While the program was open in EDIT mode, I went to the mainframe, opened the copybook book and changed the the WS-CACHING-FIELD1 to WS-CACHING-FIELD2 and SAVED the copybook and closed the member.

    6. I went back to the view of my program and the WS-CACHING-FIELD1 already said it was unable to resolve the reference to the FIELD1. When I hover over the field, the quickfix options has the FIELD2 name.

    7. Without changing anything I claosed the program (with th error) and repopened it, ang the erro still is highlighted.
    What scenario are you doing that you see this as an issue??

    Thanks!
  • J_Ham
    J_Ham
    17 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-05-25T16:49:40Z  
    • J_Ham
    • ‏2012-05-25T14:33:44Z
    IS THIS STILL TRUE on 8.0.3.2???

    Here's the scenario I just tried.

    1. I created a brand COPYLIB PDS and added a new member MACPHAMP
    added a working storage element WS-CACHING-FIELD1 PIC X VALUE 'N'.

    2. I took a program I have in a z/OS Subproject and changed my Property Group' COBOL Compile Step Copylib Libraries: to include this new PDS first.

    3. I added the COPYBOOK in working storage and added a single line to change the vaule in WS-CACHING-FIELD1 to a 'Y'.

    4. I closed the programs and reopened it and there were no COBOL issues.

    5. While the program was open in EDIT mode, I went to the mainframe, opened the copybook book and changed the the WS-CACHING-FIELD1 to WS-CACHING-FIELD2 and SAVED the copybook and closed the member.

    6. I went back to the view of my program and the WS-CACHING-FIELD1 already said it was unable to resolve the reference to the FIELD1. When I hover over the field, the quickfix options has the FIELD2 name.

    7. Without changing anything I claosed the program (with th error) and repopened it, ang the erro still is highlighted.
    What scenario are you doing that you see this as an issue??

    Thanks!
    To my own thread, I post....

    I have been showed the way this is still a problem. If you take an existing copybook member in the program from a library that is in the concatenation string (PROD.COPYLIB) and move it into the intermediate copylib (TEST.COPYLIB) and change it, it is not picked up and the program still has the source for that member as the place it originally found the member (PROD.COPYLIB).

    Concatenation sequence in Properties Group:
    1. TEST.COPYLIB
    2. PROD.COPYLIB

    It does not reconnect with the correct member concatenation until you close out of RDz and reopen.
  • chellmayr
    chellmayr
    16 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-10-16T13:42:54Z  
    I think that isn't solved at 8.0.3.2.
    Is there a solution at 8.0.3.3?

    Because a by-hand solution isn't very workable!

    Thanks,
    chris
  • chellmayr
    chellmayr
    16 Posts

    Re: RDz parses with potentially OLD copybooks! SIGNIFICANT RISK!?

    ‏2012-12-05T15:31:59Z  
    I made a test with 8033 and i think the problem is solved.

    can anyone else check it too?

    thanks,
    chris