date:20190823

RE: How to run a job on individual servers?

2019-08-23 Thread Theo Fondse

Hi Thomas,

Conny has a very good idea. If your organization’s security policies allow for 
it, it will work just fine.

If you wanted / were forced to use a more old-school AR System-based approach, 
you will need to create two dummy forms populated with a record for each server 
in the group and then trigger something like the driver program or arimport 
from a run process triggered by an escalation on Dummy Form 1. 

The driver/arimport then does a login to the individual server in the group and 
modify the record for that server on Dummy Form 2. 

This can then trigger workflow to execute locally on the intended server in the 
group to do what you want on that specific server.

See 
https://docs.bmc.com/docs/ars91/en/enabling-the-data-import-utility-609071980.html
 for info on running arimport (much easier than doing this with the driver 
program).

Best Regards,

Theo Fondse

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of 
conny.mar...@t-systems.com
Sent: Wednesday, 21 August, 2019 02:11 PM
To: arslist@arslist.org
Subject: AW: How to run a job on individual servers?

I would not recommend to run arsystem as root (from a security point of view) 
For ssh you can use whatever user you like, which has sufficient permissions to 
run your “licensetracker”. You’ll have to make sure, that the user running 
arsystem is able to do ssh to the target servers/user without the need of any 
password. (Public-Key Authentication)

KR Conny

Von: ARSList mailto:arslist-boun...@arslist.org> 
> Im Auftrag von Thomas Miskiewicz
Gesendet: Mittwoch, 21. August 2019 14:03
An: ARSList mailto:arslist@arslist.org> >
Betreff: Re: How to run a job on individual servers?

Fabulous idea. As which use shall I do the ssh? The system is running as root

On Wed 21. Aug 2019 at 13:46, mailto:conny.mar...@t-systems.com> > wrote:

Hi,

if you're on *x, you can do something like 

RUN-PROCESS ssh server1 /path/to/your/licensetracker
RUN-PROCESS ssh server2 /path/to/your/licensetracker
RUN-PROCESS ssh server3 /path/to/your/licensetracker

within an escalation. If escalations are running on server1 it will connect via 
ssh to itself, which does not really matter.

KR Conny

-Ursprüngliche Nachricht-
Von: ARSList mailto:arslist-boun...@arslist.org> 
> Im Auftrag von Thomas Miskiewicz
Gesendet: Mittwoch, 21. August 2019 13:21
An: ARSList mailto:arslist@arslist.org> >
Betreff: Re: How to run a job on individual servers?

We're collecting license information on each individual server reading the 
user.log I’m looking for a way to trigger the action on each individual server 
without having to use a cron job.

> On 21. Aug 2019, at 13:18, Tauf Chowdhury   > wrote:
> 
> Do you mean escalations? Also is this during a maintenance period or 
> scheduled outage? You could always bring up one server at a time and that way 
> you can ensure escalations are running on that server if you’re in a server 
> group with the failover configured. 
> 
> Sent from my iPhone
> 
>> On Aug 21, 2019, at 6:50 AM, Thomas Miskiewicz >  > wrote:
>> 
>> Hi there
>> 
>> we got three servers in the group and would like to collect information on 
>> every individual server. We did that in the past using a cron job but would 
>> prefer escalation which can be controlled by workflow. The problem is 
>> explanations run only on one of the three servers. Any idea how to trigger 
>> workflow on each individual server?
>> 
>> 
>> Thomas
>> -- 
>> ARSList mailing list
>> ARSList@arslist.org  
>> https://mailman.rrr.se/cgi/listinfo/arslist
> 
> -- 
> ARSList mailing list
> ARSList@arslist.org  
> https://mailman.rrr.se/cgi/listinfo/arslist

-- 
ARSList mailing list
ARSList@arslist.org  
https://mailman.rrr.se/cgi/listinfo/arslist

-- 
ARSList mailing list
ARSList@arslist.org  
https://mailman.rrr.se/cgi/listinfo/arslist

-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

RE: How to run a job on individual servers?

2019-08-23 Thread Andre, Jacques

Hi Thomas,

I wrote a workflow solution to this problem some time ago, and it still seems 
to work (Just tried it on 9.1.3)

It is basically one form with 2 escalations.

The following information is recorded in the form

  *   User Login Name
  *   License Name (AR User, Change , Incident … etc)
  *   License Type (Fixed, Floating, Read)
  *   Server Name (Server the user is logged into)
  *   Time Acquired (Time the license was acquired)
  *   Duration (How long the user has used the license (In Seconds))
  *   Status (Currently logged in or logged out)

More than happy to share this if it suites your needs.

Kind regards
Jacques Andre

From: ARSList  On Behalf Of Theo Fondse
Sent: 23 August 2019 10:11
To: 'ARSList' 
Subject: RE: How to run a job on individual servers?

Hi Thomas,

Conny has a very good idea. If your organization’s security policies allow for 
it, it will work just fine.

If you wanted / were forced to use a more old-school AR System-based approach, 
you will need to create two dummy forms populated with a record for each server 
in the group and then trigger something like the driver program or arimport 
from a run process triggered by an escalation on Dummy Form 1.
The driver/arimport then does a login to the individual server in the group and 
modify the record for that server on Dummy Form 2.
This can then trigger workflow to execute locally on the intended server in the 
group to do what you want on that specific server.

See 
https://docs.bmc.com/docs/ars91/en/enabling-the-data-import-utility-609071980.html
 for info on running arimport (much easier than doing this with the driver 
program).

Best Regards,

Theo Fondse

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of 
conny.mar...@t-systems.com
Sent: Wednesday, 21 August, 2019 02:11 PM
To: arslist@arslist.org
Subject: AW: How to run a job on individual servers?

