Re: [U2] @LOGNAME... Changing @variables

2010-06-17 Thread u2ug 
That is different from universe where you get the error "@Variable
(Read-only) unexpected" when you try to directly assign to @LOGNAME


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan McGrath
Sent: June 17, 2010 06:53 PM
To: U2 Users List
Subject: Re: [U2] @LOGNAME... Changing @variables

I looked into this and there appears to be 2 different type of "system
variables" in UniData. There are those like @AM which cannot be changed
and those like @LOGNAME which can be. It is not required to pass them to
a subroutine to change those that can be. A program will not compile if
you assign to the first type.

First type (Those that cannot be changed):

@ACCOUNT
@AM
@COMMAND
@CRTHIGH
@CRTWIDE
@DATA
@GID
@LASTVERB
@LEVEL
@LPTRHIGH
@LPTRWIDE
@PARASENTENCE
@PATH
@RM
@SM
@SVM
@SYS.BELL
@SYSTEM.RETURN.CODE
@TM
@TRANSACTION
@TTY
@UDTNO
@UID
@VM
@WHO


Second type (Those that can be freely changed):

@CONV
@DATE
@DICT   (This is actual usage. Documented)
@FORMAT
@HEADER
@ID (This is actual usage. Documented)
@LOGNAME
@MONTH
@RECORD (This is actual usage. Documented)
@RECUR0 (This is actual usage. Documented)
@RECUR1 (This is actual usage. Documented)
@RECUR2 (This is actual usage. Documented)
@RECUR3 (This is actual usage. Documented)
@RECUR4 (This is actual usage. Documented)
@TIME
@USER0  (This is actual usage. Documented)
@USER1  (This is actual usage. Documented)
@USER2  (This is actual usage. Documented)
@USER3  (This is actual usage. Documented)
@USER4  (This is actual usage. Documented)
@USER.RETURN.CODE (This is actual usage. Documented)
@YEAR


Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of u2ug
Sent: Friday, June 18, 2010 8:29 AM
To: U2 Users List
Subject: Re: [U2] @LOGNAME on Unidata

We ran into a similar situation in the past with uv on hpux
Although @LOGNAME is documented as a readonly value, we found out that
it is possible to change it ( and other readonly system variables ) by
passing it as an argument to a subroutine - the subroutine can then
change the value.  I guess uv doesn't actually mark the variable as
readonly in any way at run time - readonliness is a compile time
attribute - so a subroutine has no idea that its calling args are
readonly system variables - so in effect they aren't.

Look for any subroutines called with @LOGNAME as an argument then check
that the sub doesn't alter that argument.

Given :
...
CALL *SOMESUB( @LOGNAME )
...
DEFINE SUBROUTINE SOMESUB ( ARG )
...
* this will change the argument value in the calling
routine
* including 'readonly' system variables
ARG="Something" 
...
END

Pass temp variable instead of @LOGNAME :
CALL *SOMESUB( @LOGNAME:"" )
-or-
CALL *SOMESUB( (@LOGNAME) )
-or-
Ensure that argument is never modified in the routine --
DEFINE SUBROUTINE SOMESUB ( ARG.IN )
ARG=ARG.IN ;* the only place IARG is ever used
...
ARG="SomethingElse"
...
END

Note that this also applies to functions and routines called via SUBR()
and once the variable is changed it is changed for the lifetime of the
current session not just for the current program.

Gerry



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey
Butera
Sent: June 17, 2010 02:04 PM
To: U2 Users List
Subject: [U2] @LOGNAME on Unidata

We recently migrated from Unidata 7.1.8 on Solaris to Unidata 7.2.5 on 
RedHat.

We make use of @LOGNAME quite a bit to determine a person's username.  
Since our migration, however, we've documented some cases where @LOGNAME

is not returning the proper username - it returns someone else's.
What's bizarre is that most of the time it's right, but occasionally 
it's not.

Has anyone seen or heard of this?

When we had a report of this (with documentation) I thought it was 
weird.  Today we just got a call about a different problem which I'm 99%

sure is tied to this since it makes use of @LOGNAME.  Like the above, 
sometimes it's correct, sometime it's wrong.

-- 
Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

__
This email has b

Re: [U2] @LOGNAME... Changing @variables

2010-06-17 Thread Dan McGrath 
I looked into this and there appears to be 2 different type of "system
variables" in UniData. There are those like @AM which cannot be changed
and those like @LOGNAME which can be. It is not required to pass them to
a subroutine to change those that can be. A program will not compile if
you assign to the first type.

