Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

[Doug Averch]

Hi Kathleene:

I'm not to thrilled using any of the uvtools since they are kind of slow and
if I remember they were built using cpio which is not a favorite binary of
mine.  If I'm transferring less then a 100mb, I use our copy and paste
option in our XLr8Editor tool.  We copy about 5 to10mb per second using UOJ,
so it understands the data structure. I can copy from our 32bit Universe to
our 64bit Universe in a few seconds per file.


Regards,
Doug
www.u2logic.com

On Thu, Sep 8, 2011 at 5:46 PM, Kathleené M Hunter <
kmhun...@resolutionprovider.com> wrote:

> Doug,
>
>What method are you using to move the data? Uvback and uvrestore?
> Something else?
>
>The servers are networked together.
>
> Kathleené
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
> Sent: Thursday, September 08, 2011 4:04 PM
> To: U2 Users List
> Subject: Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server
>
> Hi Kathleene:
>
> We do this all of the time you should not have a problem.
>
> Regards,
> Doug
> www.u2logic.com
>
>
> On Thu, Sep 8, 2011 at 12:16 PM, Kathleené M Hunter <
> kmhun...@resolutionprovider.com> wrote:
>
> > Like to know if I can move the data from Windows 2003 UniVerse 11.1.1
> > 32 bit to a Windows 2008 11.1.1 64 bit. What needs to be done or user.
> > Plus can I go back.
> >
> > ___
> > 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-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] Unidata 7.1.22 Index Issue

[Kevin King]

What can I get you Wally?  We did a CREATE.INDEX WO SHOP.CODE NO.NULLS
followed by BUILD.INDEX WO SHOP.CODE.  The index seems to work fine
immediately after.  If the shop code in the record changes, however, the
index does not seem to reflect the change.  This is evidenced by:

DISABLE INDEX WO
SELECT WO WITH SHOP.CODE = "09"
21 items selected
CLEARSELECT
ENABLE.INDEX WO
SELECT WO WITH SHOP.CODE = "09"
19 items selected
CLEARSELECT
DISABLE.INDEX WO
SELECT WO WITH SHOP.CODE = "09"
21 items selected

What else can I get you?

On Thu, Sep 8, 2011 at 5:58 PM, Wally Terhune
wrote:

> Not enough information.
>
> Wally Terhune
> U2 Support Architect
> Rocket Software
> 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA
> Tel: +1.720.475.8055
> Email: wterh...@rs.com
> Web: www.rocketsoftware.com/u2
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:
> u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
> Sent: Thursday, September 08, 2011 5:42 PM
> To: U2 Users List
> Subject: [U2] Unidata 7.1.22 Index Issue
>
> We have a customer on Unidata 7.1.22 running the Prelude application.  They
> have an index on a field in a file that looks like this:
>
> Top of "SHOP.CODE" in "DICT WO", 9 lines, 82 characters.
> *--: P
> 001: V
> 002: EXTRACT(@RECORD,110,2,0)
> 003:
> 004: Shop Code
> 005: 2L
> 006: S
> 007:
> 008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0)
> 009: WO
> Bottom.
>
> Because this field is extracting from @RECORD, we should be able to index
> it
> without problems, right?  However, the reality is starkly different.  The
> other data indexes work fine, but this derived index does not seem to be
> getting updated properly.
>
> -Kevin
> http://www.PrecisOnline.com
> ___
> 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
>



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

Re: [U2] Ardent programmers

[Phil Walker]

PVW is me Phil  Walker
DSM might be David Meeks
WLC is probably Wendy Cleary
JC Jesus Christ ;-)

Others cannot remember

> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
> boun...@listserver.u2ug.org] On Behalf Of Wjhonson
> Sent: Friday, 9 September 2011 12:26 p.m.
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] Ardent programmers
> 
> 
> In my copy of Acct.Stat.B the following programmer initials dating from 1992
> to 2000
> 
> PVW, WLC, AGM, JC, DJD, PEJ, SAP, DSM, LKS
> 
> anyone have long names ?
> 
> 
> ___
> 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] Ardent programmers

[Wjhonson]

In my copy of Acct.Stat.B the following programmer initials dating from 1992 to 
2000

PVW, WLC, AGM, JC, DJD, PEJ, SAP, DSM, LKS

anyone have long names ?


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

Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

[Boydell, Stuart]

Oh, the one gotcha I've encountered using uvbackup/restore between 32 and 64, 
but which shouldn't apply in your case, was moving from RISC to x86 when the 
trigger bit in the header of a file with triggers needs to be manually reset. 
This was UV10.1 and may be fixed by now.
Cheers Stuart

-Original Message-
From: Kathleené M Hunter
Sent: Friday, 9 September 2011 9:47
To: 'U2 Users List'
Subject: Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server


Doug,

What method are you using to move the data? Uvback and uvrestore?
Something else?

The servers are networked together.

Kathleené

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
Sent: Thursday, September 08, 2011 4:04 PM
To: U2 Users List
Subject: Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

Hi Kathleene:

We do this all of the time you should not have a problem.

Regards,
Doug
www.u2logic.com


On Thu, Sep 8, 2011 at 12:16 PM, Kathleené M Hunter <
kmhun...@resolutionprovider.com> wrote:

> Like to know if I can move the data from Windows 2003 UniVerse 11.1.1
> 32 bit to a Windows 2008 11.1.1 64 bit. What needs to be done or user.
> Plus can I go back.
>
> ___
> 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-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] Unidata 7.1.22 Index Issue

[Wally Terhune]

Not enough information.

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2



-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 5:42 PM
To: U2 Users List
Subject: [U2] Unidata 7.1.22 Index Issue

We have a customer on Unidata 7.1.22 running the Prelude application.  They
have an index on a field in a file that looks like this:

Top of "SHOP.CODE" in "DICT WO", 9 lines, 82 characters.
*--: P
001: V
002: EXTRACT(@RECORD,110,2,0)
003:
004: Shop Code
005: 2L
006: S
007:
008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0)
009: WO
Bottom.

Because this field is extracting from @RECORD, we should be able to index it
without problems, right?  However, the reality is starkly different.  The
other data indexes work fine, but this derived index does not seem to be
getting updated properly.

-Kevin
http://www.PrecisOnline.com
___
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] Move UniVerse Data from 32 bit server to 64 bit server

[Bill Haskett]