I would not recommend to run arsystem as root (from a security point of view) 
For ssh you can use whatever user you like, which has sufficient permissions to 
run your “licensetracker”. You’ll have to make sure, that the user running 
arsystem is able to do ssh to the target servers/user without the need of any 
password. (Public-Key Authentication)

KR Conny
Von: ARSList mailto:arslist-boun...@arslist.org>> 
Im Auftrag von Thomas Miskiewicz
Gesendet: Mittwoch, 21. August 2019 14:03
An: ARSList mailto:arslist@arslist.org>>
Betreff: Re: How to run a job on individual servers?

Fabulous idea. As which use shall I do the ssh? The system is running as root

On Wed 21. Aug 2019 at 13:46, 
mailto:conny.mar...@t-systems.com>> wrote:
Hi,

if you're on *x, you can do something like

RUN-PROCESS ssh server1 /path/to/your/licensetracker
RUN-PROCESS ssh server2 /path/to/your/licensetracker
RUN-PROCESS ssh server3 /path/to/your/licensetracker

within an escalation. If escalations are running on server1 it will connect via 
ssh to itself, which does not really matter.

KR Conny

-Ursprüngliche Nachricht-
Von: ARSList mailto:arslist-boun...@arslist.org>> 
Im Auftrag von Thomas Miskiewicz
Gesendet: Mittwoch, 21. August 2019 13:21
An: ARSList mailto:arslist@arslist.org>>
Betreff: Re: How to run a job on individual servers?

We're collecting license information on each individual server reading the 
user.log I’m looking for a way to trigger the action on each individual server 
without having to use a cron job.

> On 21. Aug 2019, at 13:18, Tauf Chowdhury 
> mailto:taufc...@gmail.com>> wrote:
>
> Do you mean escalations? Also is this during a maintenance period or 
> scheduled outage? You could always bring up one server at a time and that way 
> you can ensure escalations are running on that server if you’re in a server 
> group with the failover configured.
>
> Sent from my iPhone
>
>> On Aug 21, 2019, at 6:50 AM, Thomas Miskiewicz 
>> mailto:tmisk...@gmail.com>> wrote:
>>
>> Hi there
>>
>> we got three servers in the group and would like to collect information on 
>> every individual server. We did that in the past using a cron job but would 
>> prefer escalation which can be controlled by workflow. The problem is 
>> explanations run only on one of the three servers. Any idea how to trigger 
>> workflow on each individual server?
>>
>>
>> Thomas
>> --
>> ARSList mailing list
>> ARSList@arslist.org
>> https://mailman.rrr.se/cgi/listinfo/arslist
>
> --
> ARSList mailing list
> ARSList@arslist.org
> https://mailman.rrr.se/cgi/listinfo/arslist

--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and m

DWP Question

2019-08-23 Thread Roger Justice via ARSList

My customer wants to use DWP as their end user portal to see what they have 
ordered and what open Incidents they have. I have not been able to find any 
documentation of how an Incident created in Remedy can be seen in DWP. I know 
that the Incident Rules allow a SRM SR to be created that allowed the user to 
see open Incident in SRM.

I have been working with DWP since May and have not gotten official training.

Has anyone implemented this?
Thanks
Roger Justice-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

DSO creating duplicates

2019-08-23 Thread Thomas Miskiewicz

Hello Listers

we transfer from Server A to B using DSO with the Option independent copy and 
overwrite if you find something.

So some reason DSO is trying to create a record twice, ignores the Overwrite 
instruction and violated the unique index on the Request ID

We’re using 9.1.001 201811140711

Any ideas?

LOG


  
 /* Fr Aug 16 2019 16:33:47.7550 */ UPDATE B88 SET 
B88.CC536870943 = NULL, B88.CO536870943 = NULL, B88.C536870943 = NULL, 
B88.CC536870944 = NULL, B88.CO536870944 = NULL, B88.C536870944 = NULL, 
B88.CC536870945 = NULL, B88.CO536870945 = NULL, B88.C536870945 = NULL WHERE 
(B88.C1 = '00020438')
  
 /* Fr Aug 16 2019 16:33:47.7680 */ +GE  
ARGetEntry -- schema P_BBK:Problem_Reporting entryId 00020441 from Mid-tier 
(protocol 24) at IP address 10.212.16.69 using RPC // :q:0.0s 
  
 /* Fr Aug 16 2019 16:33:47.7680 */ BEGIN TRANSACTION
  
 /* Fr Aug 16 2019 16:33:47.7700 */ Generating 
prepared statement
  
 /* Fr Aug 16 2019 16:33:47.7700 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7700 */ Binding [1] 
parameters to prepared statement
  
 /* Fr Aug 16 2019 16:33:47.7700 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7700 */ SELECT T88.C1, 
