Re: Synch Search Database, UNIX (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE However, you can run it as a Run Process under an Escalation. Escalations are sometimes utilized like CRON jobs. Just set the time and it will start like a CRON job. Gordon M. Frank DISA\Version FNS -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 12:06 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX I was afraid of that. Thanks Hugo. On Thu, 29 Nov 2007, Hugo Visser wrote: > No, the admin tool does the actual "syncing". Since the admin tool is > a client side and windows only, you cannot synchronize the search > database from a unix command line. > > Hugo > > On Nov 29, 2007 5:37 PM, Drew Shuller <[EMAIL PROTECTED]> wrote: > >> Can the Synch Search Database be run from a Unix command line? >> >> Drew >> >> >> _ >> __ 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" > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" Classification: UNCLASSIFIED Caveats: NONE ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
That might work, as I'm trying to get around the bug where the synch stops if someone logs out of the Admin tool. On Thu, 29 Nov 2007, FRANK, GORDON CTR DISA JSSC wrote: Classification: UNCLASSIFIED Caveats: NONE However, you can run it as a Run Process under an Escalation. Escalations are sometimes utilized like CRON jobs. Just set the time and it will start like a CRON job. Gordon M. Frank DISA\Version FNS -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 12:06 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX I was afraid of that. Thanks Hugo. On Thu, 29 Nov 2007, Hugo Visser wrote: No, the admin tool does the actual "syncing". Since the admin tool is a client side and windows only, you cannot synchronize the search database from a unix command line. Hugo On Nov 29, 2007 5:37 PM, Drew Shuller <[EMAIL PROTECTED]> wrote: Can the Synch Search Database be run from a Unix command line? Drew _ __ 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" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" Classification: UNCLASSIFIED Caveats: NONE ___ 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: Synch Search Database, UNIX (UNCLASSIFIED)
...and of course there is the continuing saga of the 7.x admin tool being totally incapable of completing a sync successfully against a 7.x server with most of ITSM 7 and several other apps installed - it crashes every time after about an hour. This is still true on 7.1.00.001 Admin Tool and AR Server, even if you delete and recreate the search tables. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller > Sent: Thursday, November 29, 2007 1:01 PM > To: arslist@ARSLIST.ORG > Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) > > That might work, as I'm trying to get around the bug where > the synch stops if someone logs out of the Admin tool. > > > On Thu, 29 Nov 2007, FRANK, > GORDON CTR DISA JSSC wrote: > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > However, you can run it as a Run Process under an Escalation. > > Escalations are sometimes utilized like CRON jobs. Just set > the time and > > it will start like a CRON job. > > > > Gordon M. Frank > > DISA\Version FNS > > > > > > -Original Message- > > From: Action Request System discussion list(ARSList) > > [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller > > Sent: Thursday, November 29, 2007 12:06 PM > > To: arslist@ARSLIST.ORG > > Subject: Re: Synch Search Database, UNIX > > > > I was afraid of that. Thanks Hugo. > > > > > > On Thu, 29 Nov 2007, Hugo Visser wrote: > > > >> No, the admin tool does the actual "syncing". Since the > admin tool is > >> a client side and windows only, you cannot synchronize the search > >> database from a unix command line. > >> > >> Hugo > >> > >> On Nov 29, 2007 5:37 PM, Drew Shuller <[EMAIL PROTECTED]> wrote: > >> > >>> Can the Synch Search Database be run from a Unix command line? > >>> > >>> Drew ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
That's distressing. Do you know if anyone has submitted a bug report? I looked but didn't see one. On Thu, 29 Nov 2007, strauss wrote: ...and of course there is the continuing saga of the 7.x admin tool being totally incapable of completing a sync successfully against a 7.x server with most of ITSM 7 and several other apps installed - it crashes every time after about an hour. This is still true on 7.1.00.001 Admin Tool and AR Server, even if you delete and recreate the search tables. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 1:01 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) That might work, as I'm trying to get around the bug where the synch stops if someone logs out of the Admin tool. On Thu, 29 Nov 2007, FRANK, GORDON CTR DISA JSSC wrote: Classification: UNCLASSIFIED Caveats: NONE However, you can run it as a Run Process under an Escalation. Escalations are sometimes utilized like CRON jobs. Just set the time and it will start like a CRON job. Gordon M. Frank DISA\Version FNS -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 12:06 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX I was afraid of that. Thanks Hugo. On Thu, 29 Nov 2007, Hugo Visser wrote: No, the admin tool does the actual "syncing". Since the admin tool is a client side and windows only, you cannot synchronize the search database from a unix command line. Hugo On Nov 29, 2007 5:37 PM, Drew Shuller <[EMAIL PROTECTED]> wrote: Can the Synch Search Database be run from a Unix command line? Drew ___ 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: Synch Search Database, UNIX (UNCLASSIFIED)
I have had tickets open on this for 7.0.0.003 since June 2007. The main ticket was closed in an unresolved state and replaced with another ticket for 7.1 GA in September 2007, which was then closed and a defect SW00276070 was created that still has not been fixed even though its status is closed. That's as near as I can tell after retracing the steps through the labyrinth of supportweb issue and defect displays. There were even duplicate tickets for the same problem manifested differently for 7.0.x and 7.1 beta along the way. I don't think support is tracking this stuff correctly since they went to a process of closing the ticket upon creating a defect. If the defect from my ticket was also closed, there is no way to tell if they consolidated it into another defect, or addressed it in some other way. They sure as hell have NOT fixed it yet! Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller > Sent: Thursday, November 29, 2007 1:29 PM > To: arslist@ARSLIST.ORG > Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) > > That's distressing. > > Do you know if anyone has submitted a bug report? I looked > but didn't see one. > > > On Thu, 29 Nov 2007, strauss wrote: > > > ...and of course there is the continuing saga of the 7.x admin tool > > being totally incapable of completing a sync successfully > against a 7.x > > server with most of ITSM 7 and several other apps installed > - it crashes > > every time after about an hour. This is still true on > 7.1.00.001 Admin > > Tool and AR Server, even if you delete and recreate the > search tables. > > > > Christopher Strauss, Ph.D. > > Call Tracking Administration Manager > > University of North Texas Computing & IT Center > > http://itsm.unt.edu/ > > > >> -Original Message- > >> From: Action Request System discussion list(ARSList) > >> [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller > >> Sent: Thursday, November 29, 2007 1:01 PM > >> To: arslist@ARSLIST.ORG > >> Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) > >> > >> That might work, as I'm trying to get around the bug where > >> the synch stops if someone logs out of the Admin tool. > >> > >> > >> On Thu, 29 Nov 2007, FRANK, > >> GORDON CTR DISA JSSC wrote: > >> > >>> Classification: UNCLASSIFIED > >>> Caveats: NONE > >>> > >>> However, you can run it as a Run Process under an Escalation. > >>> Escalations are sometimes utilized like CRON jobs. Just set > >> the time and > >>> it will start like a CRON job. > >>> > >>> Gordon M. Frank > >>> DISA\Version FNS > >>> > >>> > >>> -Original Message- > >>> From: Action Request System discussion list(ARSList) > >>> [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller > >>> Sent: Thursday, November 29, 2007 12:06 PM > >>> To: arslist@ARSLIST.ORG > >>> Subject: Re: Synch Search Database, UNIX > >>> > >>> I was afraid of that. Thanks Hugo. > >>> > >>> > >>> On Thu, 29 Nov 2007, Hugo Visser wrote: > >>> > >>>> No, the admin tool does the actual "syncing". Since the > >> admin tool is > >>>> a client side and windows only, you cannot synchronize the search > >>>> database from a unix command line. > >>>> > >>>> Hugo > >>>> > >>>> On Nov 29, 2007 5:37 PM, Drew Shuller <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> Can the Synch Search Database be run from a Unix command line? > >>>>> > >>>>> Drew > > > > > __ > _ > > 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" > > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
I feel your pain! Hopefully, someone from BMC Remedy is monitoring this thread and will give us an update. SSD really does provide a lot of help. I'll run it and when it fails I'll submit a ticket. Drew On Thu, 29 Nov 2007, strauss wrote: I have had tickets open on this for 7.0.0.003 since June 2007. The main ticket was closed in an unresolved state and replaced with another ticket for 7.1 GA in September 2007, which was then closed and a defect SW00276070 was created that still has not been fixed even though its status is closed. That's as near as I can tell after retracing the steps through the labyrinth of supportweb issue and defect displays. There were even duplicate tickets for the same problem manifested differently for 7.0.x and 7.1 beta along the way. I don't think support is tracking this stuff correctly since they went to a process of closing the ticket upon creating a defect. If the defect from my ticket was also closed, there is no way to tell if they consolidated it into another defect, or addressed it in some other way. They sure as hell have NOT fixed it yet! Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 1:29 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) That's distressing. Do you know if anyone has submitted a bug report? I looked but didn't see one. On Thu, 29 Nov 2007, strauss wrote: ...and of course there is the continuing saga of the 7.x admin tool being totally incapable of completing a sync successfully against a 7.x server with most of ITSM 7 and several other apps installed - it crashes every time after about an hour. This is still true on 7.1.00.001 Admin Tool and AR Server, even if you delete and recreate the search tables. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 1:01 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) That might work, as I'm trying to get around the bug where the synch stops if someone logs out of the Admin tool. On Thu, 29 Nov 2007, FRANK, GORDON CTR DISA JSSC wrote: Classification: UNCLASSIFIED Caveats: NONE However, you can run it as a Run Process under an Escalation. Escalations are sometimes utilized like CRON jobs. Just set the time and it will start like a CRON job. Gordon M. Frank DISA\Version FNS -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Thursday, November 29, 2007 12:06 PM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX I was afraid of that. Thanks Hugo. On Thu, 29 Nov 2007, Hugo Visser wrote: No, the admin tool does the actual "syncing". Since the admin tool is a client side and windows only, you cannot synchronize the search database from a unix command line. Hugo On Nov 29, 2007 5:37 PM, Drew Shuller <[EMAIL PROTECTED]> wrote: Can the Synch Search Database be run from a Unix command line? Drew __ _ 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" ___ 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: Synch Search Database, UNIX (UNCLASSIFIED)
Hi I'm running a 7.0.1 patch 3 admin tool and our synch works, not fully but it does do some form of sync, we leave a PC on and start the sync, go home, come back in the morning to the message sync completed successfully, its best to have only the admin tool running as we find it grabs loads of memory and loads of processor. The only problem we have found so far is that it does not sync Active Links, not a single one, everything else seems fine but no AL's. We are going to run it again and if we get the same result we'll bug it. Cheers Robert - Original Message From: Drew Shuller <[EMAIL PROTECTED]> To: arslist@ARSLIST.ORG Sent: Thursday, 29 November, 2007 9:12:21 PM Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) I feel your pain! Hopefully, someone from BMC Remedy is monitoring this thread and will give us an update. SSD really does provide a lot of help. I'll run it and when it fails I'll submit a ticket. Drew On Thu, 29 Nov 2007, strauss wrote: > I have had tickets open on this for 7.0.0.003 since June 2007. The main > ticket was closed in an unresolved state and replaced with another > ticket for 7.1 GA in September 2007, which was then closed and a defect > SW00276070 was created that still has not been fixed even though its > status is closed. That's as near as I can tell after retracing the > steps through the labyrinth of supportweb issue and defect displays. > There were even duplicate tickets for the same problem manifested > differently for 7.0.x and 7.1 beta along the way. I don't think support > is tracking this stuff correctly since they went to a process of closing > the ticket upon creating a defect. If the defect from my ticket was > also closed, there is no way to tell if they consolidated it into > another defect, or addressed it in some other way. They sure as hell > have NOT fixed it yet! > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > >> -Original Message- >> From: Action Request System discussion list(ARSList) >> [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller >> Sent: Thursday, November 29, 2007 1:29 PM >> To: arslist@ARSLIST.ORG >> Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) >> >> That's distressing. >> >> Do you know if anyone has submitted a bug report? I looked >> but didn't see one. >> >> >> On Thu, 29 Nov 2007, strauss wrote: >> >>> ...and of course there is the continuing saga of the 7.x admin tool >>> being totally incapable of completing a sync successfully >> against a 7.x >>> server with most of ITSM 7 and several other apps installed >> - it crashes >>> every time after about an hour. This is still true on >> 7.1.00.001 Admin >>> Tool and AR Server, even if you delete and recreate the >> search tables. >>> >>> Christopher Strauss, Ph.D. >>> Call Tracking Administration Manager >>> University of North Texas Computing & IT Center >>> http://itsm.unt.edu/ >>> >>>> -Original Message- >>>> From: Action Request System discussion list(ARSList) >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller >>>> Sent: Thursday, November 29, 2007 1:01 PM >>>> To: arslist@ARSLIST.ORG >>>> Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) >>>> >>>> That might work, as I'm trying to get around the bug where >>>> the synch stops if someone logs out of the Admin tool. >>>> >>>> >>>> On Thu, 29 Nov 2007, FRANK, >>>> GORDON CTR DISA JSSC wrote: >>>> >>>>> Classification: UNCLASSIFIED >>>>> Caveats: NONE >>>>> >>>>> However, you can run it as a Run Process under an Escalation. >>>>> Escalations are sometimes utilized like CRON jobs. Just set >>>> the time and >>>>> it will start like a CRON job. >>>>> >>>>> Gordon M. Frank >>>>> DISA\Version FNS >>>>> >>>>> >>>>> -Original Message- >>>>> From: Action Request System discussion list(ARSList) >>>>> [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller >>>>> Sent: Thursday, November 29, 2007 12:06 PM >>>>> To: arslist@ARSLIST.ORG >>>>> Subject: Re: Synch Search Database, UNIX >>>>> >>>>> I was afraid of that. Thanks Hugo. >>>>> >>>>> >>>>&
Re: Synch Search Database, UNIX (UNCLASSIFIED)
Frank, Sure, but I really doubt that the Sync DB has any logic to "limit"/"break down" the full set into partial sets so that the operation can complete. (That is my theory anyway.) My opinion is that a standard feature of the tool set BREAKS when the OOB application is loaded. Therefor it is a bug. ( BMC can pick if it is a flaw in the OOB to have "to many objects" or in the ARS server for not being able to export all of the objects before the Admin Tool timeout. Either way it is a BUG in my book.) This kind of a bug has far reaching impact to the perception of quality of the products (note: the plural there) IMHO. Why has BMC not found this bug before release to the customers? If they have already found it, why was it not documented? What else will break due to "scaling issues" of the system with OOB applications? Etc... Etc... Etc... -- 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 Nov 30, 2007 12:02 PM, FRANK, GORDON CTR DISA JSSC <[EMAIL PROTECTED]> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Chris, > I haven't had trouble with forms. I've had trouble with Active Links. > Usually I break Als into two halves (A-H and I-Z). The reason I don't do > right down the middle is because the "H" (i.e. HPD:HelpDesk) has a large > quantity of Active Links. > > I also do them as separate chunks (Forms, 2 AL dumps and the rest of the > objects). Don't forget that a .def file is just a text file and you can > always put them back together if necessary (or pick and choose as > needed). > > Gordon M. Frank > DISA\Version FNS ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
I started an export ALL to .def file for one of my 7.1.00.001 servers a bit ago - the Admin tool (same patch level) is on an XP machine with 1gb RAM and is using 400 mb and peaks CPU to only 15% every minute. The servers: AR Server has run between 5% and 10% cpu almost continuously, with the separate SQL Server at 15% to 20% cpu continuously. Occasionally the AR Server will jump to 30% while the SQL Server drops to 0%, or the two will switch places. After 18 minutes the Admin Tool displayed an error "Malloc in client library failed (ARERR 154)" and declared the Export Complete. The exported file, however, is only 148 kb and has only 94 data visualization objects in it. Tried again on a Vista machine with 2 gb RAM - same patch level Admin Tool - this time it completed in about 15 minutes without any indication of an error, creating a 254 mb text file. The Data Visualization defs are at the very end of this file (they were the ONLY objects in the failed file). I tried loading this new file in the 7.1.00.001 Migrator and it loaded, although it issued an error at the end the file conversion process: There were errors while converting the AR System Definition File C:\~~\Remedy7ALL.def Error 9088 (missing rel op -- 1) Then it went on to Retrieve Objects and loaded 39,179 objects into a new .migrator file. Unfortunately, the source server has 39,372 objects when Migrator accesses it directly, so something in the exported file was still missing. I tried a second time and got the same error, but the final object count loaded from the same file was 39,181 (two more than the first time). If the Admin Tool cannot handle exporting all items on the server to def, or create a valid .def file when doing it, by the same token it probably cannot handle updating the search database for all items on the server. I guess they should have thought about that before building applications where the developers appear to have had a "pay by the object" model going for them. Christopher E. Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/helpdesk/ -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of J.T. Shyman Sent: Friday, November 30, 2007 10:11 AM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) I'd be curious to see what the load on both the database backend and the remedy server (and what processes are causing the load) is during such an export. If there isn't any discernable load on either then I'd say there is a defect in either the ARServer or the admin tool that is getting stuck in an endless loop. I've got a 7.1 system, with no ITSM apps loaded yet, on RHEL 4 on VMWare. Maybe I'll try an export and see what happens. J.T. Shyman Column Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Friday, November 30, 2007 11:02 AM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) Just so you know, I tried to export a form and All Related the other day. It was either the AST:People or the AST:AssetPeople form, I can't remember. But the export ran for about 30 minutes before I gave up and shut the admin tool down. And that was only exporting ONE form. Drew ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Chris,
I've been following this thread and I had the same issues, but have been
able to overcome the export definitions and Sync Search with various
versions of the 7.x Admin Tool. Perhaps your issue is related:
The Remedy database I inherited a few months ago had many issues. After
working through all the issues, the export definitions and Sync Search
runs relatively quickly on all our servers.
A brief list of the things I found that contributed to the inability to
sync or export definitions.
- Workflow that points to non-existent Hard Coded Server Reference
Names.
- Workflow that references non-existent fields, forms, groups or
other workflow.
- Damaged workflow. Sometimes opening the workflow in the latest
usertool and saving again fixes this one.
- Group ID's in the permissions of workflow/forms that reference
Non-existent Groups.
- Lot's of other similar issues that are too painful to recall.
ARERR 92 93 errors are the result, these seem to send the process into
limbo so it may not be able to finish. The arxref.log file in ARAdmin
directory shows many of these issues that contribute to the delays.
Hope this helps,
Scott.
FYI:
P R O B L E M
Is there a way to run the Admin Tool Sync Search Database from the
command line?
S O L U T I O N
There is a command line option that allows you to run the Tools >> Sync
Search Database outside of the Graphical User Interface (GUI). The the
Syntax is:
aradmin -x {Server Name} -u {User Name} -p {Password} -s (For Version
5.+
Sync Search Database is not a server function. It is an Remedy Admin
function. Remedy Admin issues API calls to the server, prepares the data
for the object_search_admin, object_search_details, and
object_search_ref forms, and creates entries within those forms. The
main processing is done in the Admin Tool.
The Sync Search Database runs in a separate thread leaving the Remedy
Admin available for other functions such as opening and working with
another AR objects. Because of the intensity of object crossreferencing,
AR Server performance becomes a concern. It is recommended that the
Synchronization be run during non-peak hours and with minimal
applications running on the client at the time when the synch is
started. When using the Admin tool on a system where physical memory is
scarce, it is recommended that the command line option be used instead
as it uses less memory.
The Sync Search Database log, called arxref.txt in 4.5.2 and 5.0.1,
arxref.log in 5.1, is located in the same directory as aradmin.exe.
=
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of strauss
Sent: Friday, November 30, 2007 10:32 AM
To: arslist@ARSLIST.ORG
Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED)
The last time I tried to export all to def the 7.1 Admin Tool crashed,
much as it does on any attempt to sync. I'll try again today with just
the forms, as you suggest.
Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center http://itsm.unt.edu/
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
> Sent: Friday, November 30, 2007 6:19 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED)
>
> Robert and Christopher,
>
> I have been watching this thread and wondering if you two(Robert and
> Chris) could do a test for me to find out if a "related problem" might
> be the root cause of your issues?
>
> I have observed on a v7.x server (with only Service Desk
> installed) that it is not capable of exporting all ARS objects at one
> time. Not even if you only try to export one object class at a time. I
> have reported this to BMC, they are saying "as designed". (Bullux if
> you ask me. Install an OOB application and suddenly a "feature of the
> system" stops working? How can that be "as designed"?) So I am
> wondering if this is the underlying issue with your abilities to not
> sync or partially sync the Search DB data?
>
> I have observed that if you enable API logs on the ARS server before
> you do an export operation that you will see that the Admin tool
> "times out" (after about 30 minutes, or was it 60
> minutes?) and the ARS server keeps on going for well over an hour (in
> my case) and the Admin Tool produces no file and looks to be "hung"
> from the time it times out and the time the ARS server stops doing
&
Re: Synch Search Database, UNIX (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Chris, I haven't had trouble with forms. I've had trouble with Active Links. Usually I break Als into two halves (A-H and I-Z). The reason I don't do right down the middle is because the "H" (i.e. HPD:HelpDesk) has a large quantity of Active Links. I also do them as separate chunks (Forms, 2 AL dumps and the rest of the objects). Don't forget that a .def file is just a text file and you can always put them back together if necessary (or pick and choose as needed). Gordon M. Frank DISA\Version FNS -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Friday, November 30, 2007 10:32 AM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) The last time I tried to export all to def the 7.1 Admin Tool crashed, much as it does on any attempt to sync. I'll try again today with just the forms, as you suggest. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Friday, November 30, 2007 6:19 AM > To: arslist@ARSLIST.ORG > Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) > > Robert and Christopher, > > I have been watching this thread and wondering if you two(Robert and > Chris) could do a test for me to find out if a "related problem" might > be the root cause of your issues? > > I have observed on a v7.x server (with only Service Desk > installed) that it is not capable of exporting all ARS objects at one > time. Not even if you only try to export one object class at a time. I > have reported this to BMC, they are saying "as designed". (Bullux if > you ask me. Install an OOB application and suddenly a "feature of the > system" stops working? How can that be "as designed"?) So I am > wondering if this is the underlying issue with your abilities to not > sync or partially sync the Search DB data? > > I have observed that if you enable API logs on the ARS server before > you do an export operation that you will see that the Admin tool > "times out" (after about 30 minutes, or was it 60 > minutes?) and the ARS server keeps on going for well over an hour (in > my case) and the Admin Tool produces no file and looks to be "hung" > from the time it times out and the time the ARS server stops doing > whatever it was asked to do. > > I would be very interested to know if either of you can do either of > the following: > 1) "Export All" ( All objects into one Def file in one pass) > 2) "Export" All of each class of ARS objects in to separate files (one > pass per object class: Form, Active Link, Filter, etc..) > If not which one(s) fail to export? > > My hypothesis is that Christopher might not be able to even export all > forms in one batch. > However Robert might be able to export all object classes except > Active Links. > > I just can not help but think that our problems could be related. > > -- > 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 Nov 30, 2007 4:53 AM, Robert Page <[EMAIL PROTECTED]> wrote: > > ** > > > > Hi > > > > I'm running a 7.0.1 patch 3 admin tool and our synch works, > not fully > > but it does do some form of sync, we leave a PC on and > start the sync, > > go home, come back in the morning to the message sync completed > > successfully, its best to have only the admin tool running > as we find > > it grabs loads of memory and loads of processor. > > > > The only problem we have found so far is that it does not > sync Active > > Links, not a single one, everything else seems fine but no > AL's. We > > are going to run it again and if we get the same result > we'll bug it. > > > > Cheers > > > > Robert > > On Thu, 29 Nov 2007, strauss wrote: > > > > > > I have had tickets open on this for 7.0.0.003 since June > 2007. The > > > main ticket was closed in an unresolved state and replaced with > > > another ticket for 7.1 GA in September 2007, which was > then closed > > > and a defect SW00276070 was created that still has not been fixed > > > even though its status is closed. That's as near as I can tell > > > aft
Re: Synch Search Database, UNIX (UNCLASSIFIED)
Just so you know, I tried to export a form and All Related the other day. It was either the AST:People or the AST:AssetPeople form, I can't remember. But the export ran for about 30 minutes before I gave up and shut the admin tool down. And that was only exporting ONE form. Drew ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
The last time I tried to export all to def the 7.1 Admin Tool crashed, much as it does on any attempt to sync. I'll try again today with just the forms, as you suggest. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Friday, November 30, 2007 6:19 AM > To: arslist@ARSLIST.ORG > Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) > > Robert and Christopher, > > I have been watching this thread and wondering if you two(Robert and > Chris) could do a test for me to find out if a "related > problem" might be the root cause of your issues? > > I have observed on a v7.x server (with only Service Desk > installed) that it is not capable of exporting all ARS > objects at one time. Not even if you only try to export one > object class at a time. I have reported this to BMC, they are > saying "as designed". (Bullux if you ask me. Install an OOB > application and suddenly a "feature of the system" stops > working? How can that be "as designed"?) So I am wondering if > this is the underlying issue with your abilities to not sync > or partially sync the Search DB data? > > I have observed that if you enable API logs on the ARS server > before you do an export operation that you will see that the > Admin tool "times out" (after about 30 minutes, or was it 60 > minutes?) and the ARS server keeps on going for well over an > hour (in my case) and the Admin Tool produces no file and > looks to be "hung" from the time it times out and the time > the ARS server stops doing whatever it was asked to do. > > I would be very interested to know if either of you can do > either of the following: > 1) "Export All" ( All objects into one Def file in one pass) > 2) "Export" All of each class of ARS objects in to separate > files (one pass per object class: Form, Active Link, Filter, etc..) > If not which one(s) fail to export? > > My hypothesis is that Christopher might not be able to even > export all forms in one batch. > However Robert might be able to export all object classes > except Active Links. > > I just can not help but think that our problems could be related. > > -- > 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 Nov 30, 2007 4:53 AM, Robert Page <[EMAIL PROTECTED]> wrote: > > ** > > > > Hi > > > > I'm running a 7.0.1 patch 3 admin tool and our synch works, > not fully > > but it does do some form of sync, we leave a PC on and > start the sync, > > go home, come back in the morning to the message sync completed > > successfully, its best to have only the admin tool running > as we find > > it grabs loads of memory and loads of processor. > > > > The only problem we have found so far is that it does not > sync Active > > Links, not a single one, everything else seems fine but no > AL's. We > > are going to run it again and if we get the same result > we'll bug it. > > > > Cheers > > > > Robert > > On Thu, 29 Nov 2007, strauss wrote: > > > > > > I have had tickets open on this for 7.0.0.003 since June > 2007. The > > > main ticket was closed in an unresolved state and replaced with > > > another ticket for 7.1 GA in September 2007, which was > then closed > > > and a defect SW00276070 was created that still has not been fixed > > > even though its status is closed. That's as near as I can tell > > > after retracing the steps through the labyrinth of > supportweb issue and defect displays. > > > There were even duplicate tickets for the same problem manifested > > > differently for 7.0.x and 7.1 beta along the way. I don't think > > > support is tracking this stuff correctly since they went to a > > > process of closing the ticket upon creating a defect. If > the defect > > > from my ticket was also closed, there is no way to tell if they > > > consolidated it into another defect, or addressed it in > some other > > > way. They sure as hell have NOT fixed it yet! > > > > > > Christopher Strauss, Ph.D. > > > Call Tracking Administration Manager University of North Texas > > > Computing & IT Center http://itsm.unt.edu/ > > __ > _ > 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: Synch Search Database, UNIX (UNCLASSIFIED)
Robert and Christopher, I have been watching this thread and wondering if you two(Robert and Chris) could do a test for me to find out if a "related problem" might be the root cause of your issues? I have observed on a v7.x server (with only Service Desk installed) that it is not capable of exporting all ARS objects at one time. Not even if you only try to export one object class at a time. I have reported this to BMC, they are saying "as designed". (Bullux if you ask me. Install an OOB application and suddenly a "feature of the system" stops working? How can that be "as designed"?) So I am wondering if this is the underlying issue with your abilities to not sync or partially sync the Search DB data? I have observed that if you enable API logs on the ARS server before you do an export operation that you will see that the Admin tool "times out" (after about 30 minutes, or was it 60 minutes?) and the ARS server keeps on going for well over an hour (in my case) and the Admin Tool produces no file and looks to be "hung" from the time it times out and the time the ARS server stops doing whatever it was asked to do. I would be very interested to know if either of you can do either of the following: 1) "Export All" ( All objects into one Def file in one pass) 2) "Export" All of each class of ARS objects in to separate files (one pass per object class: Form, Active Link, Filter, etc..) If not which one(s) fail to export? My hypothesis is that Christopher might not be able to even export all forms in one batch. However Robert might be able to export all object classes except Active Links. I just can not help but think that our problems could be related. -- 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 Nov 30, 2007 4:53 AM, Robert Page <[EMAIL PROTECTED]> wrote: > ** > > Hi > > I'm running a 7.0.1 patch 3 admin tool and our synch works, not fully but it > does do some form of sync, we leave a PC on and start the sync, go home, > come back in the morning to the message sync completed successfully, its > best to have only the admin tool running as we find it grabs loads of memory > and loads of processor. > > The only problem we have found so far is that it does not sync Active Links, > not a single one, everything else seems fine but no AL's. We are going to > run it again and if we get the same result we'll bug it. > > Cheers > > Robert > On Thu, 29 Nov 2007, strauss wrote: > > I have had tickets open on this for 7.0.0.003 since June 2007. The main > > ticket was closed in an unresolved state and replaced with another > > ticket for 7.1 GA in September 2007, which was then closed and a defect > > SW00276070 was created that still has not been fixed even though its > > status is closed. That's as near as I can tell after retracing the > > steps through the labyrinth of supportweb issue and defect displays. > > There were even duplicate tickets for the same problem manifested > > differently for 7.0.x and 7.1 beta along the way. I don't think support > > is tracking this stuff correctly since they went to a process of closing > > the ticket upon creating a defect. If the defect from my ticket was > > also closed, there is no way to tell if they consolidated it into > > another defect, or addressed it in some other way. They sure as hell > > have NOT fixed it yet! > > > > Christopher Strauss, Ph.D. > > Call Tracking Administration Manager > > University of North Texas Computing & IT Center > > http://itsm.unt.edu/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Synch Search Database, UNIX (UNCLASSIFIED)
I'd be curious to see what the load on both the database backend and the remedy server (and what processes are causing the load) is during such an export. If there isn't any discernable load on either then I'd say there is a defect in either the ARServer or the admin tool that is getting stuck in an endless loop. I've got a 7.1 system, with no ITSM apps loaded yet, on RHEL 4 on VMWare. Maybe I'll try an export and see what happens. J.T. Shyman Column Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Shuller Sent: Friday, November 30, 2007 11:02 AM To: arslist@ARSLIST.ORG Subject: Re: Synch Search Database, UNIX (UNCLASSIFIED) Just so you know, I tried to export a form and All Related the other day. It was either the AST:People or the AST:AssetPeople form, I can't remember. But the export ran for about 30 minutes before I gave up and shut the admin tool down. And that was only exporting ONE form. Drew ___ 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"