With respect to UniData, we moved from Windows 2003 Server to Windows 
2008 R2.  I had to upgrade to UniData v7.2.7 and they fixed a 
permissions problem in STARTPTR (I think).  Other than that, everything 
worked as it had previously.


I suspect UV is the same thing.  Contact Rocket to find out which 
version of UV is Win2008 R2 certified.


Bill


- Original Message -
*From:* kmhun...@resolutionprovider.com
*To:* 'U2 Users List' 
*Date:* 9/8/2011 4:46 PM
*Subject:* Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

Doug,

What method are you using to move the data? Uvback and uvrestore?
Something else?

The servers are networked together.

Kathleené

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
Sent: Thursday, September 08, 2011 4:04 PM
To: U2 Users List
Subject: Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

Hi Kathleene:

We do this all of the time you should not have a problem.

Regards,
Doug
www.u2logic.com


On Thu, Sep 8, 2011 at 12:16 PM, Kathleené M Hunter<
kmhun...@resolutionprovider.com>  wrote:


Like to know if I can move the data from Windows 2003 UniVerse 11.1.1
32 bit to a Windows 2008 11.1.1 64 bit. What needs to be done or user.
Plus can I go back.

___
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-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] Move UniVerse Data from 32 bit server to 64 bit server

[Kathleené M Hunter]

Doug,

What method are you using to move the data? Uvback and uvrestore?
Something else?

The servers are networked together.

Kathleené

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
Sent: Thursday, September 08, 2011 4:04 PM
To: U2 Users List
Subject: Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

Hi Kathleene:

We do this all of the time you should not have a problem.

Regards,
Doug
www.u2logic.com


On Thu, Sep 8, 2011 at 12:16 PM, Kathleené M Hunter <
kmhun...@resolutionprovider.com> wrote:

> Like to know if I can move the data from Windows 2003 UniVerse 11.1.1 
> 32 bit to a Windows 2008 11.1.1 64 bit. What needs to be done or user. 
> Plus can I go back.
>
> ___
> 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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

[U2] Unidata 7.1.22 Index Issue

[Kevin King]

We have a customer on Unidata 7.1.22 running the Prelude application.  They
have an index on a field in a file that looks like this:

Top of "SHOP.CODE" in "DICT WO", 9 lines, 82 characters.
*--: P
001: V
002: EXTRACT(@RECORD,110,2,0)
003:
004: Shop Code
005: 2L
006: S
007:
008: SHOP.CODEýýEXTRACT(@RECORD,110,2,0)
009: WO
Bottom.

Because this field is extracting from @RECORD, we should be able to index it
without problems, right?  However, the reality is starkly different.  The
other data indexes work fine, but this derived index does not seem to be
getting updated properly.

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

Re: [U2] Move UniVerse Data from 32 bit server to 64 bit server

[Boydell, Stuart]

Should be straightforward using uvbackup and uvrestore to go either way.
Stuart.

-Original Message-
From: Kathleené M Hunter
Sent: Friday, 9 September 2011 4:21
To: 'U2 Users List'
Subject: [U2] Move UniVerse Data from 32 bit server to 64 bit server


Like to know if I can move the data from Windows 2003 UniVerse 11.1.1 32 bit
to a Windows 2008 11.1.1 64 bit. What needs to be done or user. Plus can I
go back.

___
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] Move UniVerse Data from 32 bit server to 64 bit server

[Doug Averch]

Hi Kathleene:

We do this all of the time you should not have a problem.

Regards,
Doug
www.u2logic.com


On Thu, Sep 8, 2011 at 12:16 PM, Kathleené M Hunter <
kmhun...@resolutionprovider.com> wrote:

> Like to know if I can move the data from Windows 2003 UniVerse 11.1.1 32
> bit
> to a Windows 2008 11.1.1 64 bit. What needs to be done or user. Plus can I
> go back.
>
> ___
> 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] Lock Status

[Mecki Foerthmann]

Now that's a program I'd like to see.
I've been trying to write one that makes cups of coffee, but so far no 
luck.:-D
I always tell my clients when they ask me for things that can't be done 
without rewriting the whole system, that I will do the impossible 
straight away, but miracles may take a bit longer.


Mecki

On 08/09/2011 21:48, Wjhonson wrote:

If you rewrote your system to whip eggs, then it would whip eggs.
But this doesn't fix the underlying issue that there are many systems already 
out there, which cannot whip eggs.

And which you do not have the luxury to rewrite, but have to live with them the 
way they are.
There IS a way to get around this problem, but not retroactively, only 
proactively.





-Original Message-
From: Mecki Foerthmann
To: u2-users
Sent: Thu, Sep 8, 2011 1:28 pm
Subject: Re: [U2] Lock Status


I dare to disagree.
f you ALWAYS use a subroutine that records the pid, the file, item Id
nd program on a logfile when you want to read and lock a record and
LWAYS use a subroutine that removes the info from the logfile to write
r release this could work.
therwise it won't.
On 08/09/2011 20:39, Wjhonson wrote:
  This still would not be accurate for the reasons already stated.
  The call stack only shows you what routine is on the stack.  If the lock had
een set for hours, who knows what routine was there previously?
  As you yourself stated, locks can persist, after the routine which created
hem has gone away.

  The only viable solution is to record the lock at the time it is set.






  -Original Message-
  From: George Hammerle
  To: u2-users
  Sent: Thu, Sep 8, 2011 12:36 pm
  Subject: Re: [U2] Lock Status



  ven if the program ended that locked the item, the lock could still be
  aintained if the file variable was passed.
  I know this is after the fact but, one option going forward would be to write

  rapper program for READU's and call it "LOCK.RECORD". I use this approach
  xtensively.
  CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )
  1. If it is a phantom, perform a READU
  . If it is a real user, use the LOCKED clause
  a. If it is locked, display whom has it locked followed by an INPUT ( if it is
  B+, use a DISP ).
  b. If it is not locked, lock it.
This allows them to see who has them locked and contact the guilty party
  . NEW OPTION : Once locked, you could get the call stack and record to a file
  hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add
  n additional parameter to this sub and pass in the program name.

  e already do 1 and 2, but 3 would be an interesting option.

  e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to
  scape if the record is locked and it also displays who has them locked. We
nly
  se this option when it is safe to escape and it sends back "ESCAPED" 1 or 0 so
  e can handle the escape properly.


  This e-mail and any files transmitted with it are confidential and intended
  olely for the use of the individual or company to whom they are addressed. If
  ou have received this e-mail in error, please notify the sender immediately
