Re,
I generally would expect short naming to work correctly if it is entirely consistent between all the nodes. In theory, short naming is nothing but all FQDNs being TLDs, and that used to work since 1986 (cf. localhost). The problem is that, in practice, ignorant developers have sprinkled code bases with implicit assumptions about host names necessarily containing a domain part (they probably work next door to those who always forget that '-' is an allowed character in domain names). That brought us nonsense like localhost.localdomain (and RedHat, being essentially the blueprint for CentOS, are quite in the front row of this questionable development). But I disgress. What I want to say is that in practice, short names have quirks. Windows for instance does some weird magic when you try to resolve short names that it doesn't do when resolving FQDNs that have a domain part. It's even a difference how many parts there are, name.tld is dealt with differently then name.sld.tld. Don't know what they smoke, but when they embraced DNS with the beginnings of AD, we all hoped it could only get better than before (NetBIOS naming and WINS). But all sorts of quirks remain. BTW, DNS and "a domain environment" are two completely orthogonal things. IP networks (including LANs) of some size used DNS long before MS finally based their second generation domain concept (AD) on top of its naming hierarchy entirely. As soon as networks grow beyond SOHO size, naming usually turns into a mess and DNS is absolutely necessary to keep it consistent.
But back to your problem: What baffles me is the repeating theme here ain't only the DA claiming it couldn't connect to the MA (runing on dpcell3), it's that IPC Invalid Hostname or IP Address that it presents as the actual reason for the problem to connect. And that would mean the issue is in fact ultimately in the resolving of dpcell3 to a proper address. But ping and telnet 5555 working with that same name would exclude this explanation.
This somehow calls for some strace(8) examination of what really happens, I think, ideally accompanied by sniffing the conversations with tcpdump(8). There's some dead rat here in name resolution, and it needs to be found and disposed of. Have you checked all the usual suspects, like /etc/resolv.conf, /etc/host.conf, /etc/nsswitch.conf, /etc/gai.onf (and IPv6 interference in general)? Is mDNS/ZeroConf/avahi part of the picture? It somehow looks like the issue is client-->server, but not the other way around (as you could import the client when connecting to it from the server).
BTW, if you ask yourself of what FQDN to use in order to test this, I have a backup DMZ that simply uses the TLD backup (so with your hostnames, they would turn into dpcell3.backup and centos-02.backup). That's working flawlessly so far with a lot of different Linux (including one CentOS 4, mind you) and Windows versions, some of them using DNS (the zone is on a Linux running BIND) and some of them using hosts entries. The problem is probably that you cannot move your CM to another name (even when only changing its FQDN) now, as that is burned deeply into the IDB. But maybe I'm wrong here.
HTH,
Andre.