RE: (forte-users) FORTE_ROOT environment variable

Simply :
myVar : string = ${forte_root};
It works in the current partition, if you want to know about variables
in another partition or
another machine, you'll have to use the
task.part.operatingsystem.GetEnv() syntax.
Patrice BOURDON
Alliance Sante France
ZIAP Chtx-Deols - BP 30
Place Marcel Dassault
31630 DEOLS
FRANCE
e-mail: mailto:[email protected]
web : http://www.alliance-sante.fr

Dear Jane,
In order to see the new value of the environment variable you have to
reboot your forte, or it is also possible to write a simple forte program
which sets the environment variable (SetEnv), in this case you can change the
value without rebooting.
Best Regards,
Tamas Deak
Jane Patterson wrote:
Dear Forte Users,
I am using a Windows 95 machine running Forte 30G2 and I am trying to get
the value of FORTE_ROOT within a method so I can create the full path and
name for the applications helpfile. I have tried many, many ways to get
the value out of this environment variable, but with no joy!
All ideas or samples will be welcome.
Thanks,
Jane Patterson
Jane Patterson
Analyst/Programmer, Administrative Technology Services
P.O. Box 56, University of Otago
Dunedin, New Zealand
Business Phone: +64 (0)3 479 8286
Business Fax : +64 (0)3 479 5080
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
Tamas Deak
Lufthansa Systems Hungary
(forte developer)
2-6 Mazsa ter, Budapest, 1107, HUNGARY
(36-1) 4312 973
[email protected]
[email protected][email protected]-

Similar Messages

Re: (forte-users) Same Environment variables?

If you will be connecting the environments in the
future, then you will need to make sure that the
environment names are unique. Both the Name Server
Addresses and the Environment Names need to be unique
in connected environments.
Mark Musgrove
Senior Consultant
Object Technologies, Inc
(540) 977-3861 (home)
(540) 977-2794 (fax)
http://shopping.yahoo.com/

If you will be connecting the environments in the
future, then you will need to make sure that the
environment names are unique. Both the Name Server
Addresses and the Environment Names need to be unique
in connected environments.
Mark Musgrove
Senior Consultant
Object Technologies, Inc
(540) 977-3861 (home)
(540) 977-2794 (fax)
http://shopping.yahoo.com/

FORTE_ROOT environment variable

Dear Forte Users,
I am using a Windows 95 machine running Forte 30G2 and I am trying to get
the value of FORTE_ROOT within a method so I can create the full path and
name for the applications helpfile. I have tried many, many ways to get
the value out of this environment variable, but with no joy!
All ideas or samples will be welcome.
Thanks,
Jane Patterson
Jane Patterson
Analyst/Programmer, Administrative Technology Services
P.O. Box 56, University of Otago
Dunedin, New Zealand
Business Phone: +64 (0)3 479 8286
Business Fax : +64 (0)3 479 5080

Dear Jane,
In order to see the new value of the environment variable you have to
reboot your forte, or it is also possible to write a simple forte program
which sets the environment variable (SetEnv), in this case you can change the
value without rebooting.
Best Regards,
Tamas Deak
Jane Patterson wrote:
Dear Forte Users,
I am using a Windows 95 machine running Forte 30G2 and I am trying to get
the value of FORTE_ROOT within a method so I can create the full path and
name for the applications helpfile. I have tried many, many ways to get
the value out of this environment variable, but with no joy!
All ideas or samples will be welcome.
Thanks,
Jane Patterson
Jane Patterson
Analyst/Programmer, Administrative Technology Services
P.O. Box 56, University of Otago
Dunedin, New Zealand
Business Phone: +64 (0)3 479 8286
Business Fax : +64 (0)3 479 5080
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
Tamas Deak
Lufthansa Systems Hungary
(forte developer)
2-6 Mazsa ter, Budapest, 1107, HUNGARY
(36-1) 4312 973
[email protected]
[email protected][email protected]-