nd
  elete this e-mail including all attachments from your system. Thank you
  __
  2-Users mailing list
  2-us...@listserver.u2ug.org
  ttp://listserver.u2ug.org/mailman/listinfo/u2-users

  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[John Hester]

I just realized there also needs to be a 3rd step in the process below
that removes any logging of locks that have since been released.  In the
following sequence of events:

Program A locks record R
Program A calls subroutine B
Program A calls subroutine C
Program A releases record R

Subroutines B and C will falsely accuse program A of leaving an
unresolved lock.  The next subroutine that runs following the release in
program A needs to check for this and remove the lock log for record R.
That way when the user eventually logs off you're only left with logs of
the locks that never went away.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester
Sent: Thursday, September 08, 2011 1:36 PM
To: U2 Users List
Subject: Re: [U2] Lock Status

You might be able to implement this capability from within the programs
themselves without a huge amount of effort.  We have a small program
tracking subroutine and a companion utility that automatically installs
a call to it from every program.  The original purpose was to determine
which code was still in use for our initial conversion from Ultimate to
UV 15 years ago, but it's come in handy for isolating anomolies over the
years.  The call statement is simply:

CALL TRACKER('THIS.PROGRAM')

The utility goes through all programs on a weekly basis during nightly
batch processing, adds that line at the top if it doesn't exist
(following the "SUBROUTINE" line), and recompiles the program.  The
tracker program writes a log record where the ID is the user and the
data is a sequential list of programs as well as a record where the ID
is the program and the data is a sequential list of users.  For your
lock issue, you could take this a step further and:

1) Check to see if this session is still hanging onto locks from the
previously called subroutine
2) Figure out what subroutine was previously called from the log record
and log the locks still being held

You will also have to come up with a method of insuring you only log the
initial instance, but I think that should be do-able.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 1:01 PM
To: U2 Users List
Subject: Re: [U2] Lock Status

Thank you goes out to everyone for the input.  We were able to identify
(and
as of this moment it would appear correct) a couple of suspects by
looking
at the code that had been compiled within the last 2 weeks and
evaluating
each routine separately.  I still think it'd be cool to be able to see
which
program set which locks retrospectively, though I completely understand
Wally's perspective about the effort involved to make that happen.

-K
___
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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Wjhonson]

If you rewrote your system to whip eggs, then it would whip eggs.
But this doesn't fix the underlying issue that there are many systems already 
out there, which cannot whip eggs.

And which you do not have the luxury to rewrite, but have to live with them the 
way they are.
There IS a way to get around this problem, but not retroactively, only 
proactively.





-Original Message-
From: Mecki Foerthmann 
To: u2-users 
Sent: Thu, Sep 8, 2011 1:28 pm
Subject: Re: [U2] Lock Status


I dare to disagree.
f you ALWAYS use a subroutine that records the pid, the file, item Id 
nd program on a logfile when you want to read and lock a record and 
LWAYS use a subroutine that removes the info from the logfile to write 
r release this could work.
therwise it won't.
On 08/09/2011 20:39, Wjhonson wrote:
 This still would not be accurate for the reasons already stated.
 The call stack only shows you what routine is on the stack.  If the lock had 
een set for hours, who knows what routine was there previously?
 As you yourself stated, locks can persist, after the routine which created 
hem has gone away.

 The only viable solution is to record the lock at the time it is set.






 -Original Message-
 From: George Hammerle
 To: u2-users
 Sent: Thu, Sep 8, 2011 12:36 pm
 Subject: Re: [U2] Lock Status



 ven if the program ended that locked the item, the lock could still be
 aintained if the file variable was passed.
 I know this is after the fact but, one option going forward would be to write 

 rapper program for READU's and call it "LOCK.RECORD". I use this approach
 xtensively.
 CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )
 1. If it is a phantom, perform a READU
 . If it is a real user, use the LOCKED clause
 a. If it is locked, display whom has it locked followed by an INPUT ( if it is
 B+, use a DISP ).
 b. If it is not locked, lock it.
   This allows them to see who has them locked and contact the guilty party
 . NEW OPTION : Once locked, you could get the call stack and record to a file
 hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add
 n additional parameter to this sub and pass in the program name.

 e already do 1 and 2, but 3 would be an interesting option.

 e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to
 scape if the record is locked and it also displays who has them locked. We 
nly
 se this option when it is safe to escape and it sends back "ESCAPED" 1 or 0 so
 e can handle the escape properly.


 This e-mail and any files transmitted with it are confidential and intended
 olely for the use of the individual or company to whom they are addressed. If
 ou have received this e-mail in error, please notify the sender immediately 
nd
 elete this e-mail including all attachments from your system. Thank you
 __
 2-Users mailing list
 2-us...@listserver.u2ug.org
 ttp://listserver.u2ug.org/mailman/listinfo/u2-users

 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Lock Status

[John Hester]

You might be able to implement this capability from within the programs
themselves without a huge amount of effort.  We have a small program
tracking subroutine and a companion utility that automatically installs
a call to it from every program.  The original purpose was to determine
which code was still in use for our initial conversion from Ultimate to
UV 15 years ago, but it's come in handy for isolating anomolies over the
years.  The call statement is simply:

CALL TRACKER('THIS.PROGRAM')

The utility goes through all programs on a weekly basis during nightly
batch processing, adds that line at the top if it doesn't exist
(following the "SUBROUTINE" line), and recompiles the program.  The
tracker program writes a log record where the ID is the user and the
data is a sequential list of programs as well as a record where the ID
is the program and the data is a sequential list of users.  For your
lock issue, you could take this a step further and:

1) Check to see if this session is still hanging onto locks from the
previously called subroutine
2) Figure out what subroutine was previously called from the log record
and log the locks still being held

You will also have to come up with a method of insuring you only log the
initial instance, but I think that should be do-able.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 1:01 PM
To: U2 Users List
Subject: Re: [U2] Lock Status

Thank you goes out to everyone for the input.  We were able to identify
(and
as of this moment it would appear correct) a couple of suspects by
looking
at the code that had been compiled within the last 2 weeks and
evaluating
each routine separately.  I still think it'd be cool to be able to see
which
program set which locks retrospectively, though I completely understand
Wally's perspective about the effort involved to make that happen.