T88.C2, T88.C3, T88.C4, T88.C5, T88.C6, T88.C7, T88.C8, T88.C104, 
T88.C536870913, T88.C536870923, T88.C536870924, T88.C536870925, T88.C536870928, 
T88.C536870929, T88.C536870939, B88.C536870943, B88.CO536870943, 
B88.CC536870943, B88.C536870944, B88.CO536870944, B88.CC536870944, 
B88.C536870945, B88.CO536870945, B88.CC536870945, T88.C536870965, 
T88.C536870979, T88.C536871028, T88.C536871034, T88.C536871035, T88.C536871041, 
T88.C536871048, T88.C536871061, T88.C536871076, T88.C536871077, T88.C536871085, 
T88.C536871090, T88.C536871099, T88.C536871103, T88.C536871107, T88.C536871110, 
T88.C53687, T88.C536871122, T88.C536871123, T88.C536871130, T88.C536871138, 
T88.C536871149, T88.C536871172, T88.C536871180, T88.C536871186, T88.C536871189, 
T88.C536871201, T88.C536871206, T88.C536871212, T88.C536871213, T88.C536871215, 
T88.C536871216, T88.C536871217, T88.C536871218, T88.C536871219, T88.C536871229, 
T88.C536871240, T88.C536871242, T88.C536871243, T88.C536871244, T88.C536871245, 
T88.C536871249, T88.C536871250, T88.C536871253, T88.C536871254, T88.C536871257, 
T88.C536871258, T88.C536871259, T88.C536871263, T88.C536871264, T88.C536871268, 
T88.C536871269, T88.C536871271, T88.C536871273, T88.C536871274, T88.C536871275, 
T88.C536871276, T88.C536871277, T88.C536871280, T88.C536871284, T88.C536871306, 
T88.C536871307, T88.C536871308, T88.C536871310, T88.C536871314, T88.C536871315, 
T88.C536871316, T88.C536871317, T88.C536871318, T88.C536871319, T88.C536871323, 
T88.C536871325, T88.C536871329, T88.C536871330, T88.C536871331, T88.C536871332, 
T88.C536871338, T88.C536871340, T88.C536871341, T88.C536871343, T88.C536871344, 
T88.C536871345, T88.C536871346, T88.C536871347, T88.C536871354, T88.C536871355, 
T88.C536871358, T88.C536871359, T88.C536871360, T88.C536871361, T88.C536871362, 
T88.C536871363, T88.C536871364, T88.C536871365, T88.C536871366, T88.C536871367, 
T88.C536871368, T88.C536871369, T88.C536871370, T88.C536871371, T88.C536871372, 
T88.C536871373, T88.C536871374, T88.C536871375, T88.C536871376, T88.C536871380, 
T88.C536871381, T88.C536871382, T88.C536871385, T88.C536871387, T88.C536871388, 
T88.C536871390, T88.C536871391, T88.C536871392, T88.C536871393, T88.C536871394, 
T88.C536871419, T88.C536871423, T88.C536871426, T88.C536871429, T88.C536871430, 
T88.C536871431, T88.C536871432, T88.C536871433, T88.C536871435, T88.C536871436, 
T88.C536871437, T88.C536871438, T88.C536871439, T88.C536871440, T88.C536871442, 
T88.C536871453, T88.C536871454, T88.C536871455, T88.C536871457, T88.C536871459, 
T88.C536871462, T88.C536871489, T88.C536871490, T88.C536871491, T88.C536871492, 
T88.C536871493, T88.C536871494, T88.C536871495, T88.C536871496, T88.C536871497, 
T88.C536884259, T88.C536884288, T88.C536884289, T88.C536884502, T88.C536884503, 
T88.C536884504, H88.U0, H88.T0, H88.U1, H88.T1, H88.U2, H88.T2, H88.U3, H88.T3, 
H88.U4, H88.T4, H88.U5, H88.T5, H88.U6, H88.T6, H88.U7, H88.T7, H88.U8, H88.T8, 
H88.U9, H88.T9, H88.U10, H88.T10, H88.U11, H88.T11, H88.U12, H88.T12, H88.U13, 
H88.T13, H88.U14, H88.T14 FROM T88 LEFT JOIN B88 ON (T88.C1 = B88.C1) LEFT JOIN 
H88 ON (T88.C1 = H88.entryId) WHERE (T88.C1 = '00020441')
  
 /* Fr Aug 16 2019 16:33:47.7730 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7730 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7740 */Start der 
Filterverarbeitung (Phase 1) -- Vorgang - GET on P_BBK:Problem_Reporting - 
00020441
  
 /* Fr Aug 16 2019 16:33:47.7740 */  Prüfung läuft. "ESP_4.40_P_BBK_Problem_Reporting" (500)
  
 /* Fr Aug 16 2019 16:33:47.7740 */ --> Deaktiviert 
- Filter wird ignoriert.
  
 /* Fr Aug 16 2019 16:33:47.7740 */Ende der 
Filterverarbeitung (Phase 1) -- Vorgang - GET on P_BBK:Problem_Reporting - 
00020441
  
 /* Fr Aug 16 2019 16:33:47.7740 */ COMMIT 
TRANSACTION
  
 /* Fr Aug 16 2019 1

RE: DSO creating duplicates

2019-08-23 Thread Jeff Lockemy

Hi Thomas,

There were multiple issues that we had with DSO in 9.1.x that we had to work 
with BMC on.  They fixed them in later patch releases, so my recommendation 
would  be to get to either 9.1.3 or 9.1.4 with the latest service pack.  That 
should alleviate the issues that you are experiencing.

Best,
Jeff


-Original Message-
From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Thomas 
Miskiewicz
Sent: Friday, August 23, 2019 8:11 AM
To: ARSList 
Subject: DSO creating duplicates

Hello Listers

we transfer from Server A to B using DSO with the Option independent copy and 
overwrite if you find something.

So some reason DSO is trying to create a record twice, ignores the Overwrite 
instruction and violated the unique index on the Request ID

We’re using 9.1.001 201811140711

Any ideas?

LOG


  
 /* Fr Aug 16 2019 16:33:47.7550 */ UPDATE B88 SET 
B88.CC536870943 = NULL, B88.CO536870943 = NULL, B88.C536870943 = NULL, 
B88.CC536870944 = NULL, B88.CO536870944 = NULL, B88.C536870944 = NULL, 
B88.CC536870945 = NULL, B88.CO536870945 = NULL, B88.C536870945 = NULL WHERE 
(B88.C1 = '00020438')
  
 /* Fr Aug 16 2019 16:33:47.7680 */ +GE  
