I saw this problem the other day (while out sick). I've been debating about chiming in ever since. On one hand, it seems like homework. (It's a simple problem. Your code is difficult to understand, indicating of a lack of experience.)
On the other hand, I don't mind helping out. I'm not going to do your work for you, but I can point you in the right direction...
First step: Define the problem. Once clearly defined, answers become far more straightforward.
A "full house", presumably 5 cards consisting of a three-of-a-kind plus a pair. Presumably this is a single-deck game. Presumably this is a standard deck (Ace,2,3,4,5,6,7,8,9,Jack,Queen,King) with suits (Spades,Clubs,Hearts,Diamonds). (Abbreviated below as (A23456789JQK) and (SCHD).)
You mention 3700 combinations. Presumably you therefore consider the hands (2S,2C,2H,3H,3D) and (3D,3H,2H,2C,2S) as being equivalent rather than distinct. (That's actually quite an important point, as touched upon by Sean & Loadmaster in their comments. There are 311,875,200 (52*51*50*49*48) possible 5-card drawings. However, only 2,598,960 of those hands are distinct!)
We have (13 * 4) possible three-of-a-kinds. E.g. For each rank card (such as 3), we can have 4 three-of-a-kinds ({0S,3C,3H,3D}, {3S,0C,3H,3D}, {3S,3C,0H,3D}, {3S,3C,3H,0D}). (Perhaps you begin to notice a pattern: 0111 1011 1101 1110.)
Give our three-of-a-kind, and presuming it's a single deck and standard deck game, our pair must be one of the other 12 remaining card ranks. For each card rank, there are six possibilities for a pair. E.g. Given a card rank of 7, we could have ({7S,7C,0H,0D}, {7S,0C,7H,0D}, {7S,0C,0H,7D}, {0S,7C,7H,0D}, {0S,7C,0H,7D}, {0S,0C,7H,7D}). (Again, perhaps you notice the pattern: 1100 1010 1001, 0110 0101, 0011.)
This gives us 13 * 4 * 12 * 6 = 3744 combinations.
From here it is a simple matter of looping to print them out.
I suggest you consider more descriptive variable names. While there are places and times to use single character loop variables, this is not one of them. Well written code is nearly self-documenting, allowing documentation to concentrate on the more complex higher-level abstractions. The few extra characters you save will wind up costing you a fortune in debugging time. If desired, you can be lazy like me, learn emacs, use (require 'completion), (global-set-key "\C-\\" 'complete), type the first few characters and let emacs auto-complete for you.
I suggest you consider supporting, and perhaps private, methods. For instance, you might be able to do something like: (It's been a while since I last coded in Java.)
for ( suit = 0; suit < 4 ; ++ suit )
private_printThreeOfAKind( card, suit!=0, suit!=1, suit!=2, suit!=3 )
Three of those (!=) would be true, one would be false.
With respect to printing pairs, you may want to investigate the continue statement. Ref: http://en.wikipedia.org/wiki/Java_syntax#continue_statement
E.g. This would allow you to skip over the case where the pair card is the same rank as the three-of-a-kind:
if ( threeOfAKindCard == pairCard )
continue;
I suggest you build your software in parts. Trying to build a complete system rarely works, even for the experts. Build parts, test them, rinse, repeat. Yes, that means writing scaffolding code that you won't turn it. Perhaps even a testing subclass... But small steps are easier to get working. As you improve as a programmer, you'll be able to take larger steps...