-K
___
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] Lock Status

[Mecki Foerthmann]

I dare to disagree.
If you ALWAYS use a subroutine that records the pid, the file, item Id 
and program on a logfile when you want to read and lock a record and 
ALWAYS use a subroutine that removes the info from the logfile to write 
or release this could work.

Otherwise it won't.

On 08/09/2011 20:39, Wjhonson wrote:

This still would not be accurate for the reasons already stated.
The call stack only shows you what routine is on the stack.  If the lock had 
been set for hours, who knows what routine was there previously?
As you yourself stated, locks can persist, after the routine which created them 
has gone away.

The only viable solution is to record the lock at the time it is set.






-Original Message-
From: George Hammerle
To: u2-users
Sent: Thu, Sep 8, 2011 12:36 pm
Subject: Re: [U2] Lock Status



ven if the program ended that locked the item, the lock could still be
aintained if the file variable was passed.
I know this is after the fact but, one option going forward would be to write a
rapper program for READU's and call it "LOCK.RECORD". I use this approach
xtensively.
CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )
1. If it is a phantom, perform a READU
. If it is a real user, use the LOCKED clause
a. If it is locked, display whom has it locked followed by an INPUT ( if it is
B+, use a DISP ).
b. If it is not locked, lock it.
  This allows them to see who has them locked and contact the guilty party
. NEW OPTION : Once locked, you could get the call stack and record to a file
hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add
n additional parameter to this sub and pass in the program name.

e already do 1 and 2, but 3 would be an interesting option.

e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to
scape if the record is locked and it also displays who has them locked. We only
se this option when it is safe to escape and it sends back "ESCAPED" 1 or 0 so
e can handle the escape properly.


This e-mail and any files transmitted with it are confidential and intended
olely for the use of the individual or company to whom they are addressed. If
ou have received this e-mail in error, please notify the sender immediately and
elete this e-mail including all attachments from your system. Thank you
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Kevin King]

Thank you goes out to everyone for the input.  We were able to identify (and
as of this moment it would appear correct) a couple of suspects by looking
at the code that had been compiled within the last 2 weeks and evaluating
each routine separately.  I still think it'd be cool to be able to see which
program set which locks retrospectively, though I completely understand
Wally's perspective about the effort involved to make that happen.

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

Re: [U2] Lock Status

[Wjhonson]

This still would not be accurate for the reasons already stated.
The call stack only shows you what routine is on the stack.  If the lock had 
been set for hours, who knows what routine was there previously?
As you yourself stated, locks can persist, after the routine which created them 
has gone away.

The only viable solution is to record the lock at the time it is set.






-Original Message-
From: George Hammerle 
To: u2-users 
Sent: Thu, Sep 8, 2011 12:36 pm
Subject: Re: [U2] Lock Status



ven if the program ended that locked the item, the lock could still be 
aintained if the file variable was passed.
I know this is after the fact but, one option going forward would be to write a 
rapper program for READU's and call it "LOCK.RECORD". I use this approach 
xtensively.
CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )
1. If it is a phantom, perform a READU
. If it is a real user, use the LOCKED clause 
a. If it is locked, display whom has it locked followed by an INPUT ( if it is 
B+, use a DISP ).
b. If it is not locked, lock it.
 This allows them to see who has them locked and contact the guilty party
. NEW OPTION : Once locked, you could get the call stack and record to a file 
hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add 
n additional parameter to this sub and pass in the program name. 

e already do 1 and 2, but 3 would be an interesting option. 

e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to 
scape if the record is locked and it also displays who has them locked. We only 
se this option when it is safe to escape and it sends back "ESCAPED" 1 or 0 so 
e can handle the escape properly.


This e-mail and any files transmitted with it are confidential and intended
olely for the use of the individual or company to whom they are addressed. If
ou have received this e-mail in error, please notify the sender immediately and
elete this e-mail including all attachments from your system. Thank you
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Lock Status

[George Hammerle]

Even if the program ended that locked the item, the lock could still be 
maintained if the file variable was passed.

I know this is after the fact but, one option going forward would be to write a 
wrapper program for READU's and call it "LOCK.RECORD". I use this approach 
extensively.

CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )

1. If it is a phantom, perform a READU
2. If it is a real user, use the LOCKED clause 
2a. If it is locked, display whom has it locked followed by an INPUT ( if it is 
SB+, use a DISP ).
2b. If it is not locked, lock it.
* This allows them to see who has them locked and contact the guilty party
3. NEW OPTION : Once locked, you could get the call stack and record to a file 
which program locked it ( excluding this sub - LOCK.RECORD ). Or you could add 
an additional parameter to this sub and pass in the program name. 


We already do 1 and 2, but 3 would be an interesting option. 


We also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to 
escape if the record is locked and it also displays who has them locked. We 
only use this option when it is safe to escape and it sends back "ESCAPED" 1 or 
0 so we can handle the escape properly.





This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or company to whom they are addressed. If
you have received this e-mail in error, please notify the sender immediately and
delete this e-mail including all attachments from your system. Thank you
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Wjhonson]

Port.status shows what is currently running on that PID
Not what was running when the lock was set.

The "process" is not the "program".  You are using the words interchangebly 
when they are not.
A process can run a long stack up and down adding and pruning.  The call stack 
only shows the current stack of the stack, not what the state was when the lock 
was set.

If a member of the old call stack had set a lock, that lock persists until the 
entire call stack is completely depleted.
Which could be 20 routines later.





-Original Message-
From: Jeff Schasny 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 11:30 am
Subject: Re: [U2] Lock Status


I disagree.
If I run LIST.READU and note the PID of a process holding a lock on an 
tem then run PORT.STATUS on that PID the only way that the program 
hown by PORT.STATUS as currently running is not the process holding the 
ock would be if the program ended (thus dropping the lock) before I ran 
he PORT.STATUS.
Wjhonson wrote:
 That's not the case.
 PORT.STATUS shows you what that PID is currently doing when you run it.
 Not what it was doing an hour ago for example.
 Not what it was doing when it set the lock.
 Just what it's doing now.
 In Unix/Universe world.

 If you are so lucky to know about the lock *right when* it's being set, then 
ou are right.
 But in my experience that is a very rare occurence.
 And in this particular example, he already stated that it was a lock left set 
ome time earlier.
 You can only know the program being run by that PID if that program is in some 
