Compiling with the wrong connection's properties.

Hi,

Sorry, this is a long one, but it shows an error in RDP v8.5.1 that might affect several of you. The same error may be in earlier versions as well, but I haven't got any earlier versions to test with.

I have two IBM i connections setup in RSE connecting to the same server. The idea is that they have different library lists so that I can open a source member with one connection and it will compile with that connection's library list and into the correct object library (PGMLIB - not the same as SRCLIB in this 'shop). Each connection has a different PGMLIB set in the properties.

Yesterday I was helping a colleague with a change I'd made ages ago and I opened a source member (using CTRL-ALT-A) using the "dev" connection, but when I compiled it I discovered that it used the "test" connection's PGMLIB (so I basically overwrote the test program). Normally this works fine, but this is probably the first time that I have opened the same source member from two different connections at the same time. Before you ask, I closed all source members, opened the source member from the "dev" connection only and it still compiled into the PGMLIB for the "test" connection. Also, the erroneous PGMLIB used in the compile was *not* the default PGMLIB set in the windows|preferences screen (remote systems|IBM i|command execution).

When I shut RDP (v8.5.1) down and restarted it, the correct PGMLIB was used in all further compiles until I opened two versions of the same source in two different connections again.

I can reproduce this problem every time. (assuming your compile commands use the PGM(&O/&N) SRCFILE(&L/&F) SRCMBR(&N) compile options and you have a different object library set in each connection.)
0) Start RDP.
1) Open a development source member using one connection (i.e. "dev")
2) Open the test version of the same source member using the other connection
3) "Accidentally" compile (w/ prompt) the test source and cancel the compile. (You'll see the "test" PGMLIB listed in the prompt).
4) Try to compile (w/ prompt) the development source and you'll see the PGMLIB is set to the "test" connection's PGMLIB.

At a guess I would say that once a compile is attempted, the PGMLIB for all further compiles will never change whether it is the correct one or not.

The compile *with* prompt is not necessary, but just highlights the issue while enabling you to cancel the compile. I did it with the compile without prompt, and it took me a good few minutes to realise I had compiled over the test version and caused the testers to suddenly get lots of level checks. If you go through with the compile, the correct library list is used but the PGMLIB is wrong. If you haven't prompted the compile you have no idea what has happened until someone screams at you.


-Paul.



P.S. I've created a PMR for this. The "description" field on the PMR is really annoying! It completely ignores all CR/LF or <BR /> and makes the text really hard to read... oh well, I hope I entered it correctly anyway.


Important, this email transmission and any files with it are strictly confidential to the intended recipient and may be legally privileged. Any views or opinions presented are solely those of the author and do not necessarily represent those of BHSF. If you are not the intended recipient, you must not copy, disclose or distribute its contents in any way. If you have received this e-mail in error, please notify the sender and delete the e-mail from your system.

We have taken steps to ensure this email and attachments are free from any virus but do not accept any responsibility once this e-mail has been transmitted. You should scan any attachments for viruses. No contract may be concluded on behalf of BHSF Limited by e-mail.

Registered Office: BHSF Limited, Gamgee House, 2 Darnley Road, Birmingham, B16 8TE. www.bhsf.co.uk Registered in England number 35500. BHSF is authorised and regulated by the Financial Services Authority.