Re: [foxboro] Starting Script at Windows System Startup
- From: Ted Jirik <ted.jirik@xxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 5 Dec 2012 07:59:52 -0900
I did that but found it takes some time for the IA services to initialize. I
wound up checking the running processes to verify that foxview was running
before trying to use IA resources within my service.
Ted
On Dec 5, 2012, at 5:49 AM, "William C Ricker" <wcricker@xxxxxxxxxxxxxxx> wrote:
> Yes, hadn't thought of that.
> Thx
>
> William C Ricker
> FeedForward, Inc.
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of Johnson, Alex P (IOM)
> Sent: Wednesday, December 05, 2012 9:41 AM
> To: 'foxboro@xxxxxxxxxxxxx'
> Subject: Re: [foxboro] Starting Script at Windows System Startup
>
> You could make your service dependent on the I/A Series services so that it
> starts up after the I/A Series software does.
> Regards,
>
> Alex Johnson
> Invensys Operations Management
> 10900 Equity Drive
> Houston, TX 77041
> +1 713 329 8472 (desk)
> +1 713 329 1600 (operator)
> +1 713 329 1700 (Central Fax)
> alex.johnson@xxxxxxxxxxxx
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of William C Ricker
> Sent: Wednesday, December 05, 2012 9:35 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Starting Script at Windows System Startup
>
> Thanks, and yes, that would work. However, I was looking for the "preferred"
> method. The software I'm writing is going into a system I don’t control, and
> likely will go into other systems down the road. Therefore I should use
> methods which will be clear to whoever maintains that system in future, and
> particularly should be clear to any Foxboro service guy who may in future
> upgrade the system.
>
> For me the downside of using fox_apps.dat is that the service guy may never
> look for something non-standard there, and if there is an upgrade, or even a
> system definition change, that file may be overwriten.
>
> On the other hand, using the startup folder or a registry edit, or even the
> Windows task scheduler all have the disadvantage of running on any startup,
> while I want this to run only if IA is running. Writing a service shares
> this problem. In each case I'd have to include code to see if IA is on, and
> exit if it isn't.
>
> William C Ricker
> FeedForward, Inc.
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of QUEIROLO, IGNACIO ESTEBAN
> Sent: Tuesday, December 04, 2012 10:21 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Starting Script at Windows System Startup
>
> If you want to run the script at the IA startup, I think you can do it if you
> add a line to the file /usr/fox/bin/fox_apps.dat. If you put the line
> MYSCRIPT at the end of this file, then you have to create the file
> go_MYSCRIPT.ksh in order to be processed at the startup. The file
> go_MYSCRIPT.ksh is your script. I use this to start the DMCplus controller
> and it works fine.
> If you want to run the script at the Windows startup, then you can do it
> using the registry or the startup menu. In this case, I think you should use
> a bat file or a cmd file.
>
> -----Mensaje original-----
> De: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] En
> nombre de William C Ricker
> Enviado el: Martes, 04 de Diciembre de 2012 20:20
> Para: foxboro@xxxxxxxxxxxxx
> Asunto: [foxboro] Starting Script at Windows System Startup
>
> Question of the day; What is the preferred method of starting a script at
> Windows system startup ?
> (in UNIX it was /etc/fox/user_apps.dat)
>
>
>
> William C Ricker
>
> FeedForward, Imc.
>
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