First type (Those that cannot be changed):

@ACCOUNT
@AM
@COMMAND
@CRTHIGH
@CRTWIDE
@DATA
@GID
@LASTVERB
@LEVEL
@LPTRHIGH
@LPTRWIDE
@PARASENTENCE
@PATH
@RM
@SM
@SVM
@SYS.BELL
@SYSTEM.RETURN.CODE
@TM
@TRANSACTION
@TTY
@UDTNO
@UID
@VM
@WHO


Second type (Those that can be freely changed):

@CONV
@DATE
@DICT   (This is actual usage. Documented)
@FORMAT
@HEADER
@ID (This is actual usage. Documented)
@LOGNAME
@MONTH
@RECORD (This is actual usage. Documented)
@RECUR0 (This is actual usage. Documented)
@RECUR1 (This is actual usage. Documented)
@RECUR2 (This is actual usage. Documented)
@RECUR3 (This is actual usage. Documented)
@RECUR4 (This is actual usage. Documented)
@TIME
@USER0  (This is actual usage. Documented)
@USER1  (This is actual usage. Documented)
@USER2  (This is actual usage. Documented)
@USER3  (This is actual usage. Documented)
@USER4  (This is actual usage. Documented)
@USER.RETURN.CODE (This is actual usage. Documented)
@YEAR


Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of u2ug
Sent: Friday, June 18, 2010 8:29 AM
To: U2 Users List
Subject: Re: [U2] @LOGNAME on Unidata

We ran into a similar situation in the past with uv on hpux
Although @LOGNAME is documented as a readonly value, we found out that
it is possible to change it ( and other readonly system variables ) by
passing it as an argument to a subroutine - the subroutine can then
change the value.  I guess uv doesn't actually mark the variable as
readonly in any way at run time - readonliness is a compile time
attribute - so a subroutine has no idea that its calling args are
readonly system variables - so in effect they aren't.

Look for any subroutines called with @LOGNAME as an argument then check
that the sub doesn't alter that argument.

Given :
...
CALL *SOMESUB( @LOGNAME )
...
DEFINE SUBROUTINE SOMESUB ( ARG )
...
* this will change the argument value in the calling
routine
* including 'readonly' system variables
ARG="Something" 
...
END

Pass temp variable instead of @LOGNAME :
CALL *SOMESUB( @LOGNAME:"" )
-or-
CALL *SOMESUB( (@LOGNAME) )
-or-
Ensure that argument is never modified in the routine --
DEFINE SUBROUTINE SOMESUB ( ARG.IN )
ARG=ARG.IN ;* the only place IARG is ever used
...
ARG="SomethingElse"
...
END

Note that this also applies to functions and routines called via SUBR()
and once the variable is changed it is changed for the lifetime of the
current session not just for the current program.

Gerry



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey
Butera
Sent: June 17, 2010 02:04 PM
To: U2 Users List
Subject: [U2] @LOGNAME on Unidata

We recently migrated from Unidata 7.1.8 on Solaris to Unidata 7.2.5 on 
RedHat.

We make use of @LOGNAME quite a bit to determine a person's username.  
Since our migration, however, we've documented some cases where @LOGNAME

is not returning the proper username - it returns someone else's.
What's bizarre is that most of the time it's right, but occasionally 
it's not.

Has anyone seen or heard of this?

When we had a report of this (with documentation) I thought it was 
weird.  Today we just got a call about a different problem which I'm 99%

sure is tied to this since it makes use of @LOGNAME.  Like the above, 
sometimes it's correct, sometime it's wrong.

-- 
Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__
###
The information transmitted in this message and attachments (if any) is 
intended only
for the person or entity to which it is addressed. The mes

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread u2ug 
We ran into a similar situation in the past with uv on hpux
Although @LOGNAME is documented as a readonly value, we found out that
it is possible to change it ( and other readonly system variables ) by
passing it as an argument to a subroutine - the subroutine can then
change the value.  I guess uv doesn't actually mark the variable as
readonly in any way at run time - readonliness is a compile time
attribute - so a subroutine has no idea that its calling args are
readonly system variables - so in effect they aren't.

Look for any subroutines called with @LOGNAME as an argument then check
that the sub doesn't alter that argument.