How does java access user specific environment variables ?

Hi,
I'm running a java application on a W2K o/s. My application needs to be able to access the user environment variables in Windows but I don't know how to do this. Can anyone help ?
Thanks.

http://www.rgagnon.com/javadetails/java-0150.html

Getting the value of a user defined environment variable

hi,
i have an environment variable called MY_PATH='E:\data'
I am running a batch file which sets the value of this variable. Then i run my java program. Now from my java program i want the value of the variable MY_PATH. How do i get it?

See http://developer.java.sun.com/developer/bugParade/bugs/4199068.html and http://developer.java.sun.com/developer/bugParade/bugs/4642629.html
You can pass the value into the Java program as:
$ java -DMY_PATH="E:\data" YourJavaProgram
HTH,
Binil

Same Environment variables?

Hi,
I am creating two environments with two different versions of Forte on
same server, can we keep all the environment variables same except port
number. Will this create problems in future if we have to connect the
environments? As usual your help is appreciated. Thanks.
Sanjeev Arab

It shouldn't be a problem to share environment variables between environments.
But, you may run into variable-dependency problems very quickly like, for e.g.,
FORTE_ROOT, FORTE_NS_ADDRESS, FORTE_GC_SPECIAL which you may want to have
different values in each environment. Not to mention that it's even more
confusing when the same application is running in two different environments and
expecting different values in some application-specific variables on the same
machine.
You are better off by launching the environments with two different logins on
the same machine. This would reduce the interdepedencies.
Hope this helps.
Jagadish
Sanjeev J Arab <arabsdteenergy.com> on 11/09/2000 07:24:57
To: forte-users <forte-userslists.xpedior.com>
cc:
Fax to:
Subject: (forte-users) Same Environment variables?
Hi,
I am creating two environments with two different versions of Forte on
same server, can we keep all the environment variables same except port
number. Will this create problems in future if we have to connect the
environments? As usual your help is appreciated. Thanks.
Sanjeev Arab
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: forte-users-digest V1 #1490

