Just an update with common blocks. What I am doing is calling two different subroutines with the same UniSession.
The first Subroutine inserts 1 common variable to the common block. The second Subroutine inserts 2 common variables to the common block. I am calling these subroutines consecutively and not nested. This means that after each subroutine call the common area should be lost and therefore I should not get a common miss match exception. >From UniVerse BASIC Reference "A common area can be either named or unnamed. An unnamed common area is lost when the program completes its execution and control returns to the UniVerse command level. A named common area remains available for as long as the user remains in the UniVerse environment." I decided to compare the difference between UniObject .NET, VB6 and Java. The results are as follows. UniObjects VB6 and Java Can use the same session to call subroutines consecutively. The common block is cleared after each subroutine call. UniObjects .NET Can NOT use the same session to call subroutines consecutively. The common block is not cleared after each subroutine call. Causing the second subroutine to not load and throw and exception. This to me sounds like a bug in the .NET implementation of UniObjects. Example code for .NET, VB6 and Java can be found via the link below. http://www.mediafire.com/?sharekey=dfc3c5e4b0702c4d2fb2ca15d7ea42d9e04e75f6e8ebb871 Subroutines ----------------SR.AHTEST.CALL1--------------------- SUBROUTINE SR.AHTEST.CALL1 COMMON AH1 RETURN END ---------------------------------------------------- ----------------SR.AHTEST.CALL2--------------------- SUBROUTINE SR.AHTEST.CALL2 COMMON AH1, AH2 RETURN END ---------------------------------------------------- Below is the same example in Java import asjava.uniobjects.*; public class test { public static void main(String [ ] args) { System.out.println("Start"); try{ UniJava objUJ; objUJ = new UniJava(); UniSession ahsession = objUJ.openSession(); ahsession.setHostName("HOST"); ahsession.setUserName("USERNAME"); ahsession.setPassword("PASSWORD"); ahsession.setAccountPath("ACCOUNT"); ahsession.connect(); UniSubroutine ahsub1 = ahsession.subroutine("SR.AHTEST.CALL1", 0); ahsub1.call(); UniSubroutine ahsub2 = ahsession.subroutine("SR.AHTEST.CALL1", 0); ahsub2.call(); }catch(Exception e){ System.out.println(e.toString()); } System.out.println("End"); } } Adrian Halid Senior Analyst/Programmer IT Vision Australia Pty Ltd (ABN: 34 309 336 904) PO Box 881, Canning Bridge WA 6153 Level 3, Kirin Centre, 15 Ogilvie Road, Applecross, WA, 6153 P: (08) 9315 7000 F: (08) 9315 7088 E: [email protected] W: http://www.itvision.com.au ___________________________________________________________ NOTICE : This e-mail and any attachments are intended for the addressee(s) only and may contain confidential or privileged material. Any unauthorised review, use, alteration, disclosure or distribution of this e-mail (including any attachments) by an unintended recipient is prohibited. If you are not the intended recipient please contact the sender as soon as possible by return e-mail and then delete both messages. ___________________________________________________________ -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Adrian Halid Sent: Friday, 9 October 2009 8:35 AM To: U2 Users List Subject: Re: [U2] UniObject .NET Session and Common Block Bug Thanks everyone for you support. I understand that the issue in .net is caused by trying to resize the common block and will look at putting all unnamed commons into one include or name all my commons. The bit that I still don't understand is why I don't have an exception in UniObject VB6. But do have an exception in UniObject .NET. Is this a feature/bug of UniObject VB6 that it clears out the Common Block? In the VB6 code you are still creating the Subroutine object from the same session. So shouldn't the 2nd subroutine call fail to load as well in VB6 just like it does in .net? I ask this because I am looking converting our existing VB6 app into a .NET app. We have thousands of Subroutines that insert different common blocks but never had this issue when calling consecutive subroutines via VB6 code all within the same session. So before I go naming all my unnamed commons I want to be sure I understand exactly what it does as it will effect these thousands of Subroutines. Regards Adrian Halid Senior Analyst/Programmer IT Vision Australia Pty Ltd (ABN: 34 309 336 904) PO Box 881, Canning Bridge WA 6153 Level 3, Kirin Centre, 15 Ogilvie Road, Applecross, WA, 6153 P: (08) 9315 7000 F: (08) 9315 7088 E: [email protected] W: http://www.itvision.com.au ___________________________________________________________ NOTICE : This e-mail and any attachments are intended for the addressee(s) only and may contain confidential or privileged material. Any unauthorised review, use, alteration, disclosure or distribution of this e-mail (including any attachments) by an unintended recipient is prohibited. If you are not the intended recipient please contact the sender as soon as possible by return e-mail and then delete both messages. ___________________________________________________________ -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bill Haskett Sent: Friday, 9 October 2009 12:26 AM To: U2 Users List Subject: Re: [U2] UniObject .NET Session and Common Block Bug Adrian: An "unnamed" common is not lost between subroutine calls. It is only lost when a program (not a subroutine) completes execution. So, If I run PROGRAM1, set "unnamed" common within it, then call SUBROUTINE1, then call SUBROUTINE2, "unnamed" common is kept until PROGRAM1 completes execution, even though SUBROUTINE2 completed execution then SUBROUTINE1 completed execution. This is where you have to be careful with non-telnet connectivity. Sometimes, a product has a BASIC subroutine listening at the U2 end then CALLS the subroutines specified. In this case, the use of all common has to be thought about. Bill ------------------------------------------------------------------------ Adrian Halid said the following on 10/7/2009 11:36 PM: > Thanks for the help. > > It seems once you name your common block you do not get the error anymore. > > Just having a read of the documentation about the common statement in the > documentation. > > "A common area can be either named or unnamed. An unnamed common area is > lost when the program completes its execution and control returns to the > UniVerse > command level. A named common area remains available for as long as the user > remains in the UniVerse environment." > > >From what it says I should be able to have them unnamed and loose it between > >subroutine calls. > > Regards > > > Adrian Halid > Senior Analyst/Programmer > > IT Vision Australia Pty Ltd (ABN: 34 309 336 904) > PO Box 881, Canning Bridge WA 6153 > Level 3, Kirin Centre, 15 Ogilvie Road, Applecross, WA, 6153 > P: (08) 9315 7000 F: (08) 9315 7088 > E: [email protected] W: http://www.itvision.com.au > > ___________________________________________________________ > > NOTICE : This e-mail and any attachments are intended for the addressee(s) > only and may > contain confidential or privileged material. Any unauthorised review, use, > alteration, > disclosure or distribution of this e-mail (including any attachments) by an > unintended recipient > is prohibited. If you are not the intended recipient please contact the > sender as soon as > possible by return e-mail and then delete both messages. > ___________________________________________________________ > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Womack, Adrian > Sent: Thursday, 8 October 2009 2:19 PM > To: U2 Users List > Subject: Re: [U2] UniObject .NET Session and Common Block Bug > > > The common blocks you've shown are not named - maybe that's your > problem. > > Try naming them (i.e. adding a unique slash-delimited name between the > word COMMON and the variable name(s). > > eg. > > COMMON /AHC1/ AHCOMMON1 > & > COMMON /AHC2/ AHCOMMON2 > > That way there won't be any conflict between the two blocks. > > We use named common extensively and it is mostly "lazy loaded" i.e. only > loaded the first time it's required, and we don't have any problems. > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Adrian Halid > Sent: Thursday, 8 October 2009 11:07 AM > To: [email protected] > Subject: [U2] UniObject .NET Session and Common Block Bug > > <snip> > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > > > DISCLAIMER: > Disclaimer. This e-mail is private and confidential. If you are not the > intended recipient, please advise us by return e-mail immediately, and delete > the e-mail and any attachments without using or disclosing the contents in > any way. The views expressed in this e-mail are those of the author, and do > not represent those of this company unless this is clearly indicated. You > should scan this e-mail and any attachments for viruses. This company accepts > no liability for any direct or indirect damage or loss resulting from the use > of any attachments to this e-mail. > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