ort of waiting condition and had been waiting since it set the lock.

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

Re: [U2] Lock Status

[Jeff Schasny]

I disagree.

If I run LIST.READU and note the PID of a process holding a lock on an 
item then run PORT.STATUS on that PID the only way that the program 
shown by PORT.STATUS as currently running is not the process holding the 
lock would be if the program ended (thus dropping the lock) before I ran 
the PORT.STATUS.


Wjhonson wrote:

That's not the case.
PORT.STATUS shows you what that PID is currently doing when you run it.
Not what it was doing an hour ago for example.
Not what it was doing when it set the lock.
Just what it's doing now.
In Unix/Universe world.

If you are so lucky to know about the lock *right when* it's being set, then 
you are right.
But in my experience that is a very rare occurence.
And in this particular example, he already stated that it was a lock left set 
some time earlier.
You can only know the program being run by that PID if that program is in some 
sort of waiting condition and had been waiting since it set the lock.







-Original Message-
From: Jeff Schasny 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 10:30 am
Subject: Re: [U2] Lock Status


I believe that if the program ended the lock would be released, so by 
inding the PID via LIST.READU and then determining the program name 
ssociated with the PID via PORT.STATUS you are identifying the program 
hich currently holds the lock unless the program ends between the 
IST.READU and PORT.STATUS.

At least in my Unix/Universe world.
Wjhonson wrote:
 This won't work unless the program is halted-waiting.
 Most likely it's moved on to do a hundred other things since the lock in 
uestion, but left it hanging because the pid is still living.
 If the pid dies it would release the lock, but for example, even on non-SB 
ystems, phantoms which run constantly can leave locks hanging forever.






 -Original Message-
 From: Jeff Schasny 
 To: U2 Users List 
 Sent: Thu, Sep 8, 2011 8:34 am
 Subject: Re: [U2] Lock Status


 Kevin,
 I think that the closest you are going to be able to get is the program 
 n question using LIST.READU to determine the PID and PORT.STATUS to 
 hen find the program. I don't know of any way to dynamically get to the 
 rogram line number from there. You could, of course, just look through 
 he program source and the READUs then make an educated guess from there.

 Kevin King wrote:
  Unfortunately, no love there either John.  I even went to the GETREADU( .. )
  function in BASIC.. nothing there.
  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users


   
  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

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

[U2] Move UniVerse Data from 32 bit server to 64 bit server

[Kathleené M Hunter]

Like to know if I can move the data from Windows 2003 UniVerse 11.1.1 32 bit
to a Windows 2008 11.1.1 64 bit. What needs to be done or user. Plus can I
go back.

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

Re: [U2] Lock Status

[Wally Terhune]

Not exactly trivial. Would require a new structure to be added to the table and 
changes to all associated routines that access and maintain this shared memory 
table.

Also - UniData record locks are tied to a file variable. So even if the 
'program ends', if the file variable is in COMMON and therefore not closed 
(local variables closed when program ends), the lock would persist.

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2




-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Thursday, September 08, 2011 9:39 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

On Thu, Sep 8, 2011 at 11:34 AM, Kevin King  wrote:
> We do suspect it is from a custom BASIC subroutine, recently installed.  So
> knowing the file we're looking back through any code that was compiled
> within the past 2 weeks and manually searching for READU's that don't WRITE,
> DELETE, or RELEASE.  Sure would be nice if the lock table would report the
> line of code that set the lock.  Just sayin'.
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>

That does seem like it would be a trivial and cool addition.  Maybe
just on an option switch.
___
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] Lock Status

[Wjhonson]

That's not the case.
PORT.STATUS shows you what that PID is currently doing when you run it.
Not what it was doing an hour ago for example.
Not what it was doing when it set the lock.
Just what it's doing now.
In Unix/Universe world.

If you are so lucky to know about the lock *right when* it's being set, then 
you are right.
But in my experience that is a very rare occurence.
And in this particular example, he already stated that it was a lock left set 
some time earlier.
You can only know the program being run by that PID if that program is in some 
sort of waiting condition and had been waiting since it set the lock.







-Original Message-
From: Jeff Schasny 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 10:30 am
Subject: Re: [U2] Lock Status


I believe that if the program ended the lock would be released, so by 
inding the PID via LIST.READU and then determining the program name 
ssociated with the PID via PORT.STATUS you are identifying the program 
hich currently holds the lock unless the program ends between the 
IST.READU and PORT.STATUS.
At least in my Unix/Universe world.
Wjhonson wrote:
 This won't work unless the program is halted-waiting.
 Most likely it's moved on to do a hundred other things since the lock in 
uestion, but left it hanging because the pid is still living.
 If the pid dies it would release the lock, but for example, even on non-SB 
ystems, phantoms which run constantly can leave locks hanging forever.





 -Original Message-
 From: Jeff Schasny 
 To: U2 Users List 
 Sent: Thu, Sep 8, 2011 8:34 am
 Subject: Re: [U2] Lock Status


 Kevin,
 I think that the closest you are going to be able to get is the program 
 n question using LIST.READU to determine the PID and PORT.STATUS to 
 hen find the program. I don't know of any way to dynamically get to the 
 rogram line number from there. You could, of course, just look through 
 he program source and the READUs then make an educated guess from there.
 Kevin King wrote:
  Unfortunately, no love there either John.  I even went to the GETREADU( .. )
  function in BASIC.. nothing there.
  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users


   
-- 
---
eff Schasny - Denver, Co, USA
schasny at gmail dot com
---
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Lock Status

[Jeff Schasny]

I believe that if the program ended the lock would be released, so by 
finding the PID via LIST.READU and then determining the program name 
associated with the PID via PORT.STATUS you are identifying the program 
which currently holds the lock unless the program ends between the 
LIST.READU and PORT.STATUS.


At least in my Unix/Universe world.

Wjhonson wrote:

This won't work unless the program is halted-waiting.
Most likely it's moved on to do a hundred other things since the lock in 
question, but left it hanging because the pid is still living.
If the pid dies it would release the lock, but for example, even on non-SB 
systems, phantoms which run constantly can leave locks hanging forever.





-Original Message-
From: Jeff Schasny 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 8:34 am
Subject: Re: [U2] Lock Status


Kevin,
I think that the closest you are going to be able to get is the program 
n question using LIST.READU to determine the PID and PORT.STATUS to 
hen find the program. I don't know of any way to dynamically get to the 
rogram line number from there. You could, of course, just look through 
he program source and the READUs then make an educated guess from there.