Jim -
We had the same issues when we were running multiple production
environments.
The best way to handle the logging of application exceptions from multiple
environments, is to use a database.
Plus the database allows for easier reporting.
Give us a call if you'd like to discuss.
Larry McCartney
[email protected]
(203)459-7959 - Trumbull
From:
[email protected][SMTP:[email protected]
om]
Sent: Monday, June 07, 1999 6:00 PM
To: [email protected]
Subject: forte-users-digest V1 #1490
forte-users-digest Monday, 7 June 1999 Volume 01 : Number
1490
In this issue:
Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
Off topic: Database Unique IDs
From: "Field, Jim" <[email protected]>
Date: Mon, 7 Jun 1999 09:49:07 -0700
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing environments installed
on
a Unix box and a development environment on a Windows NT box. For our
error
handling, we write messages to a custom log file. If an error occurs on a
service object, the error message is written to a copy of this log file on
the client as well as to a copy of the file on the server where the
service
object is running. Currently, the path to the file begins with the
FORTE_ROOT environment variable and then the specific path is concatenated
to the end of the path. However, when trying to write the log file to the
Unix box, the application seems to be getting confused between the paths
for
the different environments and hangs. Does anyone know of a good way to
manage paths for writing files to multiple server environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Lopez, Len CWT-MSP" <[email protected]>
Date: Mon, 7 Jun 1999 13:34:33 -0500
Subject: RE: Multiple Forte environments on one machine
The environment variable $FORTE_ROOT will be the value you exported =
when you
started the environment on the unix server. This is usually specified =
in
your fortedef.sh (csh). It will not get confused between environments =
since
your application is only deployed to one environment and that =
environment
has only one value for FORTE_ROOT. The problem you are more likely =
having
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are =
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Fort=E9 portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 12:56:19 PDT
Subject: RE: Multiple Forte environments on one machine
An alternative solution could be, define different environment variables
in
the fortedef.sh shell script which will avoid confusion in refering to the
FORTE ROOT directories for the respective environments.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 13:02:28 PDT
Subject: RE: Multiple Forte environments on one machine
More over, my line of thinking is that once you are able to open the file
in
the appropriate mode, the problem could also attribute to disk space
availability, as you have mentioned that it hangs while writing to the
file!!
Quote :
However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs.Unquote.
Hope this helps.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Duncan Kinnear" <[email protected]>
Date: Tue, 8 Jun 1999 09:26:56 +1200
Subject: Off topic: Database Unique IDs
Hi folks,
This is a little off-topic, but I figure that there may be other people
out
there whose Forte development would benefit from the discussion.
I am currently building a development framework for our new software
product. As part of that framework I'd like to include the facility for
generating unique, user-invisible, integer database IDs.
Now there is some doubt here that this is actually required and that the
primary key should be whatever the programmer wants it to be, including
multiple columns if necessary.
I was wondering if anyone can give us some rules-of-thumb regarding
the use of unique IDs as primary keys. Or if someone can point me to
some on-line resources (or even a good book) that can guide us in this
area.
The arguments I have given for using integer IDs are:
- - Single, integer columns should be faster
- - User invisible integer ID allows editing/duplicates of all
user-visible fields
- - Single, integer foreign keys would reduce storage requirements
- - Standardising on integer IDs would allow generic functionality built
into
framework
- - More object-oriented as objects have "built-in" unique identity
I would appreciate any comments people have. We can take this
discussion off-list if that is preferable.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369
Providing Integrated Software to the Meat Processing Industry for over 10
years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
End of forte-users-digest V1 #1490
To unsubscribe, email '[email protected]' with
'unsubscribe $LIST' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Jim -
We had the same issues when we were running multiple production
environments.
The best way to handle the logging of application exceptions from multiple
environments, is to use a database.
Plus the database allows for easier reporting.
Give us a call if you'd like to discuss.
Larry McCartney
[email protected]
(203)459-7959 - Trumbull
From:
[email protected][SMTP:[email protected]
om]
Sent: Monday, June 07, 1999 6:00 PM
To: [email protected]
Subject: forte-users-digest V1 #1490
forte-users-digest Monday, 7 June 1999 Volume 01 : Number
1490
In this issue:
Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
Off topic: Database Unique IDs
From: "Field, Jim" <[email protected]>
Date: Mon, 7 Jun 1999 09:49:07 -0700
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing environments installed
on
a Unix box and a development environment on a Windows NT box. For our
error
handling, we write messages to a custom log file. If an error occurs on a
service object, the error message is written to a copy of this log file on
the client as well as to a copy of the file on the server where the
service
object is running. Currently, the path to the file begins with the
FORTE_ROOT environment variable and then the specific path is concatenated
to the end of the path. However, when trying to write the log file to the
Unix box, the application seems to be getting confused between the paths
for
the different environments and hangs. Does anyone know of a good way to
manage paths for writing files to multiple server environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Lopez, Len CWT-MSP" <[email protected]>
Date: Mon, 7 Jun 1999 13:34:33 -0500
Subject: RE: Multiple Forte environments on one machine
The environment variable $FORTE_ROOT will be the value you exported =
when you
started the environment on the unix server. This is usually specified =
in
your fortedef.sh (csh). It will not get confused between environments =
since
your application is only deployed to one environment and that =
environment
has only one value for FORTE_ROOT. The problem you are more likely =
having
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are =
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Fort=E9 portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 12:56:19 PDT
Subject: RE: Multiple Forte environments on one machine
An alternative solution could be, define different environment variables
in
the fortedef.sh shell script which will avoid confusion in refering to the
FORTE ROOT directories for the respective environments.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 13:02:28 PDT
Subject: RE: Multiple Forte environments on one machine
More over, my line of thinking is that once you are able to open the file
in
the appropriate mode, the problem could also attribute to disk space
availability, as you have mentioned that it hangs while writing to the
file!!
Quote :
However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs.Unquote.
Hope this helps.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Duncan Kinnear" <[email protected]>
Date: Tue, 8 Jun 1999 09:26:56 +1200
Subject: Off topic: Database Unique IDs
Hi folks,
This is a little off-topic, but I figure that there may be other people
out
there whose Forte development would benefit from the discussion.
I am currently building a development framework for our new software
product. As part of that framework I'd like to include the facility for
generating unique, user-invisible, integer database IDs.
Now there is some doubt here that this is actually required and that the
primary key should be whatever the programmer wants it to be, including
multiple columns if necessary.
I was wondering if anyone can give us some rules-of-thumb regarding
the use of unique IDs as primary keys. Or if someone can point me to
some on-line resources (or even a good book) that can guide us in this
area.
The arguments I have given for using integer IDs are:
- - Single, integer columns should be faster
- - User invisible integer ID allows editing/duplicates of all
user-visible fields
- - Single, integer foreign keys would reduce storage requirements
- - Standardising on integer IDs would allow generic functionality built
into
framework
- - More object-oriented as objects have "built-in" unique identity
I would appreciate any comments people have. We can take this
discussion off-list if that is preferable.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369
Providing Integrated Software to the Meat Processing Industry for over 10
years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
End of forte-users-digest V1 #1490
To unsubscribe, email '[email protected]' with
'unsubscribe $LIST' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Environment variables of Winnt winxp