ARGetEntry -- schema P_BBK:Problem_Reporting entryId 00020441 from Mid-tier 
(protocol 24) at IP address 10.212.16.69 using RPC // :q:0.0s 
  
 /* Fr Aug 16 2019 16:33:47.7680 */ BEGIN TRANSACTION
  
 /* Fr Aug 16 2019 16:33:47.7700 */ Generating 
prepared statement
  
 /* Fr Aug 16 2019 16:33:47.7700 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7700 */ Binding [1] 
parameters to prepared statement
  
 /* Fr Aug 16 2019 16:33:47.7700 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7700 */ SELECT T88.C1, 
T88.C2, T88.C3, T88.C4, T88.C5, T88.C6, T88.C7, T88.C8, T88.C104, 
T88.C536870913, T88.C536870923, T88.C536870924, T88.C536870925, T88.C536870928, 
T88.C536870929, T88.C536870939, B88.C536870943, B88.CO536870943, 
B88.CC536870943, B88.C536870944, B88.CO536870944, B88.CC536870944, 
B88.C536870945, B88.CO536870945, B88.CC536870945, T88.C536870965, 
T88.C536870979, T88.C536871028, T88.C536871034, T88.C536871035, T88.C536871041, 
T88.C536871048, T88.C536871061, T88.C536871076, T88.C536871077, T88.C536871085, 
T88.C536871090, T88.C536871099, T88.C536871103, T88.C536871107, T88.C536871110, 
T88.C53687, T88.C536871122, T88.C536871123, T88.C536871130, T88.C536871138, 
T88.C536871149, T88.C536871172, T88.C536871180, T88.C536871186, T88.C536871189, 
T88.C536871201, T88.C536871206, T88.C536871212, T88.C536871213, T88.C536871215, 
T88.C536871216, T88.C536871217, T88.C536871218, T88.C536871219, T88.C536871229, 
T88.C536871240, T88.C536871242, T88.C536871243, T88.C536871244, T88.C536871245, 
T88.C536871249, T88.C536871250, T88.C536871253, T88.C536871254, T88.C536871257, 
T88.C536871258, T88.C536871259, T88.C536871263, T88.C536871264, T88.C536871268, 
T88.C536871269, T88.C536871271, T88.C536871273, T88.C536871274, T88.C536871275, 
T88.C536871276, T88.C536871277, T88.C536871280, T88.C536871284, T88.C536871306, 
T88.C536871307, T88.C536871308, T88.C536871310, T88.C536871314, T88.C536871315, 
T88.C536871316, T88.C536871317, T88.C536871318, T88.C536871319, T88.C536871323, 
T88.C536871325, T88.C536871329, T88.C536871330, T88.C536871331, T88.C536871332, 
T88.C536871338, T88.C536871340, T88.C536871341, T88.C536871343, T88.C536871344, 
T88.C536871345, T88.C536871346, T88.C536871347, T88.C536871354, T88.C536871355, 
T88.C536871358, T88.C536871359, T88.C536871360, T88.C536871361, T88.C536871362, 
T88.C536871363, T88.C536871364, T88.C536871365, T88.C536871366, T88.C536871367, 
T88.C536871368, T88.C536871369, T88.C536871370, T88.C536871371, T88.C536871372, 
T88.C536871373, T88.C536871374, T88.C536871375, T88.C536871376, T88.C536871380, 
T88.C536871381, T88.C536871382, T88.C536871385, T88.C536871387, T88.C536871388, 
T88.C536871390, T88.C536871391, T88.C536871392, T88.C536871393, T88.C536871394, 
T88.C536871419, T88.C536871423, T88.C536871426, T88.C536871429, T88.C536871430, 
T88.C536871431, T88.C536871432, T88.C536871433, T88.C536871435, T88.C536871436, 
T88.C536871437, T88.C536871438, T88.C536871439, T88.C536871440, T88.C536871442, 
T88.C536871453, T88.C536871454, T88.C536871455, T88.C536871457, T88.C536871459, 
T88.C536871462, T88.C536871489, T88.C536871490, T88.C536871491, T88.C536871492, 
T88.C536871493, T88.C536871494, T88.C536871495, T88.C536871496, T88.C536871497, 
T88.C536884259, T88.C536884288, T88.C536884289, T88.C536884502, T88.C536884503, 
T88.C536884504, H88.U0, H88.T0, H88.U1, H88.T1, H88.U2, H88.T2, H88.U3, H88.T3, 
H88.U4, H88.T4, H88.U5, H88.T5, H88.U6, H88.T6, H88.U7, H88.T7, H88.U8, H88.T8, 
H88.U9, H88.T9, H88.U10, H88.T10, H88.U11, H88.T11, H88.U12, H88.T12, H88.U13, 
H88.T13, H88.U14, H88.T14 FROM T88 LEFT JOIN B88 ON (T88.C1 = B88.C1) LEFT JOIN 
H88 ON (T88.C1 = H88.entryId) WHERE (T88.C1 = '00020441')
  
 /* Fr Aug 16 2019 16:33:47.7730 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7730 */ OK
  
 /* Fr Aug 16 2019 16:33:47.7740 */St

Re: DSO creating duplicates

2019-08-23 Thread Thomas Miskiewicz

Thank you for the quick reaction, Jeff. It’s interesting because I was looking 
Through the release notes today and hardly found anything regarding DSO...

I wish I could find something that would justify an upgrade...