Given :
...
CALL *SOMESUB( @LOGNAME )
...
DEFINE SUBROUTINE SOMESUB ( ARG )
...
* this will change the argument value in the calling
routine
* including 'readonly' system variables
ARG="Something" 
...
END

Pass temp variable instead of @LOGNAME :
CALL *SOMESUB( @LOGNAME:"" )
-or-
CALL *SOMESUB( (@LOGNAME) )
-or-
Ensure that argument is never modified in the routine --
DEFINE SUBROUTINE SOMESUB ( ARG.IN )
ARG=ARG.IN ;* the only place IARG is ever used
...
ARG="SomethingElse"
...
END

Note that this also applies to functions and routines called via SUBR()
and once the variable is changed it is changed for the lifetime of the
current session not just for the current program.

Gerry



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey
Butera
Sent: June 17, 2010 02:04 PM
To: U2 Users List
Subject: [U2] @LOGNAME on Unidata

We recently migrated from Unidata 7.1.8 on Solaris to Unidata 7.2.5 on 
RedHat.

We make use of @LOGNAME quite a bit to determine a person's username.  
Since our migration, however, we've documented some cases where @LOGNAME

is not returning the proper username - it returns someone else's.
What's bizarre is that most of the time it's right, but occasionally 
it's not.

Has anyone seen or heard of this?

When we had a report of this (with documentation) I thought it was 
weird.  Today we just got a call about a different problem which I'm 99%

sure is tied to this since it makes use of @LOGNAME.  Like the above, 
sometimes it's correct, sometime it's wrong.

-- 
Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread John Hester 
Yes, @LOGNAME comes from the unix/linux LOGNAME environment variable, at
least in UV.  If the LOGNAME variable is wrong but some other
environment (like USER) is correct, LOGNAME could be re-assigned in
.bash_profile prior to executing UD:

LOGNAME=$USER

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jacques G.
Sent: Thursday, June 17, 2010 12:39 PM
To: jbut...@hampshire.edu; U2 Users List
Subject: Re: [U2] @LOGNAME on Unidata


On Universe you can use SYSTEM(19) instead of @LOGNAME.  It might exist
on Unidata too.

I don't know if @LOGNAME gets it from the Unix environment LOGNAME
variable.  If so, there may be a Unix script that is changing the
environment variable.   You can try:
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread Jon Wells 
Hi Jeff,

While at Beloit I had a problem with @LOGNAME.  It only showed up when a 
Datatel program was calling another Datatel program (or something like that).  
I know it had something to do with a problem with Uniobjects and PAM 
authentication.  The work-around was to add the DMI username and password in a 
DMIEXTS record.  We used a Datatel subroutine to control access to budgets for 
reports such as the trial balance report.  Turned out the report thought 
everyone was "datatel".  Worse yet, at the time we found this out, the user 
datatel was setup to have wide open budget access.

I'm wondering if Datatel's strange world of listeners is involved in your case. 
 On the other hand; going to Unidata 7.2.x was the solution for our budget 
access problem as I was able to undo the above work-around.

--- On Thu, 6/17/10, Jeffrey Butera  wrote:

> From: Jeffrey Butera 
> Subject: [U2] @LOGNAME on Unidata
> To: "U2 Users List" 
> Date: Thursday, June 17, 2010, 2:04 PM
> We recently migrated from Unidata
> 7.1.8 on Solaris to Unidata 7.2.5 on RedHat.
> 
> We make use of @LOGNAME quite a bit to determine a person's
> username.  Since our migration, however, we've
> documented some cases where @LOGNAME is not returning the
> proper username - it returns someone else's.   
> What's bizarre is that most of the time it's right, but
> occasionally it's not.
> 
> Has anyone seen or heard of this?
> 
> When we had a report of this (with documentation) I thought
> it was weird.  Today we just got a call about a
> different problem which I'm 99% sure is tied to this since
> it makes use of @LOGNAME.  Like the above, sometimes
> it's correct, sometime it's wrong.
> 
> -- Jeff Butera, Ph.D.
> Manager of ERP Systems
> Hampshire College
> jbut...@hampshire.edu
> 413-559-5556 
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
>  
> begin_of_the_skype_highlighting  413-559-5556  end_of_the_skype_highlighting
> 
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> 
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread Jacques G. 

On Universe you can use SYSTEM(19) instead of @LOGNAME.  It might exist on 
Unidata too.

