I think it's appropriate for a software PM to have a fundamental understanding of coding, basic computer architecture, and even methodologies like Agile or Scrum. That way he can create accurate work breakdowns/estimates, and can go to bat for his team when the customer demands (for example) the equivalent of amazon.com in 16 hours with a team of five. I've worked with non-technical pm's and although they've been very good at managing the schedule and budget, it means I often have to spend alot of time trying to explain to them why some things look easier than they are. The developers or team leads shouldn't be wasting project time trying to explain technology to the PM. A non-technical Pm also won't have the ability to control feature creep because either he'll make promises the team can't deliver on or the team will waste time explaining why the endless features are impacting the schedule/budget. It can be done of course, and IS done in many places. But in my opinion it's not ideal.

However, as to exactly what or how much technology the PM should know? As I said, I think he should have the fundamentals. He can be an old Cobol programmer. Even though his experience is in procedural languages, that will still give him the background to understand that even in object oriented languages some things are harder than they look. He will still have respect for the workloads of his team. But in job hunting over the last year, what I've seen in technical PM job postings are specific requirements like 5+ years experience with C# programming, or .NET or whatever. I'm pretty sure that what this means is that job will be part time PM and part time developer. Or in this economy... you'll spend 40 hours/week doing development work and 20 hours/week doing PM work.

Knowledge of the Software Development Life Cycle, a development methodology such as Agile or Waterfall, some basic understanding of how the components are structured such as what are the big pieces of the software being built, and some emotional intelligence in handling people.

The PM doesn't need to know coding thoroughly but should be able to explain some parts of it to a non-techie, e.g. why do developers or testers ask so many questions when I've just told you what I want in 2 sentences. Understanding the methodology is useful as otherwise there may be issues as if a PM has never done a Waterfall project and comes from an Agile background, it could be quite the shock or vice versa.

PMI should have some information on how to get credentials as a PM, though that is only part of what has to be done. A second point would be to see if you could shadow a PM where you currently work and get to know what their process looks like, how they handle it, and what challenges you could see in trying to take on that kind of role. There are also likely more than a few PM blogs out there that may also have tips and suggestions for how to become a PM.

For keeping up on coding, I'd likely see if there is a way to split your duties so that there is some time,e.g. an hour a day, spent reviewing the code and checking the code base. This may or may not be adequate for keeping up with what is being built, but the idea here is to prevent the skills from getting rusty. The other thought would be to find small companies where the PM may also do a little developing as part of the project. The more general keeping up with technology question is more likely resolved by reading blogs and keeping up on trends particularly as they relate to your projects. For example, if you were a PM for a CMS project, if a new version of the software comes out, what is the procedure to determine if an upgrade makes sense? If does make sense, how to work that into the project plan? Those kinds of things are more common for a PM or strategic planners in IT and rarely are they simple to resolve.

Indirectly, the project manager is responsible for all aspects of the server. Where I work we have infrastructure and operations personnel that would handle installing the hardware and basic software like operating system. Applications people may be responsible for some configurations if there are special settings required by some applications that aren't documented in a step-by-step guide though sometimes if the new server is a clone of an existing one then a backup image may be used on it. As for performance tuning, this can be almost anyone to some extent from the systems administrators, application developers, database administrators or someone else possibly. The project manager is overseeing all of this but isn't likely to log onto a server to do some work, at least where I am now. In the past, there may have been some cases where in smaller companies the project manager would have to do this kind of work but generally in larger companies it would rarely happen as here you'd have specialists that could be used rather than having to rely on people that may or may not have deep knowledge and experience with some software.