Here's how I would summarize the most obvious problem with the code as posted:

open( REFLIB, ... )
open( ORGLIB, ... )

while (<REFLIB>) {
    ...
    while (<ORGLIB>) {
        ....
    }
}
[download]

Having the second while loop nested like that means that you read to the end of the second input file immediately upon reading the first line of the first input file. In other words, by the time you get to the second line of input from REFLIB, there's no more data available to be read from ORGLIB because that file handle has reached end-of-file.

So you should do everything you need to do with all of the content from one file before you open the other file. I'm not sure whether it matters which file you handle first, but whatever you need from the first file must be stored in a suitable data structure, which you can then work with as you read through the second file.

Another big problem with your approach is that you're using line-oriented operations to deal with multi-line structured data. This makes it way too easy to create output that is badly structured. That's why you should be very grateful for toolic's question about the nature of your data -- and the link he provided to some relevant CPAN modules for handling data files of that type.

You should seriously consider taking advantage of the work that others have already done in dealing with the "synopsis liberty" data format. I looked at the man page for Parse::Liberty, and I'll admit that it isn't clear to me how it would be applied to the task you describe. (It's unfortunate that the documentation isn't better.)

Anyway, if that (or some other "liberty"-related) module doesn't work for you, you'll at least have to pay closer attention to the structure of the input -- at least try to use something that involves reading bracketed data, so you can keep track of the structure.

(minor updates to grammar and punctuation)

One other update: Please consider starting your code with some documentation (the POD formatting is easy to learn and use). Start over from scratch, but instead of writing the perl code first, describe what the code will do - what the procedure will be - as simply and clearly as possible (use your native language, if that will help). The description can look like pseudo-code, or a step-wise recipe. When you think you have it worked out clearly, then write the actual perl code to carry out the recipe. I always write code that way.