Kevin King wrote:
 Unfortunately, no love there either John.  I even went to the GETREADU( .. )
 function in BASIC.. nothing there.
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users

   
  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

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

Re: [U2] DataVu Query [ad]

[Wjhonson]

Obviously your install team did not include a 55 year old school teacher and an 
8 year old boy!





-Original Message-
From: David Jordan 
To: U2 Users List 
Sent: Wed, Sep 7, 2011 7:45 pm
Subject: Re: [U2] DataVu Query [ad]


Hi Steve
here have been 2 betas and I have been on both and requests were made through 
he Rocket newsletter.   The issues are probably a combination of people 
mplementing on a broader spectrum of environments than was tested and also an 
ssue of not being as intuitive to install.
Regards
avid Jordan
-Original Message-
rom: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 
n Behalf Of Steve Romanow
ent: Thursday, 8 September 2011 11:27 AM
o: U2 Users List
ubject: Re: [U2] DataVu Query [ad]
That is cool. Wish we could have done a beta and help shake some of these out.
Thank you Rocket for continuing to push the platform.
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://listserver.u2ug.org/mailman/listinfo/u2-users
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Free Software for DataBasic

[Wjhonson]

Fix... the... URL!
http://109.104.64.69/cms/cmshome.wsp

Ugly ugly ugh






-Original Message-
From: Glenn Sallis 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 8:46 am
Subject: Re: [U2] Free Software for DataBasic


All,
If anyone does have code samples (other than games!) of how to achieve 
pecific tasks that they would like to share, please do so at the U2UG 
ebsite: www.u2ug.org by following the wiki link.
This is your resource provided to you by the U2UG Board for everything 
2 related. Please use it and contribute to it, as it will only be 
ctive if you do contribute to it.
Kind regards
lenn Sallis


m 08.09.2011 17:21, schrieb DavidJMurray (mvdbs.com):
 Over the last weekend, I noticed that the pickwiki.com (the common mv code
 website) does not have any games programmes.

 I can remember playing the star-trek and adventure games on a Ultimate (or
 Altos I think), many years ago.

 Does anyone have any remnant or complete code that they can (legally) and
 would be willing to contribute to pickwiki.com?



 -

 Learn and Do
 Excel and Share


 http://mvdbs.com http://mvdbs.com
___
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Lock Status

[Wjhonson]

This won't work unless the program is halted-waiting.
Most likely it's moved on to do a hundred other things since the lock in 
question, but left it hanging because the pid is still living.
If the pid dies it would release the lock, but for example, even on non-SB 
systems, phantoms which run constantly can leave locks hanging forever.





-Original Message-
From: Jeff Schasny 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 8:34 am
Subject: Re: [U2] Lock Status


Kevin,
I think that the closest you are going to be able to get is the program 
n question using LIST.READU to determine the PID and PORT.STATUS to 
hen find the program. I don't know of any way to dynamically get to the 
rogram line number from there. You could, of course, just look through 
he program source and the READUs then make an educated guess from there.
Kevin King wrote:
 Unfortunately, no love there either John.  I even went to the GETREADU( .. )
 function in BASIC.. nothing there.
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users

   
-- 
---
eff Schasny - Denver, Co, USA
schasny at gmail dot com
---
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Lock Status

[Charlie Noah]

I think I worked for him once!  ;^)

Charlie Noah

On 09-08-2011 11:11 AM, Colin Alfke wrote:

Just don't do what one of my old bosses did (he was having trouble with SB+
holding locks) - he found one of our main processes and put in "RELEASE".
Our system relied heavily on pessimistic locking so this caused quite a bit
of data loss. Of course, I was the one that had to clean it all up (he
didn't like the names I called him after that one). Of course, this was the
same genius that taught an entire site to useq to stop their PC's
from beeping... but didn't bother to explain that you shouldn't reboot and
try the same thing again.

Good luck

Colin

-Original Message-
From: Kevin King

We do suspect it is from a custom BASIC subroutine, recently installed.  So
knowing the file we're looking back through any code that was compiled
within the past 2 weeks and manually searching for READU's that don't WRITE,
DELETE, or RELEASE.  Sure would be nice if the lock table would report the
line of code that set the lock.  Just sayin'.


___
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] Lock Status

[Wjhonson]

Kevin sorry but no.
There is no function that will tell you the "line of code" or even the program 
which set a lock.

You could however, as others have suggested determine the PID which set it, AND 
(not OR) write a routine which wakes up every five minutes and copies the 
current lock table into a history item, compare and contrast so you can get a 
running map of exactly WHEN and by WHOM the nasty lock is being set.

Then after you run that for a week, send the results to the Vendor and say, "OK 
now fix it bozo!"
Optionally you can leave off "bozo".





-Original Message-
From: Kevin King 
To: U2 Users List 
Sent: Thu, Sep 8, 2011 8:20 am
Subject: Re: [U2] Lock Status


Unfortunately, no love there either John.  I even went to the GETREADU( .. )
unction in BASIC.. nothing there.
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://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] Lock Status

[Colin Alfke]

Just don't do what one of my old bosses did (he was having trouble with SB+
holding locks) - he found one of our main processes and put in "RELEASE".
Our system relied heavily on pessimistic locking so this caused quite a bit
of data loss. Of course, I was the one that had to clean it all up (he
didn't like the names I called him after that one). Of course, this was the
same genius that taught an entire site to use q to stop their PC's
from beeping... but didn't bother to explain that you shouldn't reboot and
try the same thing again.

Good luck

Colin

-Original Message-
From: Kevin King

We do suspect it is from a custom BASIC subroutine, recently installed.  So
knowing the file we're looking back through any code that was compiled
within the past 2 weeks and manually searching for READU's that don't WRITE,
DELETE, or RELEASE.  Sure would be nice if the lock table would report the
line of code that set the lock.  Just sayin'.


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

[U2] [UV] Adding a multi-vaue using SQL UPDATE

[Perry Taylor]

I have a need to add an additional value to a multi-valued field on a bunch of 
records.  I was hoping I could do this using SQL UPDATE but it appears you have 
to explicitly list all the muli-values...

UPDATE FILE SET MVFIELD = <'FIRST', 'SECOND', 'THIRD', 'THE.NEW.VALUE'>;

Anyone know of way to append a new value using UPDATE?

Thanks.

Perry

Perry Taylor
Senior MV Architect
ZirMed
888 West Market Street, Suite 400
Louisville, KY 40202
www.zirmed.com



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
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Dave Davis]

