Page 1 of 2

Error 2278 - Retain Release Conflict

Posted: Sun Jul 18, 2010 5:13 pm
by PJKLUG
Program works 3.91f but errors in 4.18i

00010 LIBRARY RELEASE, "MPVENMNT/MPPROG" : FNVENMNT

The issue seems to be that the entire progam is a LIBRARY. If I remove the outer LIBRARY references it works. I have many file maintenance programs being run stand alone and as library calls from data entry programs if Customers, Vendors, etc. need to be added on the fly. This has worked since libraries were introduced in 3.70? but now doesn't? If you are wondering why I am still on 3.91 it's because it works. If you are wondering why I have to go on to 4.xx it's because I want to use SCREENIO.

Other issues...

F7 with GUI off doesn't highlight first and last character to copy
INSERT stays on until you turn it off rather than when you leave the line

So far those are my only problems after using 4.18i for less than 20 minutes.

Pete Klug - CTL

Posted: Sun Jul 18, 2010 5:51 pm
by PJKLUG
It works if I remove the RELEASE. I can have mixed LIBRARY statements within the program with or without RELEASE but the program itself can't have a RELEASE.

Pete

Posted: Sun Jul 18, 2010 6:32 pm
by gtisdale
When I first started using libraries I was inclined to use a lot of RELEASE libraries. My thinking was a carryover from the old days when memory conservatin was a concern.

However, I quickly learned that generally memory conservation is not a concern, althought there may be an occasional situation in which you might have this concern, and that LIBRARY RELEASE should NOT be used except in the situation where you know for sure it will work.

The situations that you know LIBRARY RELEASE will work in are situations where the released library is the very end of a string of library functions ("the end of the line"). That is, the released library does not itself call any library that is not RELEASED, nor does any other library function called by that library call any library function that is not released.

As we use more and more libraries and library functions in our programs, the probability that a called library is the "end of the line" and does not then call ANY other libaries is VERY REMOTE. So my recomendation is to never use LIBRARY RELEASE except where you are confident it is and will always be the "end of the line" AND you want the variables being used in the called library to clear as soon as the called function reaches FNEND.

FNGeorge

Posted: Sun Jul 18, 2010 6:38 pm
by Susan Smith
That's a very helpful explanation, George. Thanks. Good to know that you're on the case ;)

-- Susan

Posted: Sun Jul 18, 2010 7:15 pm
by PJKLUG
George:

If your thinking is correct then a stand alone file maintenance program called as a library from other programs should be called with a RELEASE in order for the variables in the file maintenace program to not interfere with the calling program variables. However in this situation it technically isn't being called from another program with or without a release but it is being loaded and RUN. Same thinking though in that it is at the "end of the line". Main issue is why does it now cause an error and works fine in version 3.91f ? I haven't tested it yet being called from another program. I can't believe no one has run into this before.

Pete

Posted: Sun Jul 18, 2010 7:18 pm
by PJKLUG
It also seems strange that 3 of the 5 BRG directors are working on a Sunday evening. This may explain things...

Just my thoughts...

Pete

Posted: Sun Jul 18, 2010 7:19 pm
by Susan Smith
Pete,

I run some programs as both libraries and standalone programs, but I have never used "RELEASE". I DO however make sure that I have appropriate initialization routines in those programs so that variable retention is not an issue from one library call to the next.

-- Susan

Posted: Sun Jul 18, 2010 7:21 pm
by Susan Smith
Pete wrote: It also seems strange that 3 of the 5 BRG directors are working on a Sunday evening. This may explain things...

What exactly does this explain? That we fooled around all week and have to make up the time on the weekend? Or that we need to get a life ;)

-- Susan

Posted: Sun Jul 18, 2010 7:46 pm
by PJKLUG
I was thinking more along the lines of "great dedication" which is why we were "choosen to serve" versus "excessive complusive" or the "get a life" theory. In my case the last two might be the more correct tag.

Back to topic... Most of my file maintenance programs "became" libraries by just adding the appropriate lines of code at the start and an FNend at the end, assign "non standard to me" file numbers on the file opens and WHOA-LA! it works. Throw in the RELEASE and I don't have to worry about variable conflicts. Not pretty but it worked. The problem is that it USED TO work!

Pete

Posted: Sun Jul 18, 2010 7:59 pm
by Susan Smith
I hear you. I have no idea why it would have worked in 3.91 and not in 4.1. Perhaps Gordon will weigh in on this.

I looked through the release notes to see if there was anything there, but I didn't see anything. I could have missed it however.

-- Susan

Posted: Sun Jul 18, 2010 9:13 pm
by Gabriel
PJKLUG wrote:George:

If your thinking is correct then a stand alone file maintenance program called as a library from other programs should be called with a RELEASE in order for the variables in the file maintenace program to not interfere with the calling program variables.
...
Pete
Library variables never interfere with calling program variables.

The purpose of RELEASE is to make your library variables clear every time the function closes.

Gabriel

Posted: Mon Jul 19, 2010 8:28 am
by GomezL
I know that BR 4.x added quite a bit of "Integrity Checking".
The old BR let you do a lot of things that "Didn't Work".
The Release command unloads a library after it's used, but you can't mix Release & Reserve.
My guess is the feature didn't do what you thought in 3.x, and now you get an error.

As long as you don't use "Reserve", the programs will pretty much do what you wanted.
When you run the program as a standalone project, it will link & load the library. When you chain to another program, it will unload the library. (As long as you didn't use reserve someplace).

Posted: Mon Jul 19, 2010 8:36 am
by PJKLUG
I have never used RESERVE and all my library calls within the program use RELEASE. The program will only run stand alone in 4.18i without the RELEASE. I haven't yet tried calling it from another program.

00010 LIBRARY RELEASE, "MPVENMNT/MPPROG" : FNVENMNT
00020 LET FNVENMNT(WRC$)
00030 DEF LIBRARY FNVENMNT(&WRC$)

and then an FNEND at the end of the program.

Pete

Posted: Mon Jul 19, 2010 8:58 am
by gtisdale
Pete:
You misunderstood my explanation. As a general rule DO NOT USE RELEASE when loading a program as a library.

FNGeorge

Posted: Mon Jul 19, 2010 3:25 pm
by gordon
It works if I remove the RELEASE. I can have mixed LIBRARY statements within the program with or without RELEASE but the program itself can't have a RELEASE.
Pete- I am not clear on the conditions wherein 4.18 BR will or will not accept RELEASE. Can you provide an example that refers to Program-A, Program-B, etc so I know what you mean by "the program"? First say if I have a program-A call program-B with RELEASE and program-B calls a library.... ( or whatever )

This way I can understand what is failing to run with RELEASE.

As I understand it, any library should be callable with RELEASE at any time, but it should not be callable with RELEASE while it is still in memory from a non-RELEASE call. There is no restriction on it's calls to other libraries that I know of.

A similar set of rules applies to NOFILES. NOFILES allows us to do make any program into a library like Pete has described without fear of file conflicts. NOFILES causes the library to to run with it's own set of file channels as if it were running in another session.

Gabriel is correct about the purposes of RELEASE. Originally it was to allow any number of snippets to be run in one area of memory. But nowadays the main use of RELEASE is to clear the variables upon each call to it.