> On 23. Aug 2019, at 17:27, Jeff Lockemy  wrote:
> 
> Hi Thomas,
> 
> There were multiple issues that we had with DSO in 9.1.x that we had to work 
> with BMC on.  They fixed them in later patch releases, so my recommendation 
> would  be to get to either 9.1.3 or 9.1.4 with the latest service pack.  That 
> should alleviate the issues that you are experiencing.
> 
> Best,
> Jeff
> 
> 
> -Original Message-
> From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Thomas 
> Miskiewicz
> Sent: Friday, August 23, 2019 8:11 AM
> To: ARSList 
> Subject: DSO creating duplicates
> 
> Hello Listers
> 
> we transfer from Server A to B using DSO with the Option independent copy and 
> overwrite if you find something.
> 
> So some reason DSO is trying to create a record twice, ignores the Overwrite 
> instruction and violated the unique index on the Request ID
> 
> We’re using 9.1.001 201811140711
> 
> Any ideas?
> 
> LOG
> 
> 
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7550 */ UPDATE B88 SET 
> B88.CC536870943 = NULL, B88.CO536870943 = NULL, B88.C536870943 = NULL, 
> B88.CC536870944 = NULL, B88.CO536870944 = NULL, B88.C536870944 = NULL, 
> B88.CC536870945 = NULL, B88.CO536870945 = NULL, B88.C536870945 = NULL WHERE 
> (B88.C1 = '00020438')
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7680 */ +GE  
> ARGetEntry -- schema P_BBK:Problem_Reporting entryId 00020441 from Mid-tier 
> (protocol 24) at IP address 10.212.16.69 using RPC // :q:0.0s 
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7680 */ BEGIN 
> TRANSACTION
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ Generating 
> prepared statement
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ OK
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ Binding [1] 
> parameters to prepared statement
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ OK
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ SELECT T88.C1, 
> T88.C2, T88.C3, T88.C4, T88.C5, T88.C6, T88.C7, T88.C8, T88.C104, 
> T88.C536870913, T88.C536870923, T88.C536870924, T88.C536870925, 
> T88.C536870928, T88.C536870929, T88.C536870939, B88.C536870943, 
> B88.CO536870943, B88.CC536870943, B88.C536870944, B88.CO536870944, 
> B88.CC536870944, B88.C536870945, B88.CO536870945, B88.CC536870945, 
> T88.C536870965, T88.C536870979, T88.C536871028, T88.C536871034, 
> T88.C536871035, T88.C536871041, T88.C536871048, T88.C536871061, 
> T88.C536871076, T88.C536871077, T88.C536871085, T88.C536871090, 
> T88.C536871099, T88.C536871103, T88.C536871107, T88.C536871110, 
> T88.C53687, T88.C536871122, T88.C536871123, T88.C536871130, 
> T88.C536871138, T88.C536871149, T88.C536871172, T88.C536871180, 
> T88.C536871186, T88.C536871189, T88.C536871201, T88.C536871206, 
> T88.C536871212, T88.C536871213, T88.C536871215, T88.C536871216, 
> T88.C536871217, T88.C536871218, T88.C536871219, T88.C536871229, 
> T88.C536871240, T88.C536871242, T88.C536871243, T88.C536871244, 
> T88.C536871245, T88.C536871249, T88.C536871250, T88.C536871253, 
> T88.C536871254, T88.C536871257, T88.C536871258, T88.C536871259, 
> T88.C536871263, T88.C536871264, T88.C536871268, T88.C536871269, 
> T88.C536871271, T88.C536871273, T88.C536871274, T88.C536871275, 
> T88.C536871276, T88.C536871277, T88.C536871280, T88.C536871284, 
> T88.C536871306, T88.C536871307, T88.C536871308, T88.C536871310, 
> T88.C536871314, T88.C536871315, T88.C536871316, T88.C536871317, 
> T88.C536871318, T88.C536871319, T88.C536871323, T88.C536871325, 
> T88.C536871329, T88.C536871330, T88.C536871331, T88.C536871332, 
> T88.C536871338, T88.C536871340, T88.C536871341, T88.C536871343, 
> T88.C536871344, T88.C536871345, T88.C536871346, T88.C536871347, 
> T88.C536871354, T88.C536871355, T88.C536871358, T88.C536871359, 
> T88.C536871360, T88.C536871361, T88.C536871362, T88.C536871363, 
> T88.C536871364, T88.C536871365, T88.C536871366, T88.C536871367, 
> T88.C536871368, T88.C536871369, T88.C536871370, T88.C536871371, 
> T88.C536871372, T88.C536871373, T88.C536871374, T88.C536871375, 
> T88.C536871376, T88.C536871380, T88.C536871381, T88.C536871382, 
> T88.C536871385, T88.C536871387, T88.C536871388, T88.C536871390, 
> T88.C536871391, T88.C536871392, T88.C536871393, T88.C536871394, 
> T88.C536871419, T88.C536871423, T88.C536871426, T88.C536871429, 
> T88.C536871430, T88.C536871431, T88.C536871432, T88.C536871433, 
> T88.C536871435, T88.C536871436, T88.C536871437, T88.C536871438, 
> T88.C536871439, T88.C536871440, T88.C536871442, T88.C536871453, 
> T88.C536871454, T88.C536871455, T88.C536871457, T88.C536871459, 
> T88.C536871462, T88.C536871489, T88.C536871490, T88.C536871491, 
> T88.C536871492, T88.C536871493, T88.C536871494, T88.C536871495, 
> T88.C536871496, T88.C536871497, T88.C536884259, T88.C536884288, 
> T88.C536884289, T88.C536884502, T88.C536884503, T88.C536884504

AW: DSO creating duplicates

2019-08-23 Thread Conny.Martin

We also had issues with DSO and ours was fixed with 9.1.07

KR Conny

-Ursprüngliche Nachricht-
Von: ARSList  Im Auftrag von Thomas Miskiewicz
Gesendet: Freitag, 23. August 2019 17:34
An: ARSList 
Betreff: Re: DSO creating duplicates