I don't know if @LOGNAME gets it from the Unix environment LOGNAME variable.  
If so, there may be a Unix script that is changing the environment variable.   
You can try:





- Original Message 
From: Jeffrey Butera 
To: U2 Users List 
Sent: Thu, June 17, 2010 2:04:08 PM
Subject: [U2] @LOGNAME on Unidata

We recently migrated from Unidata 7.1.8 on Solaris to Unidata 7.2.5 on RedHat.

We make use of @LOGNAME quite a bit to determine a person's username.  Since 
our migration, however, we've documented some cases where @LOGNAME is not 
returning the proper username - it returns someone else's.What's bizarre is 
that most of the time it's right, but occasionally it's not.

Has anyone seen or heard of this?

When we had a report of this (with documentation) I thought it was weird.  
Today we just got a call about a different problem which I'm 99% sure is tied 
to this since it makes use of @LOGNAME.  Like the above, sometimes it's 
correct, sometime it's wrong.

-- Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users



  
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread Steve Romanow 

On 6/17/2010 2:23 PM, Jeffrey Butera wrote:

On 06/17/10 14:20, Dan Goble wrote:
I have seen this in the past where the file wtmp usually found in 
/var/adm is corrupt or too big ( over 2 meg ).  To correct this just 
type at the unix prompt

wtmp
And it will clear the file.I recommend doing this just before a 
reboot of the system.


Thanks Dan.  Our wtmp is under 1Meg and just rotated this week, so I 
can't imagine this is the culprit, but I'll give it a whirl...



We had an issue similar to this, but I am having difficulty recalling 
what the issue was.  It was the strangest thing, right much of the time, 
but consistently it would not be correct.
Some things that come to mind, named (or un-named) COMMON.  Re-entrant 
programs.  I will check with some team members.  It has been probably 
5-10 years since this issue for us.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread Jeffrey Butera 

On 06/17/10 14:20, Dan Goble wrote:

I have seen this in the past where the file wtmp usually found in /var/adm is 
corrupt or too big ( over 2 meg ).  To correct this just type at the unix prompt
   

wtmp
 

And it will clear the file.I recommend doing this just before a reboot of 
the system.
   


Thanks Dan.  Our wtmp is under 1Meg and just rotated this week, so I 
can't imagine this is the culprit, but I'll give it a whirl...



--
Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] @LOGNAME on Unidata

2010-06-17 Thread Dan Goble 
I have seen this in the past where the file wtmp usually found in /var/adm is 
corrupt or too big ( over 2 meg ).  To correct this just type at the unix 
prompt 

> wtmp

And it will clear the file.I recommend doing this just before a reboot of 
the system.

-Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey Butera
Sent: Thursday, June 17, 2010 2:04 PM
To: U2 Users List
Subject: [U2] @LOGNAME on Unidata

We recently migrated from Unidata 7.1.8 on Solaris to Unidata 7.2.5 on 
RedHat.

We make use of @LOGNAME quite a bit to determine a person's username.  
Since our migration, however, we've documented some cases where @LOGNAME 
is not returning the proper username - it returns someone else's.
What's bizarre is that most of the time it's right, but occasionally 
it's not.

Has anyone seen or heard of this?

When we had a report of this (with documentation) I thought it was 
weird.  Today we just got a call about a different problem which I'm 99% 
sure is tied to this since it makes use of @LOGNAME.  Like the above, 
sometimes it's correct, sometime it's wrong.

-- 
Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

[U2] @LOGNAME on Unidata

2010-06-17 Thread Jeffrey Butera 
We recently migrated from Unidata 7.1.8 on Solaris to Unidata 7.2.5 on 
RedHat.


We make use of @LOGNAME quite a bit to determine a person's username.  
Since our migration, however, we've documented some cases where @LOGNAME 
is not returning the proper username - it returns someone else's.
What's bizarre is that most of the time it's right, but occasionally 
it's not.


Has anyone seen or heard of this?

When we had a report of this (with documentation) I thought it was 
weird.  Today we just got a call about a different problem which I'm 99% 
sure is tied to this since it makes use of @LOGNAME.  Like the above, 
sometimes it's correct, sometime it's wrong.


--
Jeff Butera, Ph.D.
Manager of ERP Systems
Hampshire College
jbut...@hampshire.edu
413-559-5556

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

RE: [U2] @LOGNAME?