I wanna set Environment variables of Winnt or winxp thro' Java

Actually, if you can get access to the registry, you can view/set the user's environment variables at
HKEY_CURRENT_USER\Environment
and the system environment variables at
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Evironment
Note that this is specific to Windows NT 4.0, there's no guarantee that they will be in the same location on other flavours of Windows. Note further that this will certainly work only on Windows machines... there is (AFAIK) no standard way to set environment variables for Linux, BSD or Solaris systems.
For the particularly brave (or stupid, or both :-), there is a beta(/alpha) registry interface for Java
http://www.algorekiss.com/wsnE682.html

Sapcheck environment variable

brconnect jobs in DB13 are failing. The job log gives me a pretty good indication why:
BR0252E Function fopen() failed for '/oracle/BBS/920_64/sapcheck/cdwcvtyd.sta' at location main-9
BR0253E errno 2: No such file or directory
From this, it appears that it is trying to access the log in the wrong directory (oracle/BBS/920_64) - not /oracle/BBS/sapcheck.
Documentation suggests setting the SAPCHECK environment variable to accomplish this. However, we have not tried this since we would like to understand how / why / where this errant setting setting got there. Also, we are assuming that if we do add this variable it needs to be added for the <SIDADM> user - is that accurate?
In addition, this is a "stage" system that should be configured identically to the DEV system which is working. We also have several other ancillary systems that are functioning as expected - which again, makes us hesitant to just add the "band-aid" solution of an environment variable.

Jeff,
To answer your question regarding which user's environment variables are used: When you run jobs from db13, the executables are being called from sidadm. However, depending on the permissions and ownership that the executable that is called has, the process can be run by orasid as well. So, if you call something from db13 , it starts with sidadm, but if the executable is owned by orasid and the s flag is set instead of x on the permissions, it will run with orasid. Maybe this is why the ORACLE_HOME is picked up instead of SAPDATA_HOME?
These are my permissions, which work fine in 5 installations we have here. Maybe you can run saproot.sh as root (this is under /sapmnt/SID/exe ) as root:
./saproot.sh SID
and the correct permissions will be set
-rwsrwxr-x   1 oraprd   sapsys   4898192 Jan 21 2007 brarchive
-rwsrwxr-x   1 oraprd   sapsys   5042888 Jan 21 2007 brbackup
-rwsrwxr-x   1 oraprd   sapsys   6622328 Jan 21 2007 brconnect
-rwxr-xr-x   1 prdadm   sapsys   5409416 Jan 21 2007 brrecover
-rwxr-xr-x   1 prdadm   sapsys   2132496 Jan 21 2007 brrestore
-rwxr-xr-x   1 prdadm   sapsys   6817944 Jan 21 2007 brspace
-rwsrwxr-x   1 oraprd   sapsys   2758224 Jan 21 2007 brtools
Ensure that the brtools, brspace, brconnect etc executables in the system where you have the issue have exactly the same ownership /permissions with the system where everything works fine. Pay particular attention that the "set user id on execution" bits or flags are correctly set (the S instad of x ) (rwsr_xr_x)
I hope this helps
Andreas