Thank you for the quick reaction, Jeff. It’s interesting because I was looking 
Through the release notes today and hardly found anything regarding DSO...

I wish I could find something that would justify an upgrade...

> On 23. Aug 2019, at 17:27, Jeff Lockemy  wrote:
> 
> Hi Thomas,
> 
> There were multiple issues that we had with DSO in 9.1.x that we had to work 
> with BMC on.  They fixed them in later patch releases, so my recommendation 
> would  be to get to either 9.1.3 or 9.1.4 with the latest service pack.  That 
> should alleviate the issues that you are experiencing.
> 
> Best,
> Jeff
> 
> 
> -Original Message-
> From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Thomas 
> Miskiewicz
> Sent: Friday, August 23, 2019 8:11 AM
> To: ARSList 
> Subject: DSO creating duplicates
> 
> Hello Listers
> 
> we transfer from Server A to B using DSO with the Option independent copy and 
> overwrite if you find something.
> 
> So some reason DSO is trying to create a record twice, ignores the Overwrite 
> instruction and violated the unique index on the Request ID
> 
> We’re using 9.1.001 201811140711
> 
> Any ideas?
> 
> LOG
> 
> 
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7550 */ UPDATE B88 SET 
> B88.CC536870943 = NULL, B88.CO536870943 = NULL, B88.C536870943 = NULL, 
> B88.CC536870944 = NULL, B88.CO536870944 = NULL, B88.C536870944 = NULL, 
> B88.CC536870945 = NULL, B88.CO536870945 = NULL, B88.C536870945 = NULL WHERE 
> (B88.C1 = '00020438')
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7680 */ +GE  
> ARGetEntry -- schema P_BBK:Problem_Reporting entryId 00020441 from Mid-tier 
> (protocol 24) at IP address 10.212.16.69 using RPC // :q:0.0s 
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7680 */ BEGIN 
> TRANSACTION
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ Generating 
> prepared statement
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ OK
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ Binding [1] 
> parameters to prepared statement
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ OK
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ SELECT T88.C1, 
> T88.C2, T88.C3, T88.C4, T88.C5, T88.C6, T88.C7, T88.C8, T88.C104, 
> T88.C536870913, T88.C536870923, T88.C536870924, T88.C536870925, 
> T88.C536870928, T88.C536870929, T88.C536870939, B88.C536870943, 
> B88.CO536870943, B88.CC536870943, B88.C536870944, B88.CO536870944, 
> B88.CC536870944, B88.C536870945, B88.CO536870945, B88.CC536870945, 
> T88.C536870965, T88.C536870979, T88.C536871028, T88.C536871034, 
> T88.C536871035, T88.C536871041, T88.C536871048, T88.C536871061, 
> T88.C536871076, T88.C536871077, T88.C536871085, T88.C536871090, 
> T88.C536871099, T88.C536871103, T88.C536871107, T88.C536871110, 
> T88.C53687, T88.C536871122, T88.C536871123, T88.C536871130, 
> T88.C536871138, T88.C536871149, T88.C536871172, T88.C536871180, 
> T88.C536871186, T88.C536871189, T88.C536871201, T88.C536871206, 
> T88.C536871212, T88.C536871213, T88.C536871215, T88.C536871216, 
> T88.C536871217, T88.C536871218, T88.C536871219, T88.C536871229, 
> T88.C536871240, T88.C536871242, T88.C536871243, T88.C536871244, 
> T88.C536871245, T88.C536871249, T88.C536871250, T88.C536871253, 
> T88.C536871254, T88.C536871257, T88.C536871258, T88.C536871259, 
> T88.C536871263, T88.C536871264, T88.C536871268, T88.C536871269, 
> T88.C536871271, T88.C536871273, T88.C536871274, T88.C536871275, 
> T88.C536871276, T88.C536871277, T88.C536871280, T88.C536871284, 
> T88.C536871306, T88.C536871307, T88.C536871308, T88.C536871310, 
> T88.C536871314, T88.C536871315, T88.C536871316, T88.C536871317, 
> T88.C536871318, T88.C536871319, T88.C536871323, T88.C536871325, 
> T88.C536871329, T88.C536871330, T88.C536871331, T88.C536871332, 
> T88.C536871338, T88.C536871340, T88.C536871341, T88.C536871343, 
> T88.C536871344, T88.C536871345, T88.C536871346, T88.C536871347, 
> T88.C536871354, T88.C536871355, T88.C536871358, T88.C536871359, 
> T88.C536871360, T88.C536871361, T88.C536871362, T88.C536871363, 
> T88.C536871364, T88.C536
871365, T88.C536871366, T88.C536871367, T88.C536871368, T88.C536871369, 
T88.C536871370, T88.C536871371, T88.C536871372, T88.C536871373, T88.C536871374, 
T88.C536871375, T88.C536871376, T88.C536871380, T88.C536871381, T88.C536871382, 
T88.C536871385, T88.C536871387, T88.C536871388, T88.C536871390, T88.C536871391, 
T88.C536871392, T88.C536871393, T88.C536871394, T88.C536871419, T88.C536871423, 
T88.C536871426, T88.C536871429, T88.C536871430, T88.C536871431, T88.C536871432, 
T88.C536871433, T88.C536871435, T88.C536871436, T88.C536871437, T88.C536871438, 
T88.C536871439, T88.C536871440, T88.C536871442, T88.C536871453, T88.C536871454, 
T88.C536871455, T88.C536871457, T88.C536871459, T88.C536871462, T88.C536871489, 
T88.C536871

RE: DSO creating duplicates

2019-08-23 Thread Jeff Lockemy

Hi Thomas,

Here are a couple of defect numbers for you:

SW00549254
SW00542850

You can search them under case management on the support website, and they may 
be referenced in some later release notes.

