In case anyone is interested, this was eventually solved by changing the
owner of the accounts that had the issue, so it was, in fact, a
permissions problem.
-Dianne
On 8/21/2013 9:59 AM, Dianne Ackerman wrote:
Thanks Aaron, I'll check that out!
-Dianne
On 8/21/2013 9:57 AM, Aaron Titus wrote:
hmm.. ten doesn't seem like that much. The way you describe the
problem it
sounds like a directory-level performance issue, i.e. its scanning
directories in the filesystem and there is some directory with a very
large
number of entries -- far larger than it should be. I would typically
guess
&PH& or &COMO& might have a large number of entries, but then again not
sure why STATUS function would go after those.
If this was Linux or Unix, what I would do to figure this out is to
put a
truss / strace on the uvsh process, and use the option to show
timestamps
on the function calls. You'd then be able to see which OS level
operation
was actually consuming the time. Usually that will be a dead give
away as
to where the problem is. I'm not sure how to accomplish the
equivalent of
this on Windows platforms. I did a quick search on the internet and I
came
up with a sysinternals tool called Process Monitor. While I can say
that
I've used many of the sysinternals tools in the past and had success,
I've
never done this particular type of tracing on windows so I don't know
how
to give you specific instructions.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
*Aaron Titus*
Senior Software Engineer
F.W. Davison & Company, Inc.
508-747-7261 x245
ati...@fwdco.com
On Tue, Aug 20, 2013 at 4:29 PM, Dianne Ackerman <dia...@aptron.com>
wrote:
c:\level contains about 10 universe accounts. All are local
directories,
none are remote.
-Dianne
On 8/20/2013 4:24 PM, Aaron Titus wrote:
Hi Diane, a couple of questions.
How many other directories exist within c:\level ?
Is C:\ACCOUNT a local directory and c:\level remote?
*Aaron Titus*
Senior Software Engineer
F.W. Davison & Company, Inc.
508-747-7261 x245
ati...@fwdco.com
On Tue, Aug 20, 2013 at 2:00 PM, Dianne Ackerman <dia...@aptron.com>
wrote:
OK, I've found the PERMISSIONS subroutine (APP.PROGS PERMS.B) and
have
narrowed this issue down more. It's actually a slowness in the basic
command STATUS. It's instantaneous in an upper level account (eg
C:\ACCOUNT) but takes 4-5 seconds in a lower level account (eg
C:\level\ACCOUNT). Any thoughts?
Thanks
-Dianne
On 8/15/2013 9:50 AM, Dianne Ackerman wrote:
Does anyone know anything about the -PERMISSIONS subroutine used
by the
ED verb in Universe? Running 11.1.12 on Windows, the ED verb has
a huge
delay and we've tracked it down to that subroutine call in the
basic ED
program. If I could look at that subroutine to see what it's doing,
maybe
I can figure out what's causing that delay. Thanks!
-Dianne
>ED BP ED.B The file "BP" is read-only and cannot be updated.
3988
lines
long. ----: L PERMISSIONS 0153: PERMISSIONS = '-PERMISSIONS'
----: L
0308:
CALL @PERMISSIONS(EDIT.FILE,EDIT.****PERM.MODE,EDIT.PERM.IN,EDIT
.PERM.OUT) ----: EX
______________________________****_________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/****mailman/listinfo/u2-users<http://listserver.u2ug.org/**mailman/listinfo/u2-users>
<http**://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>
______________________________**_________________
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users