If only the lock table was an actual hashed file that you could place an update 
trigger on.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 11:15 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

That's useful for determining where that port is, but we have a process
leaving rogue locks lying around.  Anything that tells what updated the lock
table?

On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
wrote:

> Once you know the pid of the program with the lock, you can use PORT.STATUS
> to determine this. You just need to use the CALL.STACK option. IIRC (It's
> been a few months) it would be like:
>
> PORT.STATUS PID  CALL.STACK
>
> Regards,
> Dan
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:
> u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
> Sent: Thursday, September 08, 2011 9:06 AM
> To: U2 Users List
> Subject: [U2] Lock Status
>
> Is there anything in Unidata that would report the line of code that set a
> particular record lock?
>
> -Kevin
> http://www.PrecisOnline.com
> ___
> 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
>



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


 Dave Davis Team Lead, R&D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.


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

Re: [U2] Free Software for DataBasic

[Glenn Sallis]

All,

If anyone does have code samples (other than games!) of how to achieve 
specific tasks that they would like to share, please do so at the U2UG 
website: www.u2ug.org by following the wiki link.


This is your resource provided to you by the U2UG Board for everything 
U2 related. Please use it and contribute to it, as it will only be 
active if you do contribute to it.


Kind regards
Glenn Sallis




Am 08.09.2011 17:21, schrieb DavidJMurray (mvdbs.com):

Over the last weekend, I noticed that the pickwiki.com (the common mv code
website) does not have any games programmes.

I can remember playing the star-trek and adventure games on a Ultimate (or
Altos I think), many years ago.

Does anyone have any remnant or complete code that they can (legally) and
would be willing to contribute to pickwiki.com?



-

Learn and Do
Excel and Share


http://mvdbs.com http://mvdbs.com


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

Re: [U2] Lock Status

[John Thompson]

Yeah PORT.STATUS on Universe will tell you the "last command" run by the
"floating user number" of the user...

So if you were able to get the UserNo from LIST.READU EVERY output, and then
cross reference that with the PORT.STATUS output, perhaps you could at least
narrow it down.

Of course that would require you knowing the program name that you were
looking for...

So if you knew the program name you were looking for, maybe you could in a
BASIC program:

1) Execute and Capture LIST.READU EVERY output.
2) Execute and Capture PORT.STATUS output.
3) Then look through PORT.STATUS and find the program you were looking for
or the UserNo you were looking for and display just that line...

-Or if you new a series of Unix user names that might be setting you could
look at only those...

Just thinking out loud...

On Thu, Sep 8, 2011 at 11:34 AM, Jeff Schasny  wrote:

> Kevin,
>
> I think that the closest you are going to be able to get is the program in
> question using LIST.READU to determine the PID and PORT.STATUS to then find
> the program. I don't know of any way to dynamically get to the program line
> number from there. You could, of course, just look through the program
> source and the READUs then make an educated guess from there.
>
>
> Kevin King wrote:
>
>> Unfortunately, no love there either John.  I even went to the GETREADU( ..
>> )
>> function in BASIC.. nothing there.
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>>
>>
>>
>
> --
> --**--**
> 
> Jeff Schasny - Denver, Co, USA
> jschasny at gmail dot com
> --**--**
> 
>
> __**_
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/**mailman/listinfo/u2-users
>



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

Re: [U2] Lock Status

[Steve Romanow]

On Thu, Sep 8, 2011 at 11:34 AM, Kevin King  wrote:
> We do suspect it is from a custom BASIC subroutine, recently installed.  So
> knowing the file we're looking back through any code that was compiled
> within the past 2 weeks and manually searching for READU's that don't WRITE,
> DELETE, or RELEASE.  Sure would be nice if the lock table would report the
> line of code that set the lock.  Just sayin'.
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>

That does seem like it would be a trivial and cool addition.  Maybe
just on an option switch.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Jeff Schasny]

Kevin,

I think that the closest you are going to be able to get is the program 
in question using LIST.READU to determine the PID and PORT.STATUS to 
then find the program. I don't know of any way to dynamically get to the 
program line number from there. You could, of course, just look through 
the program source and the READUs then make an educated guess from there.


Kevin King wrote:

Unfortunately, no love there either John.  I even went to the GETREADU( .. )
function in BASIC.. nothing there.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

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

Re: [U2] Lock Status

[Kevin King]

We do suspect it is from a custom BASIC subroutine, recently installed.  So
knowing the file we're looking back through any code that was compiled
within the past 2 weeks and manually searching for READU's that don't WRITE,
DELETE, or RELEASE.  Sure would be nice if the lock table would report the
line of code that set the lock.  Just sayin'.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Dave Davis]

It would be useful, except that the problem is the locker causing the problem 
probably hasn't updated the record yet, which most likely would release the 
lock (this being an SB+ application) and end the problem.  Retaining the lock 
after an update is something that would likely be coded in unibasic.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Thursday, September 08, 2011 11:28 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

On Thu, Sep 8, 2011 at 11:26 AM, Dave Davis  wrote:
> It's a shame there isn't a file trigger operation on locking reads, just 
> updates and deletes.  That way you could just add it to the file in question.
>

The update trigger might be useful.  Most ppl would lock the record
before updating it.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


 Dave Davis Team Lead, R&D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.


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

Re: [U2] Lock Status

[Daniel McGrath]

Yes, they should be.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Thursday, September 08, 2011 9:27 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

On Thu, Sep 8, 2011 at 11:23 AM, Daniel McGrath  
wrote:
> LIST.READU will tell you what program owns the lock (as long as the program 
> is still running). The UNO column is the UniData Number, which will relate to 
> a user/process in the PORT.STATUS (no options) command's list.
>

Aren't the locks released when the program stops?
___
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] Lock Status

[Kevin King]

Yes, Steve, but being an SB+ application... the "program" never stops
completely until the person logs off.  Meanwhile, they end up "dragging
mines"..
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Steve Romanow]

On Thu, Sep 8, 2011 at 11:26 AM, Dave Davis  wrote:
> It's a shame there isn't a file trigger operation on locking reads, just 
> updates and deletes.  That way you could just add it to the file in question.
>

The update trigger might be useful.  Most ppl would lock the record
before updating it.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Kevin King]

Kudos for the novel ideas Dan!  However, in this case we're trying to track
down a program that left a lock.  And being an SB+ application, a lot of
stuff runs under the same PID.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Steve Romanow]

On Thu, Sep 8, 2011 at 11:23 AM, Daniel McGrath
 wrote:
> LIST.READU will tell you what program owns the lock (as long as the program 
> is still running). The UNO column is the UniData Number, which will relate to 
> a user/process in the PORT.STATUS (no options) command's list.
>

Aren't the locks released when the program stops?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Dave Davis]

It's a shame there isn't a file trigger operation on locking reads, just 
updates and deletes.  That way you could just add it to the file in question.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 11:16 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

Dave: Two Words: Vendor App.  Good idea, but not possible in this case.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


 Dave Davis Team Lead, R&D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.


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

Re: [U2] Lock Status

[Daniel McGrath]

LIST.READU will tell you what program owns the lock (as long as the program is 
still running). The UNO column is the UniData Number, which will relate to a 
user/process in the PORT.STATUS (no options) command's list.

Aside from that, I don't know if you can catch the actual line number unless 
you catch the program in the act when it does it with PORT.STATUS CALL.STACK.

You know roughly what file/record it will effect, you could try locking the 
record yourself (with say, ED) and waiting until the rogue program hits it. 
Using PORT.STATUS CALL.STACK then should tell you the line number issuing the 
lock.

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 9:15 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

That's useful for determining where that port is, but we have a process leaving 
rogue locks lying around.  Anything that tells what updated the lock table?

On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
wrote:

> Once you know the pid of the program with the lock, you can use 
> PORT.STATUS to determine this. You just need to use the CALL.STACK 
> option. IIRC (It's been a few months) it would be like:
>
> PORT.STATUS PID  CALL.STACK
>
> Regards,
> Dan
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:
> u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
> Sent: Thursday, September 08, 2011 9:06 AM
> To: U2 Users List
> Subject: [U2] Lock Status
>
> Is there anything in Unidata that would report the line of code that 
> set a particular record lock?
>
> -Kevin
> http://www.PrecisOnline.com
> ___
> 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
>



--
-Kevin
http://www.PrecisOnline.com
___
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] Free Software for DataBasic

[DavidJMurray (mvdbs.com)]

Over the last weekend, I noticed that the pickwiki.com (the common mv code
website) does not have any games programmes.

I can remember playing the star-trek and adventure games on a Ultimate (or
Altos I think), many years ago.

Does anyone have any remnant or complete code that they can (legally) and
would be willing to contribute to pickwiki.com?



-

Learn and Do
Excel and Share


http://mvdbs.com http://mvdbs.com 
-- 
View this message in context: 
http://old.nabble.com/Free-Software-for-DataBasic-tp32424680p32424680.html
Sent from the U2 - Users mailing list archive at Nabble.com.

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

Re: [U2] Lock Status

[Kevin King]

Unfortunately, no love there either John.  I even went to the GETREADU( .. )
function in BASIC.. nothing there.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[John Thompson]

This is probably no help...

In Universe there is a LIST.READU EVERY.

That will show every lock in the system.  Maybe if Unidata has an
equivalent, you can get some useful info there...



On Thu, Sep 8, 2011 at 11:15 AM, Kevin King  wrote:

> That's useful for determining where that port is, but we have a process
> leaving rogue locks lying around.  Anything that tells what updated the
> lock
> table?
>
> On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
> wrote:
>
> > Once you know the pid of the program with the lock, you can use
> PORT.STATUS
> > to determine this. You just need to use the CALL.STACK option. IIRC (It's
> > been a few months) it would be like:
> >
> > PORT.STATUS PID  CALL.STACK
> >
> > Regards,
> > Dan
> >
> > -Original Message-
> > From: u2-users-boun...@listserver.u2ug.org [mailto:
> > u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
> > Sent: Thursday, September 08, 2011 9:06 AM
> > To: U2 Users List
> > Subject: [U2] Lock Status
> >
> > Is there anything in Unidata that would report the line of code that set
> a
> > particular record lock?
> >
> > -Kevin
> > http://www.PrecisOnline.com
> > ___
> > 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
> >
>
>
>
> --
> -Kevin
> http://www.PrecisOnline.com
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>



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

Re: [U2] Lock Status

[Kevin King]

Dave: Two Words: Vendor App.  Good idea, but not possible in this case.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

[Kevin King]

That's useful for determining where that port is, but we have a process
leaving rogue locks lying around.  Anything that tells what updated the lock
table?

On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
wrote:

> Once you know the pid of the program with the lock, you can use PORT.STATUS
> to determine this. You just need to use the CALL.STACK option. IIRC (It's
> been a few months) it would be like:
>
> PORT.STATUS PID  CALL.STACK
>
> Regards,
> Dan
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:
> u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
> Sent: Thursday, September 08, 2011 9:06 AM
> To: U2 Users List
> Subject: [U2] Lock Status
>
> Is there anything in Unidata that would report the line of code that set a
> particular record lock?
>
> -Kevin
> http://www.PrecisOnline.com
> ___
> 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
>



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

Re: [U2] Lock Status

[Dave Davis]

I don't see anything in the LIST.QUEUE output, but I can see how that would be 
useful.

If you have control of the source code for all of the file i/o operations you 
could write your own wrapper routines for the commands that set record locks, 
get the information from SYSTEM(49) (the program stack), and write it to a file 
somewhere, keyed by file name and record key.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 11:06 AM
To: U2 Users List
Subject: [U2] Lock Status

Is there anything in Unidata that would report the line of code that set a
particular record lock?

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


 Dave Davis Team Lead, R&D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.


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

Re: [U2] Lock Status

[Daniel McGrath]

Once you know the pid of the program with the lock, you can use PORT.STATUS to 
determine this. You just need to use the CALL.STACK option. IIRC (It's been a 
few months) it would be like:

PORT.STATUS PID  CALL.STACK

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 9:06 AM
To: U2 Users List
Subject: [U2] Lock Status

Is there anything in Unidata that would report the line of code that set a 
particular record lock?

-Kevin
http://www.PrecisOnline.com
___
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] Lock Status

[Kevin King]

Is there anything in Unidata that would report the line of code that set a
particular record lock?

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