Cheers,
Jeff


-Original Message-
From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Thomas 
Miskiewicz
Sent: Friday, August 23, 2019 8:34 AM
To: ARSList 
Subject: Re: DSO creating duplicates

Thank you for the quick reaction, Jeff. It’s interesting because I was looking 
Through the release notes today and hardly found anything regarding DSO...

I wish I could find something that would justify an upgrade...

> On 23. Aug 2019, at 17:27, Jeff Lockemy  wrote:
> 
> Hi Thomas,
> 
> There were multiple issues that we had with DSO in 9.1.x that we had to work 
> with BMC on.  They fixed them in later patch releases, so my recommendation 
> would  be to get to either 9.1.3 or 9.1.4 with the latest service pack.  That 
> should alleviate the issues that you are experiencing.
> 
> Best,
> Jeff
> 
> 
> -Original Message-
> From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Thomas 
> Miskiewicz
> Sent: Friday, August 23, 2019 8:11 AM
> To: ARSList 
> Subject: DSO creating duplicates
> 
> Hello Listers
> 
> we transfer from Server A to B using DSO with the Option independent copy and 
> overwrite if you find something.
> 
> So some reason DSO is trying to create a record twice, ignores the Overwrite 
> instruction and violated the unique index on the Request ID
> 
> We’re using 9.1.001 201811140711
> 
> Any ideas?
> 
> LOG
> 
> 
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7550 */ UPDATE B88 SET 
> B88.CC536870943 = NULL, B88.CO536870943 = NULL, B88.C536870943 = NULL, 
> B88.CC536870944 = NULL, B88.CO536870944 = NULL, B88.C536870944 = NULL, 
> B88.CC536870945 = NULL, B88.CO536870945 = NULL, B88.C536870945 = NULL WHERE 
> (B88.C1 = '00020438')
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7680 */ +GE  
> ARGetEntry -- schema P_BBK:Problem_Reporting entryId 00020441 from Mid-tier 
> (protocol 24) at IP address 10.212.16.69 using RPC // :q:0.0s 
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7680 */ BEGIN 
> TRANSACTION
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ Generating 
> prepared statement
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ OK
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ Binding [1] 
> parameters to prepared statement
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ OK
> 
>   
>  /* Fr Aug 16 2019 16:33:47.7700 */ SELECT T88.C1, 
> T88.C2, T88.C3, T88.C4, T88.C5, T88.C6, T88.C7, T88.C8, T88.C104, 
> T88.C536870913, T88.C536870923, T88.C536870924, T88.C536870925, 
> T88.C536870928, T88.C536870929, T88.C536870939, B88.C536870943, 
> B88.CO536870943, B88.CC536870943, B88.C536870944, B88.CO536870944, 
> B88.CC536870944, B88.C536870945, B88.CO536870945, B88.CC536870945, 
> T88.C536870965, T88.C536870979, T88.C536871028, T88.C536871034, 
> T88.C536871035, T88.C536871041, T88.C536871048, T88.C536871061, 
> T88.C536871076, T88.C536871077, T88.C536871085, T88.C536871090, 
> T88.C536871099, T88.C536871103, T88.C536871107, T88.C536871110, 
> T88.C53687, T88.C536871122, T88.C536871123, T88.C536871130, 
> T88.C536871138, T88.C536871149, T88.C536871172, T88.C536871180, 
> T88.C536871186, T88.C536871189, T88.C536871201, T88.C536871206, 
> T88.C536871212, T88.C536871213, T88.C536871215, T88.C536871216, 
> T88.C536871217, T88.C536871218, T88.C536871219, T88.C536871229, 
> T88.C536871240, T88.C536871242, T88.C536871243, T88.C536871244, 
> T88.C536871245, T88.C536871249, T88.C536871250, T88.C536871253, 
> T88.C536871254, T88.C536871257, T88.C536871258, T88.C536871259, 
> T88.C536871263, T88.C536871264, T88.C536871268, T88.C536871269, 
> T88.C536871271, T88.C536871273, T88.C536871274, T88.C536871275, 
> T88.C536871276, T88.C536871277, T88.C536871280, T88.C536871284, 
> T88.C536871306, T88.C536871307, T88.C536871308, T88.C536871310, 
> T88.C536871314, T88.C536871315, T88.C536871316, T88.C536871317, 
> T88.C536871318, T88.C536871319, T88.C536871323, T88.C536871325, 
> T88.C536871329, T88.C536871330, T88.C536871331, T88.C536871332, 
> T88.C536871338, T88.C536871340, T88.C536871341, T88.C536871343, 
> T88.C536871344, T88.C536871345, T88.C536871346, T88.C536871347, 
> T88.C536871354, T88.C536871355, T88.C536871358, T88.C536871359, 
> T88.C536871360, T88.C536871361, T88.C536871362, T88.C536871363, 
> T88.C536871364, T88.C536871365, T88.C536871366, T88.C536871367, 
> T88.C536871368, T88.C536871369, T88.C536871370, T88.C536871371, 
> T88.C536871372, T88.C536871373, T88.C536871374, T88.C536871375, 
> T88.C536871376, T88.C536871380, T88.C536871381, T88.C536871382, 
> T88.C536871385, T88.C536871387, T88.C536871388, T88.C536871390, 
> T88.C536871391, T88.C536871392, T88.C536871393, T88.C536871394, 
> T88.C536871419, T88.C536871423, T88.C536871426, T88.C536871429, 
> T88.C536871430, T88.C536871431, T88.C536871432, T88.C536871433, 
> T88.C536871435, T88.C536871436, T88.C53687143

DON'T unsubscribe me

2019-08-23 Thread Sanford, Claire

