<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Tell us your Tech Support Horror Stories&#8230;</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/tech-horror-stories/tell-us-your-tech-support-horror-stories/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/tech-horror-stories/tell-us-your-tech-support-horror-stories/</link>
	<description>How the US government practices security while trying to implement IT security</description>
	<lastBuildDate>Sat, 12 Jan 2013 02:22:10 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: TomLiotta</title>
		<link>http://itknowledgeexchange.techtarget.com/tech-horror-stories/tell-us-your-tech-support-horror-stories/#comment-2</link>
		<dc:creator>TomLiotta</dc:creator>
		<pubDate>Sat, 12 Jan 2013 02:22:10 +0000</pubDate>
		<guid isPermaLink="false">http://itknowledgeexchange.techtarget.com/tech-horror-stories/?p=1#comment-2</guid>
		<description><![CDATA[I have &#039;horror&#039; stories that I could tell; but they each cover months of analysis, customer hand-holding and dialogs, IBM dialogs and numerous in-house and remote conferences. They have attributes in common: product updates with concurrent&#160;OS updates, homogenous networking, interactions of multiple applications, etc. Each one really needs to&#160;be a detailed Case Study rather than a simple comment.
&#160;
But less &quot;horrible&quot; cases did occur. In one case, a customer had altered the system SNDMSG (Send Message) command to make the target user parameter unavailable. All messages were forced to go to a specific target. Our product installer blew out in a very bizarre way that made no sense to us until we discovered that fact. We never learned why any system would be crippled in that way, but did work out changes to avoid the problem in future installs.
&#160;
A second customer had configured their AS/400 to bypass the IBM-supplied standard system startup procedure. This included ignoring the QSTRUPPGM&#160;system attribute that held the program name that ran the startup. The product installed fine, but it was necessary to execute a&#160;product activation&#160;during a phase of system startup before TCP/IP was started. It took some real digging to figure out why system startup kept skipping activation of our product. No errors were ever logged during startup; it was just as if the system never called our startup/activation routine even though it was clear that normal system attributes were properly set. A detailed analysis of work management finally showed that the standard auto-start entry in the controlling subsystem had been replaced with a custom one that took startup in a completely unexpected direction. Who ever expects to look there? And current staff for that customer had no info on why previous staff had done it. As far as they knew, it had &quot;always been done that way&quot;.
&#160;
Tom]]></description>
		<content:encoded><![CDATA[<p>I have &#8216;horror&#8217; stories that I could tell; but they each cover months of analysis, customer hand-holding and dialogs, IBM dialogs and numerous in-house and remote conferences. They have attributes in common: product updates with concurrent&nbsp;OS updates, homogenous networking, interactions of multiple applications, etc. Each one really needs to&nbsp;be a detailed Case Study rather than a simple comment.<br />
&nbsp;<br />
But less &#8220;horrible&#8221; cases did occur. In one case, a customer had altered the system SNDMSG (Send Message) command to make the target user parameter unavailable. All messages were forced to go to a specific target. Our product installer blew out in a very bizarre way that made no sense to us until we discovered that fact. We never learned why any system would be crippled in that way, but did work out changes to avoid the problem in future installs.<br />
&nbsp;<br />
A second customer had configured their AS/400 to bypass the IBM-supplied standard system startup procedure. This included ignoring the QSTRUPPGM&nbsp;system attribute that held the program name that ran the startup. The product installed fine, but it was necessary to execute a&nbsp;product activation&nbsp;during a phase of system startup before TCP/IP was started. It took some real digging to figure out why system startup kept skipping activation of our product. No errors were ever logged during startup; it was just as if the system never called our startup/activation routine even though it was clear that normal system attributes were properly set. A detailed analysis of work management finally showed that the standard auto-start entry in the controlling subsystem had been replaced with a custom one that took startup in a completely unexpected direction. Who ever expects to look there? And current staff for that customer had no info on why previous staff had done it. As far as they knew, it had &#8220;always been done that way&#8221;.<br />
&nbsp;<br />
Tom</p>
]]></content:encoded>
	</item>
</channel>
</rss>