2007-05-04 Thread colin.alfke 
I think @LOGNAME comes from windows which appears to cache it. We found
after changing the user names a reboot of the server was required to
bring in the updated name. We also have a .bat file which does an: ECHO
%USERNAME% but I don't recall which it returned.

For us the reboot was the easiest fix, if you can't reboot perhaps a
"secedit /refresh" (IIRC) would work? 

Hth
Colin Alfke
Calgary Canada

>-Original Message-
>From: Eric Neu
>
>Greetings all,
>
>Does anyone here know how UniData on Windows sets @LOGNAME. 
>Where/When does it get set? (UniData 6.1, Windows 2003SE)
>
>We've recently undergone a standards enforcement for NT user 
>ids and many of my users had their user id changed. When these 
>users use a process that checks @LOGNAME (from BASIC) to 
>determine who they are their old user id is returned.
>
>I thought perhaps UniData might have stored some trace of the 
>old IDs in the user's registry but logging on a new machine 
>produces the same result.
>
>I also thought perhaps UniData might cache Windows credentials 
>and forcing a password change might trigger an update but that 
>didn't help.
>
>I'll try a server reboot after the close of business but if 
>that doesn't work I'm not sure what to try next. I have 
>considered using
>GETENV('USERNAME') to return the ID I'm expecting (which works 
>btw) but that means changing a slew of programs and I'd prefer 
>not to do that.
>
>Any information on this would be really helpful.
>
>
>Thank you,
>
>Eric Neu
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

{Blocked Content} RE: [U2] @LOGNAME?

2007-05-03 Thread Dave Davis 
Warning: This message has had one or more attachments removed
Warning: (not named).
Warning: Please read the "AngelicHost-Attachment-Warning.txt" attachment(s)
for more information.

Isn't @LOGNAME the group the user is a member of on Windows servers?

You may have had the users be in their own windows groups before.



From: [EMAIL PROTECTED] on behalf of Eric Neu
Sent: Thu 5/3/2007 7:15 PM
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] @LOGNAME?



Greetings all,

Does anyone here know how UniData on Windows sets @LOGNAME. Where/When does
it get set? (UniData 6.1, Windows 2003SE)

We've recently undergone a standards enforcement for NT user ids and many of
my users had their user id changed. When these users use a process that
checks @LOGNAME (from BASIC) to determine who they are their old user id is
returned.

I thought perhaps UniData might have stored some trace of the old IDs in the
user's registry but logging on a new machine produces the same result.

I also thought perhaps UniData might cache Windows credentials and forcing a
password change might trigger an update but that didn't help.

I'll try a server reboot after the close of business but if that doesn't
work I'm not sure what to try next. I have considered using
GETENV('USERNAME') to return the ID I'm expecting (which works btw) but that
means changing a slew of programs and I'd prefer not to do that.

Any information on this would be really helpful.


Thank you,

Eric Neu
Zetron, Inc.
eneu at zetron dot com
425.820.6363 x271
www.zetron.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
This is a message from the MailScanner E-Mail Virus Protection Service
--
The original e-mail attachment "winmail.dat"
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Thu May  3 20:00:49 2007 the virus scanner said:
   Could not parse Outlook Rich Text attachment

Note to Help Desk: Look on the AngelicHost MailScanner in
/home/virtual/site2/fst/var/spool/mail.quarantine/20070503 (message
l4430lmK018339).
--
Postmaster
MailScanner thanks transtec Computers for their support
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] @LOGNAME?

2007-05-03 Thread Eric Neu 
Greetings all,

Does anyone here know how UniData on Windows sets @LOGNAME. Where/When does
it get set? (UniData 6.1, Windows 2003SE)

We've recently undergone a standards enforcement for NT user ids and many of
my users had their user id changed. When these users use a process that
checks @LOGNAME (from BASIC) to determine who they are their old user id is
returned.

I thought perhaps UniData might have stored some trace of the old IDs in the
user's registry but logging on a new machine produces the same result.

I also thought perhaps UniData might cache Windows credentials and forcing a
password change might trigger an update but that didn't help.

I'll try a server reboot after the close of business but if that doesn't
work I'm not sure what to try next. I have considered using
GETENV('USERNAME') to return the ID I'm expecting (which works btw) but that
means changing a slew of programs and I'd prefer not to do that.

Any information on this would be really helpful.


Thank you,

Eric Neu
Zetron, Inc.
eneu at zetron dot com
425.820.6363 x271
www.zetron.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/