RCP, Environment Variables, OS X, Info.plist and LSEnvironment

I've got a somewhat challenging problem here.
I've got an RCP application that relies upon some shared dynamic libraries which might not be in standard locations (as this is OS X and they are user installed).
One of the things we need to configure is DYLD_LIBRARY_PATH in order for the shared libraries be discovered. The problem here is OS X doesn't have a simple way to set environment variables that applications launched from the Finder can "see".
One of the thing that I've found, but not had any success with, is to dynamically modify the RCP's Info.plist to have an additional key LSEnvironment whose value is a dictionary to set environment variables only visible to that application - okay this seems ideal for me. But it's not working.
I also found that I could use launchctl setenv to set a user global Environment variable, however it's not persistent across launches, and each time I set, I must restart the app. I really need this persistent.
Does anyone have any solution for setting Environment variables that are visible from the RCP app (and it's children) that works in OS X without having to launch the RCP app from a terminal?
Thanks in advance!

Brian de Alwis wrote on Wed, 05 August 2015 19:54Sounds like you want to use System.loadLibrary() with absolute paths?
That doesn't quite work, as we aren't using JNI. Unfortunately the use-case details get pretty complicated - so I omitted in an effort to make it simpler to understand the problem.
Basically we have built an IDE that uses the Prolog interpreter, XSB. XSB natively connects to MySQL using the shared MySQL libs. Unfortunately on OS X, MySQL can get installed into possibly one of many locations, and it certainly doesn't install it's libs in /usr/local/lib or /usr/lib. We access XSB via a Java library called Interprolog, which I believe, is just a pipe interface to the command line shell - hence when the Interprolog engine object is instantiated, it fires up a shell process for XSB - which needs to locate those MySQL libraries. Hence, DYLD_LIBRARY_PATH needs to be set to have the path for /usr/local/mysql/lib (or wherever the user installed it) defined in the parent process in order for Interprolog's sub-process to pick up the environment variable.
Right now there are only 2 reliables ways I have found to get this to work.
1. Launch Terminal, export the environment variable. Then launch our RCP app from the Terminal. - cumbersome and unintuitive; bad user experience.
2. Launch Terminal, use `launchctl setenv DYLD_LIBRARY_PATH /usr/local/mysql/lib`. And then one can lacuna our RCP app using Finder. - problem is that DYLD_LIBRARY_PATH is now global to the environment and will not persist between reboots.
I've tried added the LSEnvironment dictionary to the Info.plist within the RCP application, but that just doesn't seem to work - and I'm not sure if that is because the OS X eclipse launcher doesn't propagate the environment forward or what. For the time being I have a way for the user to click a button which runs launchctl setenv and then prompts the user to exit the app, and then launch again from finder [IWorkbench.restart() doesn't work because new process is a child of the current] - which works but is undesirable workflow as it doesn't persist across a login/reboot.
My next step is to try what is outlined here: http://stackoverflow.com/questions/829749/launch-mac-eclipse-with-environment-variables-set
However it feels even more sketchy than just modifying the Info.plist to contain the right environment variables.

RE: (forte-users) FW: central environment hanging

Doug,
We have our repository servers on Windows NT 4.0 (Alpha), however our
environment manager is on the same node as the repository servers, so our
experiences may not fit your case.
We use Windows NT services to start/stop the repository servers and have
defined them to start up as the appropriate Windows NT account so that its
registry is populated properly.
We use the Schedule service via WinAT for our nightly cleanups. We use the
Forte srvcinst.exe utility to shutdown the repository server before running
a batch script to perform the rpclean before starting up the repository
server within the same srvcinst.exe session.
We have never experienced environment console hangs, however this technique
doesn't cope with people leaving repository sessions active overnight as
rpstop -k would.
Sample srvcinst.exe Script
%FORTE_ROOT%\bin\srvcinst.exe
SetName "<Repositoty-Server-Name>"
Stop
Delay 10000
ExecCmd "cmd /c call RPClean_This.bat > RPClean_This.log 2>
RPClean_This_2.log"
Delay 10000
Start
Delay 10000
Exit
Mario Emmi
British Aerospace Australia
-----Original Message-----
From: Wheeler, Douglas CWT-MSP [SMTP:[email protected]]
Sent: Thursday, 23 September 1999 02:40
To: '[email protected]'
Subject: (forte-users) FW: central environment hanging
Our development environment consists of a SUN box as the environment
manager with an NT box acting as the host for all of the repositories.We
have a number of repositories and an NT service set up for each one.Each
night WinAT runs bat files the shutdown each of the rpserver, runrpclean
against each of the repositories, and then starts up each of therpserver.
The problem that we are seeing is the central environment hangs at some
point during this process. The central environment manager process is
still running under UNIX (via checkforte) but you cannot connect via
escript or econsole. In addition there are no log messages indicating
what is causing the environment to hang.
Does anybody have a similar development environment?
Some specific Forte questions:
1. Is it better to bring the repositories down via rpstop or anescript?
2. We are using rpstop -k could this be causing a problem?
3. Should we be bring down the node manager on the NT box also?
Some NT specific questions:
1. We use WinAT with a call to a batch file that calls a batch file the
runs the "rpstop ... -k" and "netsrv "name" \\machine /stop" Thisshould
work, right? Specifically, will the rpserver shut down gracefully?2. For the NT services that are set up for the Forte process should the
"Log On As" property be set to "System Account" or "This Account: forte"?
Thanks,
Doug Wheeler
Voice: (612) 594-2519
BORN Information Services voicemail: (612) 404-4379
[email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Hi Douglas,
You experience problems after a nightly refresh of your repositories.
You do not mention this explicitely in your mail, but am I correct in
assuming you also reboot the NT-server? And, am I correct in
assuming the E-script and E-console that won't start, are being
started (or at least, trying to be started) on this same NT-server,
after the reboot?
If that is the case, then there is your problem. You stopped the
repositories correctly, cleaned them and then restarted the computer,
without first stopping the nodemgr correctly. If the same node is
started again, and de nodemgr is started, it is unable to re-attach
to the cental node. First, the central node must understand that
the original node is gone, which it will after a network timeout, which
usually is a TCP/IP timeout of about 1 hour.
Solutions.
1) Wait 1 hour after reboot before attempting any E-script.
2) Before rebooting the machine, use E-script to shutdown the
nodemgr.
3) Use the KEEP_ALIVE settings (see Forte docu), to bring this
timeout back to a few minutes, in stead of 1 hour.
Pascal Rottier
STP - MSS Support & Coordination Group
Philip Morris Europe
e-mail: [email protected]
Phone: +49 (0)89-72472530
+++++++++++++++++++++++++++++++++++
Origin IT-services
Desktop Business Solutions Rotterdam
e-mail: [email protected]
Phone: +31 (0)10-2428100
+++++++++++++++++++++++++++++++++++
/* All generalizations are false! */
-----Original Message-----
From: Wheeler, Douglas CWT-MSP [SMTP:[email protected]]
Sent: Wednesday, September 22, 1999 6:40 PM
To: '[email protected]'
Subject: (forte-users) FW: central environment hanging
Our development environment consists of a SUN box as the environment
manager with an NT box acting as the host for all of the repositories.We
have a number of repositories and an NT service set up for each one.Each
night WinAT runs bat files the shutdown each of the rpserver, runrpclean
against each of the repositories, and then starts up each of therpserver.
The problem that we are seeing is the central environment hangs at some
point during this process. The central environment manager process is
still running under UNIX (via checkforte) but you cannot connect via
escript or econsole. In addition there are no log messages indicating
what is causing the environment to hang.
Does anybody have a similar development environment?
Some specific Forte questions:
1. Is it better to bring the repositories down via rpstop or anescript?
2. We are using rpstop -k could this be causing a problem?
3. Should we be bring down the node manager on the NT box also?
Some NT specific questions:
1. We use WinAT with a call to a batch file that calls a batch file the
runs the "rpstop ... -k" and "netsrv "name" \\machine /stop" Thisshould
work, right? Specifically, will the rpserver shut down gracefully?2. For the NT services that are set up for the Forte process should the
"Log On As" property be set to "System Account" or "This Account: forte"?
Thanks,
Doug Wheeler
Voice: (612) 594-2519
BORN Information Services voicemail: (612) 404-4379
[email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Environment variables (user) created at OS level dont show up in BIDS 2008

Environment variables (user) created at OS level don't show up in BIDS 2008.
I had a variable ConfigLocation created and it is not showing up when I am trying to configure it in BIDS
Is this a known issue or a bug?
Now in BIDS it doesnt show up
Mudassar

Yes it shows up after restart of BIDS .
But during design time this is a bug I hope Microsoft fixes this bug in the future releases
Mudassar
It's not really a bug. Visual Studio loads the environment variables when starting up.
In future releases you use projects and parameters instead of environment variables, so the issue goes away ;)
MCSE SQL Server 2012 - Please mark posts as answered where appropriate.

