RE: [U2] [UV] PORT.STATUS From Unix
Great info! Thanks. Perry Taylor -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herve Balestrieri Sent: Wednesday, November 23, 2005 10:27 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] PORT.STATUS From Unix Starting at release 10.1.15, the problem with "uvlictool" hanging UniVerse when issuing to a "pipe" will be fixed (ECase 7640*USA). When hung on the "Port status" semaphore, the "State" column would show = 1 as follow : Port status State Netnode Owner Collisions Retries Semaphore # 1 10 0 1 13 (I've seen this only once in 10 years supporting UniVerse...) The "Collisions" and "Retries" columns are mentionning occurences of conflicts in concurrent access toward this semaphore. Since this semaphore is used only for internal purposes by the "PORT.STATUS" command, in operating normally, such conflicts on the "Port status" semaphore would not occur because the "PORT.STATUS" command is a Database Administrator command that can be accessed only from the UniVerse Administration account (installation account). What would you think of a Database administered simultaneously by several concurrent "Database Administrators" ? It's worth knowing that, in its internal mechanism, the "PORT.STATUS" command queries by a signal "SIG_USR2" all the database sessions to put in their "Printer Shared Memory" segment their most recent "Last command processed". Then, for every database session, "PORT.STATUS" attaches to each "Disk Shared Memory" segment, passes the information to a memory buffer in the "Disk Shared Memory" segment, detach from the "Disk Shared Memory" segment, reads this information from the central buffer and formats the displayed output, each user one after the other. Note that since release 9.6.x of UniVerse, the "PORT.STATUS" command may not display ALL UniVerse interactive sessions : If, for any reason, it is failing to attach and get the information from a given user's "Printer Shared Memory" segment, "PORT.STATUS" just continues processing with next session, leaving the unaccessible user's session not mentionned in its report. The "PHANTOM" sessions are just mentionned "unavailable" when such event occurs. Regards, Hervi BALESTRIERI Support Technique Avanci - Produits "U2" IBM Software Group - DB2 Information Management Software Web : http://www.ibm.com/software/u2/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
Starting at release 10.1.15, the problem with "uvlictool" hanging UniVerse when issuing to a "pipe" will be fixed (ECase 7640*USA). When hung on the "Port status" semaphore, the "State" column would show = 1 as follow : Port status State Netnode Owner Collisions Retries Semaphore # 1 10 0 1 13 (I've seen this only once in 10 years supporting UniVerse...) The "Collisions" and "Retries" columns are mentionning occurences of conflicts in concurrent access toward this semaphore. Since this semaphore is used only for internal purposes by the "PORT.STATUS" command, in operating normally, such conflicts on the "Port status" semaphore would not occur because the "PORT.STATUS" command is a Database Administrator command that can be accessed only from the UniVerse Administration account (installation account). What would you think of a Database administered simultaneously by several concurrent "Database Administrators" ? It's worth knowing that, in its internal mechanism, the "PORT.STATUS" command queries by a signal "SIG_USR2" all the database sessions to put in their "Printer Shared Memory" segment their most recent "Last command processed". Then, for every database session, "PORT.STATUS" attaches to each "Disk Shared Memory" segment, passes the information to a memory buffer in the "Disk Shared Memory" segment, detach from the "Disk Shared Memory" segment, reads this information from the central buffer and formats the displayed output, each user one after the other. Note that since release 9.6.x of UniVerse, the "PORT.STATUS" command may not display ALL UniVerse interactive sessions : If, for any reason, it is failing to attach and get the information from a given user's "Printer Shared Memory" segment, "PORT.STATUS" just continues processing with next session, leaving the unaccessible user's session not mentionned in its report. The "PHANTOM" sessions are just mentionned "unavailable" when such event occurs. Regards, Hervi BALESTRIERI Support Technique Avanci - Produits "U2" IBM Software Group - DB2 Information Management Software Web : http://www.ibm.com/software/u2/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
Yes, Herve, that helps!
Thanks. That one's a keeper.
Can you answer my question about how to read the port.status section of
the smat -s output?
(That's what you get for being helpful.)
cds
> From: Herve Balestrieri
>
> When there is no UNIX session logged into UniVerse, you can
> setup an inode link with the "list_readu" executable to run
> "UNLOCK" commands from UNIX :
>
> # cd `cat /.uvhome`
> # ln bin/list_readu bin/unlock
> # bin/unlock LOGINLOCK SEMAPHORE
>
> From: Stevenson, Charles
>
> A more dangerous similar example is locking the login semaphore.
> Logins to UV shell are singlethreaded via this semaphore.
> uvlictool apparently sets the semaphore so it can do its
> thing in peace.
> If you run uvlictool and pipe the results to a typo ("gerp"
> instead of "grep" is one of my favorites), then uvlictool
> aborts without clearing the semaphore & no one can log in.
> At that point root needs to do UNLOCK LOGINLOCK SEMAPHORE.
> Provided root is already logged in!
> Don't know what happens if you don't have already have a
> superuser Universe session established. I generally keep one
> session like that in the computer room.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
> From: Perry Taylor > > Hrm. Good info. > > How would one go about finding a "hung" port.status semaphore? Red Herring: --- One would *expect* smat -s to indicate it, but no. Toward the bottom of a smat -s it says: Port status State Netnode Owner Collisions Retries Semaphore # 1 00 0 1 13 but State doesn't get changed to 1, Collisions & Retries are not predictably incremented. 1st Symptom: --- The culprit who causes the problem gets an error message. Let's say I'm at a shell prompt, $UVHOME/bin is in my $PATH, I do port.status and try to grep for "root", but mis-type grep: $port.status | gerp root ksh: gerp: not found Abnormal termination of UniVerse. Fault type is 13. Layer type is Verb. $ 2nd Symptom: --- Anyone who subsequently tries to run port.status, whether form unix or tcl prompt, is politely rebuffed: >PORT.STATUS PORT.STATUS is currently being run by another user, try again later. > (After all of this, my smat -s still looks just like the example above: Port status State Netnode Owner Collisions Retries Semaphore # 1 00 0 1 13 Not helpful, or I don't know how to read it.) Solution: At this point root does: >UNLOCK PSTATLOCK SEMAPHORE Please wait, semaphore clear may take as long as 15 seconds. Semaphore cleared. > & everything is back to normal. (& smat -s still reports the same stats as before). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
smat -s from unix:
Here's a snippet of the output:
Login State Netnode Owner Collisions Retries
Semaphore # 1 00 0 3 3
Port status State Netnode Owner Collisions Retries
Semaphore # 1 00 0 0 0
Type 30 fileState Netnode Owner Collisions Retries
Semaphore # 1 00 0 43285049
Note the zero in the state column... It means the semaphore is not set.
Also, there should be 'parity' between the number of collisions versus retries.
By the way, does anyone think there is a problem with my Type 30 file
semaphore? Collisions are about 86% of retries.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Perry Taylor
Sent: Wednesday, November 23, 2005 9:27 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] PORT.STATUS From Unix
Hrm. Good info.
How would one go about finding a "hung" port.status semphore?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Tuesday, November 22, 2005 9:46 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] PORT.STATUS From Unix
> From: Perry Taylor
>
> What would be the indications/complications of this happening?
No one else can run port.status until the port.status semaphore is
cleared.
A more dangerous similar example is locking the login semaphore.
Logins to UV shell are singlethreaded via this semaphore.
uvlictool apparently sets the semaphore so it can do its thing in peace.
If you run uvlictool and pipe the results to a typo ("gerp" instead of
"grep" is one of my favorites), then uvlictool aborts without clearing
the semaphore & no one can log in.
At that point root needs to do UNLOCK LOGINLOCK SEMAPHORE.
Provided root is already logged in!
Don't know what happens if you don't have already have a superuser
Universe session established. I generally keep one session like that in
the computer room.
My workaround is to never run uvlictool directly, but only via a script
that runs it cleanly, captures the result the spits it back out. I can
then pipe stdout with impugnity.
$cat /usr/local/bin/uvlicc
#!/bin/sh
# uvlictool workaround. (see uvlicr, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool clean_lic -a > /tmp/uvlicc.txt ; cat
/tmp/uvlicc.txt
$cat /usr/local/bin/uvlicr
#!/bin/sh
# uvlictool workaround. (see uvlicc, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool report_lic> /tmp/uvlicr.txt ; cat
/tmp/uvlicr.txt
This is kinda rinkydink too, because if userA runs uvlicr, the /tmp file
gets created and is not overwritten when userB runs it. uvlicc is not a
problem since only superuser can run it.
> From: Stevenson, Charles
> yeahbut, be careful not to leave the semaphore set via miss-typing:
> For example if you did:
>$port.status | asdfasf (where asdfasf is garbage.)
> You'll need superuser (or uv administrator?) to do
>>UNLOCK PSTATLOCK SEMAPHORE
> from TCL.
>
> > From: Rod Hills
> >
> > If you display the VOC entry for PORT.STATUS you'll see it calls
> > "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status".
> >
> > Then you can run port.status at the unix level.
> >
> > From: Perry Taylor
> > Does anyone know of a way to run PORT.STATUS externally? I want to
> > process it's output in a shell script without the overhead
> of starting
>
> > up uvsh. Something akin to running smat -r to get the same
> output as
> > LIST.READU from with uvsh. Any ideas?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. ZirMed, Inc. has strict policies regarding the
content of e-mail communications, specifically Protected Health Information,
any communications containing such material will be returned to the originating
party with such advisement noted. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] PORT.STATUS From Unix
When there is no UNIX session logged into UniVerse, you can setup an inode
link with the "list_readu" executable to run "UNLOCK" commands from UNIX :
# cd `cat /.uvhome`
# ln bin/list_readu bin/unlock
# bin/unlock LOGINLOCK SEMAPHORE
Same would apply to run "port.status" commands from UNIX :
# ln bin/list_readu bin/port.status
Hope this will help,
Hervi BALESTRIERI
Support Technique Avanci - Produits "U2"
IBM Software Group - DB2 Information Management Software
Web : http://www.ibm.com/software/u2/
- Forwarded by Herve Balestrieri/France/IBM on 23/11/2005 15:54 -
"Perry Taylor"
<[EMAIL PROTECTED]
med.com> To
Sent by:
[EMAIL PROTECTED] cc
stserver.u2ug.org
Subject
RE: [U2] [UV] PORT.STATUS From Unix
23/11/2005 15:27
Please respond to
u2-users
Hrm. Good info.
How would one go about finding a "hung" port.status semphore?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Tuesday, November 22, 2005 9:46 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] PORT.STATUS From Unix
> From: Perry Taylor
>
> What would be the indications/complications of this happening?
No one else can run port.status until the port.status semaphore is
cleared.
A more dangerous similar example is locking the login semaphore.
Logins to UV shell are singlethreaded via this semaphore.
uvlictool apparently sets the semaphore so it can do its thing in peace.
If you run uvlictool and pipe the results to a typo ("gerp" instead of
"grep" is one of my favorites), then uvlictool aborts without clearing
the semaphore & no one can log in.
At that point root needs to do UNLOCK LOGINLOCK SEMAPHORE.
Provided root is already logged in!
Don't know what happens if you don't have already have a superuser
Universe session established. I generally keep one session like that in
the computer room.
My workaround is to never run uvlictool directly, but only via a script
that runs it cleanly, captures the result the spits it back out. I can
then pipe stdout with impugnity.
$cat /usr/local/bin/uvlicc
#!/bin/sh
# uvlictool workaround. (see uvlicr, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool clean_lic -a > /tmp/uvlicc.txt ; cat
/tmp/uvlicc.txt
$cat /usr/local/bin/uvlicr
#!/bin/sh
# uvlictool workaround. (see uvlicc, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool report_lic> /tmp/uvlicr.txt ; cat
/tmp/uvlicr.txt
This is kinda rinkydink too, because if userA runs uvlicr, the /tmp file
gets created and is not overwritten when userB runs it. uvlicc is not a
problem since only superuser can run it.
> From: Stevenson, Charles
> yeahbut, be careful not to leave the semaphore set via miss-typing:
> For example if you did:
>$port.status | asdfasf (where asdfasf is garbage.)
> You'll need superuser (or uv administrator?) to do
>>UNLOCK PSTATLOCK SEMAPHORE
> from TCL.
>
> > From: Rod Hills
> >
> > If you display the VOC entry for PORT.STATUS you'll see it calls
> > "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status".
> >
> > Then you can run port.status at the unix level.
> >
> > From: Perry Taylor
> > Does anyone know of a way to run PORT.STATUS externally? I want to
> > process it's output in a shell script without the overhead
> of starting
>
> > up uvsh. Something akin to running smat -r to get the same
> output as
> > LIST.READU from with uvsh. Any ideas?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe pl
RE: [U2] [UV] PORT.STATUS From Unix
Hrm. Good info.
How would one go about finding a "hung" port.status semphore?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Tuesday, November 22, 2005 9:46 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] PORT.STATUS From Unix
> From: Perry Taylor
>
> What would be the indications/complications of this happening?
No one else can run port.status until the port.status semaphore is
cleared.
A more dangerous similar example is locking the login semaphore.
Logins to UV shell are singlethreaded via this semaphore.
uvlictool apparently sets the semaphore so it can do its thing in peace.
If you run uvlictool and pipe the results to a typo ("gerp" instead of
"grep" is one of my favorites), then uvlictool aborts without clearing
the semaphore & no one can log in.
At that point root needs to do UNLOCK LOGINLOCK SEMAPHORE.
Provided root is already logged in!
Don't know what happens if you don't have already have a superuser
Universe session established. I generally keep one session like that in
the computer room.
My workaround is to never run uvlictool directly, but only via a script
that runs it cleanly, captures the result the spits it back out. I can
then pipe stdout with impugnity.
$cat /usr/local/bin/uvlicc
#!/bin/sh
# uvlictool workaround. (see uvlicr, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool clean_lic -a > /tmp/uvlicc.txt ; cat
/tmp/uvlicc.txt
$cat /usr/local/bin/uvlicr
#!/bin/sh
# uvlictool workaround. (see uvlicc, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool report_lic> /tmp/uvlicr.txt ; cat
/tmp/uvlicr.txt
This is kinda rinkydink too, because if userA runs uvlicr, the /tmp file
gets created and is not overwritten when userB runs it. uvlicc is not a
problem since only superuser can run it.
> From: Stevenson, Charles
> yeahbut, be careful not to leave the semaphore set via miss-typing:
> For example if you did:
>$port.status | asdfasf (where asdfasf is garbage.)
> You'll need superuser (or uv administrator?) to do
>>UNLOCK PSTATLOCK SEMAPHORE
> from TCL.
>
> > From: Rod Hills
> >
> > If you display the VOC entry for PORT.STATUS you'll see it calls
> > "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status".
> >
> > Then you can run port.status at the unix level.
> >
> > From: Perry Taylor
> > Does anyone know of a way to run PORT.STATUS externally? I want to
> > process it's output in a shell script without the overhead
> of starting
>
> > up uvsh. Something akin to running smat -r to get the same
> output as
> > LIST.READU from with uvsh. Any ideas?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. ZirMed, Inc. has strict policies regarding the
content of e-mail communications, specifically Protected Health Information,
any communications containing such material will be returned to the originating
party with such advisement noted. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
> From: Perry Taylor
>
> What would be the indications/complications of this happening?
No one else can run port.status until the port.status semaphore is
cleared.
A more dangerous similar example is locking the login semaphore.
Logins to UV shell are singlethreaded via this semaphore.
uvlictool apparently sets the semaphore so it can do its thing in peace.
If you run uvlictool and pipe the results to a typo ("gerp" instead of
"grep" is one of my favorites), then uvlictool aborts without clearing
the semaphore & no one can log in.
At that point root needs to do UNLOCK LOGINLOCK SEMAPHORE.
Provided root is already logged in!
Don't know what happens if you don't have already have a superuser
Universe session established. I generally keep one session like that in
the computer room.
My workaround is to never run uvlictool directly, but only via a script
that runs it cleanly, captures the result the spits it back out. I can
then pipe stdout with impugnity.
$cat /usr/local/bin/uvlicc
#!/bin/sh
# uvlictool workaround. (see uvlicr, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool clean_lic -a > /tmp/uvlicc.txt ; cat
/tmp/uvlicc.txt
$cat /usr/local/bin/uvlicr
#!/bin/sh
# uvlictool workaround. (see uvlicc, too.)
# Can't handle being piped to an error without leaving uv login
semaphore set.
# (GTAR 31205) 08/12/02 CDS
`cat /.uvhome`/bin/uvlictool report_lic> /tmp/uvlicr.txt ; cat
/tmp/uvlicr.txt
This is kinda rinkydink too, because if userA runs uvlicr, the /tmp file
gets created and is not overwritten when userB runs it. uvlicc is not a
problem since only superuser can run it.
> From: Stevenson, Charles
> yeahbut, be careful not to leave the semaphore set via miss-typing:
> For example if you did:
>$port.status | asdfasf (where asdfasf is garbage.)
> You'll need superuser (or uv administrator?) to do
>>UNLOCK PSTATLOCK SEMAPHORE
> from TCL.
>
> > From: Rod Hills
> >
> > If you display the VOC entry for PORT.STATUS you'll see it calls
> > "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status".
> >
> > Then you can run port.status at the unix level.
> >
> > From: Perry Taylor
> > Does anyone know of a way to run PORT.STATUS externally? I want to
> > process it's output in a shell script without the overhead
> of starting
>
> > up uvsh. Something akin to running smat -r to get the same
> output as
> > LIST.READU from with uvsh. Any ideas?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
What would be the indications/complications of this happening? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Tuesday, November 22, 2005 3:12 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] PORT.STATUS From Unix yeahbut, be careful not to leave the semaphore set via miss-typing: For examplem if you did: $port.status | asdfasf (where asdfasf is garbage.) You'll need superuser (or uv administrator?) to do >UNLOCK PSTATLOCK SEMAPHORE from TCL. > From: Rod Hills > > If you display the VOC entry for PORT.STATUS you'll see it calls > "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status". > > Then you can run port.status at the unix level. > > From: Perry Taylor > Does anyone know of a way to run PORT.STATUS externally? I want to > process it's output in a shell script without the overhead of starting > up uvsh. Something akin to running smat -r to get the same output as > LIST.READU from with uvsh. Any ideas? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
yeahbut, be careful not to leave the semaphore set via miss-typing: For examplem if you did: $port.status | asdfasf (where asdfasf is garbage.) You'll need superuser (or uv administrator?) to do >UNLOCK PSTATLOCK SEMAPHORE from TCL. > From: Rod Hills > > If you display the VOC entry for PORT.STATUS you'll see it > calls "list_readu". Just "cd /u1/uv/bin" then "ln list_readu > port.status". > > Then you can run port.status at the unix level. > > From: Perry Taylor > Does anyone know of a way to run PORT.STATUS externally? I > want to process it's output in a shell script without the > overhead of starting up uvsh. Something akin to running smat > -r to get the same output as LIST.READU from with uvsh. Any ideas? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
Thank you, Rod! That worked just right! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rod Hills Sent: Tuesday, November 22, 2005 12:50 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] PORT.STATUS From Unix If you display the VOC entry for PORT.STATUS you'll see it calls "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status". Then you can run port.status at the unix level. HTH Rod Hills -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry Taylor Sent: Tuesday, November 22, 2005 10:59 AM To: U2-Users List Subject: [U2] [UV] PORT.STATUS From Unix Does anyone know of a way to run PORT.STATUS externally? I want to process it's output in a shell script without the overhead of starting up uvsh. Something akin to running smat -r to get the same output as LIST.READU from with uvsh. Any ideas? Thanks. Perry Taylor Senior Multi-Value System Architect Zirmed, Inc. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] PORT.STATUS From Unix
If you display the VOC entry for PORT.STATUS you'll see it calls "list_readu". Just "cd /u1/uv/bin" then "ln list_readu port.status". Then you can run port.status at the unix level. HTH Rod Hills -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry Taylor Sent: Tuesday, November 22, 2005 10:59 AM To: U2-Users List Subject: [U2] [UV] PORT.STATUS From Unix Does anyone know of a way to run PORT.STATUS externally? I want to process it's output in a shell script without the overhead of starting up uvsh. Something akin to running smat -r to get the same output as LIST.READU from with uvsh. Any ideas? Thanks. Perry Taylor Senior Multi-Value System Architect Zirmed, Inc. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
