Carey, Precisely. Thanks for the confirmation.
I don't think I can make use of this command for the purpose of creating a file from the contents of an ARS field. Stephen Remedy Skilled Professional -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Friday, March 07, 2008 8:42 AM To: arslist@ARSLIST.ORG Subject: Re: Output of field contents to file via a filter action Stephen, I am certain that the design intent was that there would be a process that parses the file and does the right thing with what it finds in the file. So #2 and #3 are totally by design. Also the process was envisioned as a standing "server" process and not something that is invoked over and over again. But I guess you could do that too. You just have to manage the "high water mark" for the entries that you have already processed between invocations. If you need to pass data to the process that is monitoring the file then the value needs to be a field that is written to the entry in the file. The process parses the entry and does what it needs to do from there. If my vague memory is correct, I would be careful about altering/renaming/moving the file while the ARS server is running. You may find that multiple users are writing to the file and that there are some "bad times" to alter the file. Also the ARS server may be confused by the files length changing or disappearing out from underneath it too. ( I seem to remember issues like that from when I played with this many years ago. But my memory might be poor about the details from that long ago. Do some testing at least.) The thing that I do not like about the approach is that it builds in a queue. (and thus a likely delay in the process) If what you need is "in line processing" then look toward the Filter Plugin. If the queue effect it desired and/or helpful then the Notify-Other model may work well for you too. 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 Fri, Mar 7, 2008 at 7:53 AM, Heider, Stephen <[EMAIL PROTECTED]> wrote: > ** > > > > Fred, > > > > That's cool. I did not know that about that part of the Notify command. > For reference, in ARS 6.3, the BasicGuide-630.pdf describes it on page 524. > > > > In my testing this morning I am not sure if I can use it here. I see three > challenges to overcome: > > > > The first 8 lines and the last 3 need to be removed from the file. This is > extra text inserted by the Notify command. > > The application or process that ultimately receives the file will need to > remove these extra lines. > > > > Each time the Notify command is run it appends to the existing file. > > After each run the file needs to be deleted or renamed. > > > > The filename is not unique. For example, "notify4.arn". This prevents > multiple simultaneous users from running this command. Even though you can > have up to 80 different file names (notify4.arn through notify83.arn) there > is no guarantee that two users will not run the process that creates these > files at the same time. > > An indirect work-around is to create a queue for these command whereby only > one command is run at one time. > > > > Since this a new command for me, are there any work-arounds for these items? > Items 2 and 3 could have been dealt with if ARS allowed for custom (unique) > filenames. > > > Stephen > Remedy Skilled Professional ________________________________________________________________________ _______ 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"