Even though I don’t do Remedy any more, I would be lost without you  ☺



Besides when I figure out what to do with my “stuff”  I’ll share it here!  The 
suckers that left will have left too soon!
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: DON'T unsubscribe me

2019-08-23 Thread LJ LongWing


What kinda stuff?

On August 23, 2019 3:31:27 PM "Sanford, Claire" 
 wrote:

Even though I don’t do Remedy any more, I would be lost without you
J



Besides when I figure out what to do with my “stuff”  I’ll share it here!  
The suckers that left will have left too soon!

--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist


-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: DON'T unsubscribe me

2019-08-23 Thread Jason Miller

I wouldn't even think of it Claire. You are still part of the family.

Jason

On Fri, Aug 23, 2019 at 4:31 PM Sanford, Claire <
claire.sanf...@memorialhermann.org> wrote:

> Even though I don’t do Remedy any more, I would be lost without you  J
>
>
>
>
>
>
>
>
> Besides when I figure out what to do with my “stuff”  I’ll share it here!
> The suckers that left will have left too soon!
> --
> ARSList mailing list
> ARSList@arslist.org
> https://mailman.rrr.se/cgi/listinfo/arslist
>
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: DON'T unsubscribe me

2019-08-23 Thread Dave Shellman

Her Remedy stuff that’s hanging around for occasional searches.

Dave

On Fri, Aug 23, 2019 at 5:43 PM LJ LongWing  wrote:

> What kinda stuff?
>
> On August 23, 2019 3:31:27 PM "Sanford, Claire" <
> claire.sanf...@memorialhermann.org> wrote:
>
>> Even though I don’t do Remedy any more, I would be lost without you  J
>>
>>
>>
>>
>>
>>
>>
>>
>> Besides when I figure out what to do with my “stuff”  I’ll share it
>> here!  The suckers that left will have left too soon!
>>
> --
>> ARSList mailing list
>> ARSList@arslist.org
>> https://mailman.rrr.se/cgi/listinfo/arslist
>>
>>
> --
> ARSList mailing list
> ARSList@arslist.org
> https://mailman.rrr.se/cgi/listinfo/arslist
>
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

RE: DON'T unsubscribe me

2019-08-23 Thread Timothy Powell

I’m still hanging on to my Remedy mouse pads and coffee cups….

 

/tp

 

From: ARSList  On Behalf Of Dave Shellman
Sent: Friday, August 23, 2019 7:00 PM
To: ARSList 
Subject: Re: DON'T unsubscribe me

 

Her Remedy stuff that’s hanging around for occasional searches.

 

Dave

 

On Fri, Aug 23, 2019 at 5:43 PM LJ LongWing mailto:lj.longw...@gmail.com> > wrote:

What kinda stuff?

 

On August 23, 2019 3:31:27 PM "Sanford, Claire" 
mailto:claire.sanf...@memorialhermann.org> 
> wrote:

Even though I don’t do Remedy any more, I would be lost without you  :) 
   

 

 

 

Besides when I figure out what to do with my “stuff”  I’ll share it here!  The 
suckers that left will have left too soon!

-- 

ARSList mailing list

ARSList@arslist.org  

https://mailman.rrr.se/cgi/listinfo/arslist

 

 

-- 
ARSList mailing list
ARSList@arslist.org  
https://mailman.rrr.se/cgi/listinfo/arslist

-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: DON'T unsubscribe me

2019-08-23 Thread jortega999 .

Yeah, I'm about to join the ex-Remedy club as my employer is about to get
SNOWblinded next month. It's been a 15 year journey, but I refuse to let go
of the ARSlist, like Claire.
If any of you need anybody that needs an old Remedy guy in Texas, please
let me know.
Remedy Jesus

On Fri, Aug 23, 2019, 6:26 PM Timothy Powell <
timothy.pow...@pbs-consulting.com> wrote:

> I’m still hanging on to my Remedy mouse pads and coffee cups….
>
>
>
> /tp
>
>
>
> *From:* ARSList  *On Behalf Of *Dave Shellman
> *Sent:* Friday, August 23, 2019 7:00 PM
> *To:* ARSList 
> *Subject:* Re: DON'T unsubscribe me
>
>
>
> Her Remedy stuff that’s hanging around for occasional searches.
>
>
>
> Dave
>
>
>
> On Fri, Aug 23, 2019 at 5:43 PM LJ LongWing  wrote:
>
> What kinda stuff?
>
>
>
> On August 23, 2019 3:31:27 PM "Sanford, Claire" <
> claire.sanf...@memorialhermann.org> wrote:
>
> Even though I don’t do Remedy any more, I would be lost without you  J
>
>
>
>
>
>
>
>
> Besides when I figure out what to do with my “stuff”  I’ll share it here!
> The suckers that left will have left too soon!
>
> --
>
> ARSList mailing list
>
> ARSList@arslist.org
>
> https://mailman.rrr.se/cgi/listinfo/arslist
>
>
>
>
>
> --
> ARSList mailing list
> ARSList@arslist.org
> https://mailman.rrr.se/cgi/listinfo/arslist
>
> --
> ARSList mailing list
> ARSList@arslist.org
> https://mailman.rrr.se/cgi/listinfo/arslist
>
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

RE: How to run a job on individual servers?

RE: How to run a job on individual servers?

DWP Question

DSO creating duplicates

RE: DSO creating duplicates

Re: DSO creating duplicates

AW: DSO creating duplicates

RE: DSO creating duplicates

DON'T unsubscribe me

Re: DON'T unsubscribe me

Re: DON'T unsubscribe me

Re: DON'T unsubscribe me

RE: DON'T unsubscribe me

Re: DON'T unsubscribe me

14 matches

Site Navigation

Mail list logo

Footer information