how about i ignore the virtual slap in the face of your response and try to assist again?
would you like that?
probably, so let me point one thing out: when one doesnt get responses one expects, it's often a sign that there is a communication issue.
to resolve communication issues, one should re-evaluate their own stance, predispoition and such. because if you have any, which you clearly do, then they will get in the way.
you seem to think that SiteMinder is broken and people should be rushing to fix it for you.
why dont you bookmark the FAQ on How To Ask Questions The Smart Way and read it later. i first read it in college in 1998 when a TA told me "Josh, you have the wrong idea here. instead of cutting you down i'm going to ask you tell me what you learn reading a website. i'll email you after office hours with the link. if i like your response you'll have my undivided attention and help outside of office hours today"
the link was: http://www.catb.org/esr/faqs/smart-questions.html
it was a good read. i completely changed my approach. the TA and i became friends, and i did well. Maybe we'll have that impact on you too. who knows.
Now lets review your issue. you're seeing "error 32" in your SMPS/Trace logs and can't figure out why.
Now let's review some facts:
1: this is not something a monitor can tell you siteminder is having
2: your trials at resolution are failing because you think SIteMinder is the issue -- it's not.
3: let's look at the error in terms of a programming language; namely the one Solaris, Linux, BSD and other unix variants are written in: C
okay. C says this, errno 32, means the pipe (communication stream) has been broken.
let's think about this a minute, if the communication stream is broken, the side that will report it is the side that doesn't expect it and is trying to act normal.
what would you gain checking it's logs? nothing. it wouldnt tell you hints to why. but you can try to isolate the broken pipe if there's multiple things being communicated with.
let's look at siteminder. pipes are used with the Web Agent, User Directories, and the Stores (Policy, Key, Session and Audit).
next, let's evaluate the pipe flows here.
Web Agents would not be likely to cause this, they only connect/disconnect as needed.
directories and stores... those the Policy server uses a lot and keeps open. it wouldnt want them to close.
wait. it wont want them to close? ok we can rule out 1 of the 3 pipe types.
now let's look closer at the next two.
stores... this one first because it is less likely to be the issue.
why?
1: key store pipe closure results in suspend mode. you'd be complaining about that if key store
2: policy store would be reopened next time it needs to write/update, and it wouldnt cause a hang
the other stores might not be used by you, and are likely not going to cause the issue you describe.
so let's look at the probably broken pipe source: user directories
shockingly, this would cause the policy server threads to hang for a big, then die, backing up the other processes and slowing everything down until your policy server is so bogged in trying old threads it stops accepting new ones.
"but wait!", mr ICAMguy is probably going to exclaim "the policy server is functioning according to what you said, just very slow and now missing stuff!"
yeah. that's right. and it causes the web agents to fail too. it's probably what you're seeing.
what about these pipes? these can be closed by many things not siteminder:
1: your os; it has a max time to hold the pipe. your solaris admin should be able to get that for you. or it should be nicely formatted by the CA SM Reproduction Informationo Gatherer tool, a perl script written about 3 years ago by a former CA Support person whom wanted an easy way to get all the information needed to make scaled environments for reproduction.
2: your firewalls
3: your routers
4: your user directories
now, siteminder's default time out on pipes, when it reopens them, is 10 minutes.
so while your solaris admin gets you the solaris value, remember you want to see 10 minutes 15 seconds minimum from there, so SiteMinder contorls these properly
ok. so now you've pinged your network guys. same deal, you want 15 seconds minimmum latency for SiteMinder, so 10 min 15 seconds minimum time out
finally cal your user directory admin, and get the same from him.
what? one is less than 10 minutes 15 seconds?
well now you know the root.
let's move on to resolving the issue so it doesnt happen anymore.
choices:
1: get the timeout bumped up. you have to have it over 10 minutes 15 seconds.
2: adjust the SiteMinder timeout.
given the way you're going about things, i strongly suggest #1 for you.
#2 requires manual adjustments that can make things worse if you ***** up, and you don't seem comfortable enough with things like registeries to be comfortable here.
hopefully, mr ICAM, you didnt go ballistic, as i expect, from the early part of this.
hopefully, mr ICAM, you adjusted your attitude, disposition, and opened your mind.
-Josh