I am not getting User Environment Variable Value

Hi Team,
I have been Trying to recover variables values using an anonym procedure from Windows XP SP3
I have already executed following procedure.
BEGIN
DECLARE
gf_filelog UTL_FILE.file_type;
v_file_log VARCHAR2 (1024) := ' ';
gv_path_log VARCHAR2 (1024) := ' ';
gv_path_log2 VARCHAR2 (1024) := ' ';
gv_file_log VARCHAR2 (1024) := ' ';
BEGIN
DBMS_OUTPUT.put_line ( 'obteniendo valores of vars: '
|| gv_path_log
|| ' '
|| gv_file_log
DBMS_SYSTEM.get_env ('ORACLE_HOME', gv_path_log);
DBMS_SYSTEM.get_env ('PATH_MODULO', gv_path_log2);
DBMS_SYSTEM.get_env ('FILELOG', v_file_log);
DBMS_OUTPUT.put_line ( 'valores vars ORACLE_HOME: '
|| gv_path_log
|| 'PATH_MODULO:'
|| gv_path_log2
|| ' FILELOG:'
|| v_file_log
gv_file_log :=
v_file_log || TO_CHAR (SYSDATE, 'yyyymmddHH24MISS')
|| '.log';
DBMS_OUTPUT.put_line ( 'Nombre de Archivo creado'
|| gv_path_log
|| ' '
|| gv_file_log
gf_filelog := UTL_FILE.fopen (gv_path_log, gv_file_log, 'w');
DBMS_OUTPUT.put_line ('Archivo creado' || gv_path_log || ' '
|| gv_file_log
UTL_FILE.put_line (gf_filelog,
|| TO_CHAR (SYSDATE, 'HH24:MI:SSSSS')
|| ']--> '
|| 'Prueba de escritura'
|| gv_path_log
|| ' '
|| v_file_log
UTL_FILE.fflush (gf_filelog);
UTL_FILE.fclose (gf_filelog);
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line ( '[reporta_log]Error en :'
|| SQLCODE
|| ' - '
|| SQLERRM
raise_application_error (-20000,
'[reporta_log]Error en :'
|| SQLCODE
|| ' - '
|| SQLERRM
END;
END;
I show you data result after procedure was excecuted.
obteniendo valores of vars:
valores vars ORACLE_HOME: E:\oracle\product\10.2.0\db_1PATH_MODULO: FILELOG:
Nombre de Archivo creadoE:\oracle\product\10.2.0\db_1 20111122171625.log
[reporta_log]Error en :-29280 - ORA-29280: invalid directory path
BEGIN
ERROR at line 1:
ORA-20000: [reporta_log]Error en :-29280 - ORA-29280: invalid directory path
ORA-06512: at line 55
I see that only ORACLE_HOME variable value was got, question is why, of course, variable values are already defined as user variables.
Variables PATH_MODULO and FILELOG was defined using windows maintenance variable method, that is :
1.- settings
2.- system
3.- advanced options
4.- environment variables
Here my oracle version
SQL> select version from v$instance;
VERSION
10.2.0.1.0
SQL>
Is this an Oracle Issue or variables would be defined in another way?
ORACLE_HOME VARIABLE was created when oracle engine was installed.
I have got same result after computer was restart.
I appreciate wathever clue.

Ok, that is , I only can read environment variables values, but not variables values at user profile. It happends in unix environment too. So I tried to use another instruction sequence in order to read user variables values.
Regards

Best practices for defining Environment Variables/User Accounts in Linux

Hello,
After reading throught the Quick Install guide for 10gR2 on x86_64 Linux, I see that it is not recommended to define ANY variables in .bash_profile.
I'm hoping to get a Best practices approach for defining environment variables - right now we use the oracle linux account for administration including sql*plus. So, where should the myriad variables be defined? Is it important enough to create a user account in linux to support best practices?
What variables, exactly, should be defined? It seems that LD_LIBRARY_PATH is no longer being used?
Thanks in advance
Doug

Something that I've done for years on unix/linux boxes is to create a seperate environment variable setup file for each instance on the box. This would include things like ORACLE_HOME, ORACLE_SID, etc. Then I would create an alias in my .bash_profile that would execute this script. As an example, I would create a orcl.env file that would hold all of the environment variables for this instance. Then in my .bash_profile I would create a line like the following:
alias orcl=". $HOME/orcl.env"
Then from anywhere you could type orcl and you would set your environment to connect to that database.
Also, if you are using 10g, something else that is really nice if you are using sqlplus, and you connect to different databases without starting a new sqlplus session is to set a parameter in your $ORACLE_HOME/sqlplus/admin/glogin.sql file:
set sqlprompt "_user 'at' _connect_identifier >"
This will automatically change your command prompt to look like this:
RALPH at ORCL >
if you connect as GEORGE, your prompt will immediately change to :
GEORGE at ORCL >
This way you can always know who and where you are connected to.
Good luck!

How can I reading environment variables (user variables)

Hi,
I hope someone can halp me out:
In the software that I develop it is neccessary to read some user (environment) variables, such as the temp folder of the current user.
I know that I can read out some system variables like this:
String homePath = System.getProperty("user.home");
But how can I read out some other variables, especially the temp folder of the current user?
Thanks

I might have misunderstood you, but I am notlooking
for the PATH variable. I need the location of
the
temp folder of the current user. This should be
called TEMP or so, but this does not work.Can you deduce from the link he provided, to lookat
System.getenv(), and find the "TEMP" environment
variable in what it returns to you?That said, I believe the "temp" folder may be
provided in one of the normal System properties
anyway, so you probably don't need to go that route.
Print all your System.getProperties() values, and see
if it's in there.Yepp. os.io.temp or something.

RE: (forte-users) FORTE_ROOT environment variable

Similar Messages

Maybe you are looking for