LJ, Sorry for the slow response, but I have been away from email for a few days.
This thread has shown that you were not the first customer to stumble over this problem. ( ITIL: A problem is a reoccurring incident that one or more customers has over time.) The idea that the docs are cheaper to fix has been suggested, and I do not agree with that idea. The docs are easier to fix, but the total cost of the decision would still be on going. It is clearly possible for a software tool to identify the format of the file and adjust it's parsing for the format. (Just as "Meta-Update" claims to do.) It would even be possible to be more "radical" and switch the file format to a more standard, platform independent and stable format like XML too. I wonder how much it costs BMC to have tech support spend hours (or days? or weeks?) trying to troubleshoot a FTP file conversion(or not converted) problem? Good luck guys trying to get someone who does not understand what an ASCII file format is to tell you over the phone that when they transferred the file to the Unix server if it was auto converted. I have been in that chair, it is not an easy or quick task to achieve. Not to mention that the user might have actually used any number of clients/protocols to actually move the file from one to the other. sneaker net [due to network security design/requirements], scp, sftp, ftp, http [wget from the command line], etc... I wonder how much it costs customers, in terms of confidence in the BMC product line, when a "simple" thing like file format based on OS line endings prevent the tools from working as expected? Is this a common trait for "Enterprise class software"? I would bet that if BMC could find all of the incidents and add up all of the time that tech support has already spent on this issue that half of that time could have made the necessary change to the arimportcmd tool source. (But then again, maybe BMC's programmers are not as fast, with what appears from the outside to be a simple change, as we would want them to be.) LJ, I think you are very justified for this being a "RANT". And if it were me..... knowing how many other customers have been impacted by this problem over the years, I would insist that the incident be left open until the "problem" is fixed. BMC will define that as updating the docs and that is their prerogative. But you should keep the clock ticking on that incident until the problem is corrected. Push them to update all the docs, for all currently supported versions. (The same problem exists in all of them.) Maybe if we ( I take this approach from time to time with incidents that BMC wants to dismiss into "doc bugs".) take the time to show BMC how much the details hurt us, by helping them to measure the amount of time their customers wait for "simple things" then maybe someday, someone will see those details in the Tech support numbers and understand that changing the docs is not cheaper. Rather, the next phone call might have the same problem and cost BMC yet again, because they choose a "easy" way out by requiring the customer to be "smarter" instead of requiring their software to be "smarter". But maybe I am just stuck on that soapbox with you. We feel your pain. HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Thu, May 8, 2008 at 2:59 PM, LJ Longwing <[EMAIL PROTECTED]> wrote: > ** > they opened a documentation defect (SW00295365) to indicate that a > conversion is needed to use it on non Windows workstations....I know this > would have saved me A LOT of work if it had been documented before... > ________________________________ <snip> > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing > Sent: Thursday, May 08, 2008 1:06 PM > To: arslist@ARSLIST.ORG > Subject: RANT: arimportcmd > > > > I just got done working with BMC regarding a mapping problem and I'm not > liking their answer. I wanted to poll the community to test the waters for > this in case I need to open an RFE to make things work the way they say they > are supposed to work > > > > I created an ARM file from the windows tool, just like the docs say to, and > transferred it to a Suse Linux box, and couldn't get the arimportcmd tool to > work properly, after several back and forths with support, they gave me a > 'working' arm file, after several hours of trying to figure out what the > difference was, I came down to the fact that for the Linux version of the > import tool you need to run a dos2unix conversion (remove the hex 0D from > the CRLF). When I commented that I shouldn't need to run any conversions on > the ARM I was told point blank that the difference between how windows and > Unix store text files is beyond BMC's support realm and that I simply needed > to perform the conversion myself. My problems with this are several, but > the major one of which is that the documentation states > > > > Importing with mapping refers to running the BMC Remedy Import CLI by using > > a mapping created in BMC Remedy Import. The mapping must be created on > > Windows because that is the only environment BMC Remedy Import runs on > > interactively. After it is created, the mapping can be used on any platform. > > I take this to mean that I don't need to convert anything to use it, because > it 'can be used on any platform'....I'm curious if anyone on HPUX or AIX has > to go through this conversion, and if so, did you figure it out on your own > or did you get told this by support, and is anyone else annoyed about the > fact that the documentation is misleading at best, and completely wrong at > worst. I think that at a minimum they should either create the file so it's > readable on all platforms they support, or update the documentation to > indicate that some type of conversion needs to be performed to be able to > use it on non Windows platforms. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
