Re: RANT: arimportcmd
LJ, I understand what you're saying, however, if they automatically scrubbed it, then it wouldn't work with windows :-) I guess they need to add a simple checkbox, and if you check it, then they scrub it. The simplest way (but wouldn't work for anyone who has already downloaded the documentation) is an update to the documentation. Thanks, Gary Opela, Jr., RSP Remedy Engineer Leader Communications, Inc. http://www.5pointleader.com http://www.lcibest.com Best Product, Best People, Best PriceTM An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company 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. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
I went through this same scenario four or five years back with an ARM to be used on Solaris. After several of their "cleanings" I finally just VI'd the file to remove the control characters that were causing the problem. It was tedious and time-consuming at best. Luckily, once it works, it works forever. Seems to me that use of arimportcmd was covered on the absolute last page of the Advanced Admin Guide for whatever rev I was using (5 I think), and the documentation was sketchy at best, as was their help. Nice to see that some aspects of Remedy Tech Support policy have remained consistent though... David M Clark Remedy Programmer/Analyst >>> LJ Longwing <[EMAIL PROTECTED]> 5/8/2008 1:05 PM >>> 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" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
This is "normal" with almost all tools - BMC or otherwise. I specifically check for both types of line endings in Meta-Update (so that any CSV or Meta-Update script created on any platform can run on any platform) but that is not the norm. Try a makefile with Windows line returns; try a compiler's source file, and on and on. There is no need for a rant. Most people with Unix familiarity do ascii file conversions as a matter of course. Now that you know, it is no problem for you either. BTW, some file in Windows also contain an end of file marker as the last byte (Ctrl Z). This also causes Unix tools grief. dos2unix also eliminates these as DOS ascii mode ftp transfers and the like. The mapping file is an ASCII file. It can be used on any platform as long as the normal ascii file transfer mechanisms are used. Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: May 8, 2008 8: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. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
LJ, I see your point, but the good news is that there's no reason that you couldn't copy the mapping files to the server, manually edit them to remove the line feeds, and run arimportcmd from there. It's the .csv files that are constantly changing, not the .arm files. They should be static enough to make this process almost one-time. Rick On Thu, May 8, 2008 at 11:05 AM, LJ Longwing <[EMAIL PROTECTED]> wrote: > ** 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. > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
they opened a documentation defect (SW00295365) to indicate that a conversion is needed to use it on non Windows workstationsI know this would have saved me A LOT of work if it had been documented before... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate) Sent: Thursday, May 08, 2008 12:12 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** LJ, I understand what you're saying, however, if they automatically scrubbed it, then it wouldn't work with windows :-) I guess they need to add a simple checkbox, and if you check it, then they scrub it. The simplest way (but wouldn't work for anyone who has already downloaded the documentation) is an update to the documentation. Thanks, Gary Opela, Jr., RSP Remedy Engineer Leader Communications, Inc. http://www.5pointleader.com http://www.lcibest.com Best Product, Best People, Best PriceTM An ISO 9001:2000 Certified, CMMIR Level 3 Rated Company _ 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. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
I only tagged it as a rant because of how frustrated I was with their response, or lack of concern for their customer. I wasn't till I replied back telling them that it wasn't good enough that 'I' knew it, that it needed to be updated in the documentation that they created a documentation defect to ensure no one else has to go through those 2 weeks of hassle... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Thursday, May 08, 2008 12:23 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** This is "normal" with almost all tools - BMC or otherwise. I specifically check for both types of line endings in Meta-Update (so that any CSV or Meta-Update script created on any platform can run on any platform) but that is not the norm. Try a makefile with Windows line returns; try a compiler's source file, and on and on. There is no need for a rant. Most people with Unix familiarity do ascii file conversions as a matter of course. Now that you know, it is no problem for you either. BTW, some file in Windows also contain an end of file marker as the last byte (Ctrl Z). This also causes Unix tools grief. dos2unix also eliminates these as DOS ascii mode ftp transfers and the like. The mapping file is an ASCII file. It can be used on any platform as long as the normal ascii file transfer mechanisms are used. Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: May 8, 2008 8: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. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
I've discovered (the hard way) that BMC uses Windows almost exclusively for their development efforts and their day-to-day operations. They're not particularly keen on supporting *nix for any of their applications: they do it because it makes money to sell to a wider range of customers. While they do a rather good job testing their applications on the more popular combinations of *nix systems, *nix is not really not the forte of their support techs. Since you have the power of the command line, you are savvy enough to think around these issues where BMC hasn't done so yet. Jennifer From: LJ Longwing Sent: Thu 08-May-08 14:59 To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd This is a multi-part message in MIME format. --=_NextPart_000_0050_01C8B10B.5B6A7840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit they opened a documentation defect (SW00295365) to indicate that a conversion is needed to use it on non Windows workstationsI know this would have saved me A LOT of work if it had been documented before... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate) Sent: Thursday, May 08, 2008 12:12 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** LJ, I understand what you're saying, however, if they automatically scrubbed it, then it wouldn't work with windows :-) I guess they need to add a simple checkbox, and if you check it, then they scrub it. The simplest way (but wouldn't work for anyone who has already downloaded the documentation) is an update to the documentation. Thanks, Gary Opela, Jr., RSP Remedy Engineer Leader Communications, Inc. http://www.5pointleader.com http://www.lcibest.com Best Product, Best People, Best PriceTM An ISO 9001:2000 Certified, CMMIR Level 3 Rated Company _ 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. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
Honestly, I agree with both parties. Sometimes I am a fence sitter. But erally they could jsut update the program to check the end of the first line, and either clean the program before loading it, or clean it as loading it. It doesn't seem to me that it would be a major challenge. However, I understand that their position is that it is cheaper to train the handful of people that run into this issue. I don't believe this to be a new policy and I don't see it changing anytime soon. We will just have to accept it. Maybe we should have a central repository of all these little items that can be handled easily with a little knowledge that as a community we keep updated. I am sure Mr. Reinfeldt or someone else would be willing to host it. Heck, we could even use wikipedia. Maybe we need a Remepedia? Any ideas, suggestions? Brian On Thu, May 8, 2008 at 2:13 PM, Jennifer Meyer <[EMAIL PROTECTED]> wrote: > ** I've discovered (the hard way) that BMC uses Windows almost > exclusively for their development efforts and their day-to-day operations. > They're not particularly keen on supporting *nix for any of their > applications: they do it because it makes money to sell to a wider range of > customers. While they do a rather good job testing their applications on the > more popular combinations of *nix systems, *nix is not really not the forte > of their support techs. > > Since you have the power of the command line, you are savvy enough to think > around these issues where BMC hasn't done so yet. > > Jennifer > > > -- > *From:* LJ Longwing > *Sent:* Thu 08-May-08 14:59 > *To:* arslist@ARSLIST.ORG > *Subject:* Re: RANT: arimportcmd > > This is a multi-part message in MIME format. > > --=_NextPart_000_0050_01C8B10B.5B6A7840 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > they opened a documentation defect (SW00295365) to indicate that a > conversion is needed to use it on non Windows workstationsI know this > would have saved me A LOT of work if it had been documented before... > > _ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate) > Sent: Thursday, May 08, 2008 12:12 PM > To: arslist@ARSLIST.ORG > Subject: Re: RANT: arimportcmd > > > ** > > LJ, I understand what you're saying, however, if they automatically scrubbed > it, then it wouldn't work with windows :-) > > > I guess they need to add a simple checkbox, and if you check it, then they > scrub it. > > > > The simplest way (but wouldn't work for anyone who has already downloaded > the documentation) is an update to the documentation. > > > > Thanks, > > > > Gary Opela, Jr., RSP > > Remedy Engineer > > Leader Communications, Inc. > http://www.5pointleader.com > http://www.lcibest.com > > > Best Product, Best People, Best PriceTM > > An ISO 9001:2000 Certified, CMMIR Level 3 Rated Company > > _ > > 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
Re: RANT: arimportcmd
This is a difference between Unix/BSD/Linux and Windows/cpm. It applies to most, if not all, plain text files transported between the two platforms. An alternative is to use a binary format for the arm file, which has it's own set of consequences. You can correct this easily on the unix host using tr, vi, sed, etc.: cat infile | sed -e 's/^M$//g' > outfile ^M is entered using CTRL-V CTRL-M Axton Grams On Thu, May 8, 2008 at 2:05 PM, LJ Longwing <[EMAIL PROTECTED]> wrote: > ** > > 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. __Platinum Sponsor: www.rmsportal.com > ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: RANT: arimportcmd
Not to keep adding to this thread but this is not entirely correct. BMC uses Windows for their GUI development. Their server development (and all related binaries) are definitively on done with equal effort on Unix as well as (now) Windows. Remedy server started only on Unix after all. On the subject of a Wiki, Axton is running one now: www.arswiki.org Perhaps a page breaking down common problems as a thesaurus might? Although, again, "ASCII files" by definition, need a translate when moving from Unix to Windows and vice versa. (Imagine the translate to mainframes!) Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jennifer Meyer Sent: May 8, 2008 9:14 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** I've discovered (the hard way) that BMC uses Windows almost exclusively for their development efforts and their day-to-day operations. They're not particularly keen on supporting *nix for any of their applications: they do it because it makes money to sell to a wider range of customers. While they do a rather good job testing their applications on the more popular combinations of *nix systems, *nix is not really not the forte of their support techs. Since you have the power of the command line, you are savvy enough to think around these issues where BMC hasn't done so yet. Jennifer _ From: LJ Longwing Sent: Thu 08-May-08 14:59 To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd This is a multi-part message in MIME format. --=_NextPart_000_0050_01C8B10B.5B6A7840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit they opened a documentation defect (SW00295365) to indicate that a conversion is needed to use it on non Windows workstationsI know this would have saved me A LOT of work if it had been documented before... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate) Sent: Thursday, May 08, 2008 12:12 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** LJ, I understand what you're saying, however, if they automatically scrubbed it, then it wouldn't work with windows :-) I guess they need to add a simple checkbox, and if you check it, then they scrub it. The simplest way (but wouldn't work for anyone who has already downloaded the documentation) is an update to the documentation. Thanks, Gary Opela, Jr., RSP Remedy Engineer Leader Communications, Inc. http://www.5pointleader.com http://www.lcibest.com Best Product, Best People, Best PriceTM An ISO 9001:2000 Certified, CMMIR Level 3 Rated Company _ 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 documenta
Re: RANT: arimportcmd
Fair enough. I'm certainly not offended and hope I haven't offended anyone! I presume that support is quite frustrating from the stories I have heard. I personally try not to use it (pointing out bugs is a chargeable service after all) and have been quite impressed with the support I have had from BMC when I have needed it. And, these days anyhow, I make my living by using, configuring, talking about, and servicing BMC's products. And I AM a great believer in Documentation bugs after all! As for how hard it is to fix: I was going to say it's one line, but I'm glad I checked: It's about 9 lines (including three lines of comments and two extra lines for spacing for old mainframe style source files or four lines actual c) every place they read a line from a file. And here it is: // delete and if (strlen(pBf) && pBf[strlen(pBf)-1] == '\n') pBf[strlen(pBf)-1] = '\0'; if (strlen(pBf) && pBf[strlen(pBf)-1] == '\r') pBf[strlen(pBf)-1] = '\0'; // handle a windows only in cc 1 of an empty // line or as the last character of a text line if (strlen(pBf) == 1 && pBf[0] == 0x1a) pBf[0] = '\0'; if (strlen(pBf) > 1 && pBf[strlen(pBf)-1] == 0x1a) pBf[strlen(pBf)-1] = '\0'; I wonder how the import tool will handle a Windows CSV on the Unix platform? No doubt you will have tested that in your travails - as an aside I just looked up that word for its spelling and though it had originated from the French but was amused to note: ...[Middle English from Old French travail, travaillier, ultimately via medieval Latin trepalium 'instrument of torture', from Latin tres 'three' + palus 'stake'] - perhaps a tad more literal in your case! Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: May 8, 2008 9:10 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** I only tagged it as a rant because of how frustrated I was with their response, or lack of concern for their customer. I wasn't till I replied back telling them that it wasn't good enough that 'I' knew it, that it needed to be updated in the documentation that they created a documentation defect to ensure no one else has to go through those 2 weeks of hassle... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Thursday, May 08, 2008 12:23 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** This is "normal" with almost all tools - BMC or otherwise. I specifically check for both types of line endings in Meta-Update (so that any CSV or Meta-Update script created on any platform can run on any platform) but that is not the norm. Try a makefile with Windows line returns; try a compiler's source file, and on and on. There is no need for a rant. Most people with Unix familiarity do ascii file conversions as a matter of course. Now that you know, it is no problem for you either. BTW, some file in Windows also contain an end of file marker as the last byte (Ctrl Z). This also causes Unix tools grief. dos2unix also eliminates these as DOS ascii mode ftp transfers and the like. The mapping file is an ASCII file. It can be used on any platform as long as the normal ascii file transfer mechanisms are used. Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: May 8, 2008 8: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 envir
Re: RANT: arimportcmd
See...now that is what I was thinking...instead of forcing their users to go through the conversion process, especially considering that they know the file will be generated on Windows, to just write their app to handle that situation, but alas... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Thursday, May 08, 2008 3:26 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** Fair enough. I'm certainly not offended and hope I haven't offended anyone! I presume that support is quite frustrating from the stories I have heard. I personally try not to use it (pointing out bugs is a chargeable service after all) and have been quite impressed with the support I have had from BMC when I have needed it. And, these days anyhow, I make my living by using, configuring, talking about, and servicing BMC's products. And I AM a great believer in Documentation bugs after all! As for how hard it is to fix: I was going to say it's one line, but I'm glad I checked: It's about 9 lines (including three lines of comments and two extra lines for spacing for old mainframe style source files or four lines actual c) every place they read a line from a file. And here it is: // delete and if (strlen(pBf) && pBf[strlen(pBf)-1] == '\n') pBf[strlen(pBf)-1] = '\0'; if (strlen(pBf) && pBf[strlen(pBf)-1] == '\r') pBf[strlen(pBf)-1] = '\0'; // handle a windows only in cc 1 of an empty // line or as the last character of a text line if (strlen(pBf) == 1 && pBf[0] == 0x1a) pBf[0] = '\0'; if (strlen(pBf) > 1 && pBf[strlen(pBf)-1] == 0x1a) pBf[strlen(pBf)-1] = '\0'; I wonder how the import tool will handle a Windows CSV on the Unix platform? No doubt you will have tested that in your travails - as an aside I just looked up that word for its spelling and though it had originated from the French but was amused to note: ...[Middle English from Old French travail, travaillier, ultimately via medieval Latin trepalium 'instrument of torture', from Latin tres 'three' + palus 'stake'] - perhaps a tad more literal in your case! Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: May 8, 2008 9:10 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** I only tagged it as a rant because of how frustrated I was with their response, or lack of concern for their customer. I wasn't till I replied back telling them that it wasn't good enough that 'I' knew it, that it needed to be updated in the documentation that they created a documentation defect to ensure no one else has to go through those 2 weeks of hassle... _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Chernys Sent: Thursday, May 08, 2008 12:23 PM To: arslist@ARSLIST.ORG Subject: Re: RANT: arimportcmd ** This is "normal" with almost all tools - BMC or otherwise. I specifically check for both types of line endings in Meta-Update (so that any CSV or Meta-Update script created on any platform can run on any platform) but that is not the norm. Try a makefile with Windows line returns; try a compiler's source file, and on and on. There is no need for a rant. Most people with Unix familiarity do ascii file conversions as a matter of course. Now that you know, it is no problem for you either. BTW, some file in Windows also contain an end of file marker as the last byte (Ctrl Z). This also causes Unix tools grief. dos2unix also eliminates these as DOS ascii mode ftp transfers and the like. The mapping file is an ASCII file. It can be used on any platform as long as the normal ascii file transfer mechanisms are used. Cheers Ben _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: May 8, 2008 8: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
Re: RANT: arimportcmd
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 workstationsI know this > would have saved me A LOT of work if it had been documented before... > > 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 seve
