RE: [U2] Unidebugger

2005-02-01 Thread David Robertshaw
The UniDebugger doesn't use locking when it reads/writes host Basic programs as 
this would not fit the home-grown check-in/out systems many people use.

In the wIntegrate Editor we added the ability to call a custom subroutine at 
the usual points which give 100% control, in the same way as the service 
subroutine which is optionally called by the Query Builder to filter what the 
users sees and does.

However today the UniDebugger does not support custom host subroutines.

-Original Message-
From: Gordon J Glorfield [mailto:[EMAIL PROTECTED] 
Sent: 31 January 2005 21:13
To: u2-users@listserver.u2ug.org
Subject: [U2] Unidebugger

Speaking of the Unidebugger and Sarbaines/Oxley, we are having some issues here 
with them.  Currently our green-screen editors are front-ended by a subroutine 
that checks a database to make sure you have the program checked out.  If you 
don't have it checked out the editors die with an error message alluding to a 
security violation.

Unidebugger does not honor the checked out status of programs in our library. 
 Is there a way to add this check to Unidebugger?


Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.3 - Release Date: 31/01/2005
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Unidebugger

2005-02-01 Thread Gordon J Glorfield
Now I'm confused.  You are now the second person to claim that the 
UniDebugger doesn't use locking when it reads/writes host Basic 
programs.  This is definitely not the case here.  We use the UniObjects 
connect method and it does use and honor record locks.

I was hoping that someone could suggest a method utilizing triggers or 
something to get it to honor our check-in/check-out database.  I'm not 
really interested in investigating alternatives to UniDebugger.  I just 
want to explore making it work.  Perhaps I need to look at the read/write 
permissions, as hinted at earlier, as a possible solution.

Cheers,
Gordon


Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839

[EMAIL PROTECTED] wrote on 02/01/2005 07:40:55 AM:

 The UniDebugger doesn't use locking when it reads/writes host Basic 
 programs as this would not fit the home-grown check-in/out systems 
 many people use.
 
 In the wIntegrate Editor we added the ability to call a custom 
 subroutine at the usual points which give 100% control, in the same 
 way as the service subroutine which is optionally called by the 
 Query Builder to filter what the users sees and does.
 
 However today the UniDebugger does not support custom host subroutines.
 
 -Original Message-
 From: Gordon J Glorfield [mailto:[EMAIL PROTECTED] 
 Sent: 31 January 2005 21:13
 To: u2-users@listserver.u2ug.org
 Subject: [U2] Unidebugger
 
 Speaking of the Unidebugger and Sarbaines/Oxley, we are having some 
 issues here with them.  Currently our green-screen editors are 
 front-ended by a subroutine that checks a database to make sure you 
 have the program checked out.  If you don't have it checked out 
 the editors die with an error message alluding to a security violation.
 
 Unidebugger does not honor the checked out status of programs in 
 our library.  Is there a way to add this check to Unidebugger?
 
 
 Gordon J. Glorfield
 Sr. Applications Developer
 MAMSI (A UnitedHealth Company)
 301-360-8839
 
 -- 
 No virus found in this outgoing message.
 Checked by AVG Anti-Virus.
 Version: 7.0.300 / Virus Database: 265.8.3 - Release Date: 31/01/2005
 ---
 u2-users mailing list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/



This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to 
which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the 
sender by replying to this message and delete this e-mail immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Unidebugger

2005-02-01 Thread Adrian Matthews
There are other ways of accessing with Unidebugger apart from
UniObjects.

FTP, shares etc. These methods do not respect Universe record locks.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gordon J
Glorfield
Sent: 01 February 2005 14:00
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Unidebugger

Now I'm confused.  You are now the second person to claim that the 
UniDebugger doesn't use locking when it reads/writes host Basic 
programs.  This is definitely not the case here.  We use the UniObjects

connect method and it does use and honor record locks.

I was hoping that someone could suggest a method utilizing triggers or 
something to get it to honor our check-in/check-out database.  I'm not 
really interested in investigating alternatives to UniDebugger.  I just 
want to explore making it work.  Perhaps I need to look at the
read/write 
permissions, as hinted at earlier, as a possible solution.

Cheers,
Gordon


Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839

[EMAIL PROTECTED] wrote on 02/01/2005 07:40:55 AM:

 The UniDebugger doesn't use locking when it reads/writes host Basic 
 programs as this would not fit the home-grown check-in/out systems 
 many people use.
 
 In the wIntegrate Editor we added the ability to call a custom 
 subroutine at the usual points which give 100% control, in the same 
 way as the service subroutine which is optionally called by the 
 Query Builder to filter what the users sees and does.
 
 However today the UniDebugger does not support custom host
subroutines.
 
 -Original Message-
 From: Gordon J Glorfield [mailto:[EMAIL PROTECTED] 
 Sent: 31 January 2005 21:13
 To: u2-users@listserver.u2ug.org
 Subject: [U2] Unidebugger
 
 Speaking of the Unidebugger and Sarbaines/Oxley, we are having some 
 issues here with them.  Currently our green-screen editors are 
 front-ended by a subroutine that checks a database to make sure you 
 have the program checked out.  If you don't have it checked out 
 the editors die with an error message alluding to a security
violation.
 
 Unidebugger does not honor the checked out status of programs in 
 our library.  Is there a way to add this check to Unidebugger?
 
 
 Gordon J. Glorfield
 Sr. Applications Developer
 MAMSI (A UnitedHealth Company)
 301-360-8839
 
 -- 
 No virus found in this outgoing message.
 Checked by AVG Anti-Virus.
 Version: 7.0.300 / Virus Database: 265.8.3 - Release Date: 31/01/2005
 ---
 u2-users mailing list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/



This e-mail, including attachments, may include confidential and/or 
proprietary information, and may be used only by the person or entity to

which it is addressed. If the reader of this e-mail is not the intended 
recipient or his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the

sender by replying to this message and delete this e-mail immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone +44 (0)20 7896 0011 and then delete the email and any 
copies of it. Opinions, conclusions (etc.) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it.  IG Markets Limited and IG Index Plc are authorised and regulated by the 
Financial Services Authority and, in Australia, by the Australian Securities 
and Investments Commission.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


[U2] [UV] Transaction Compile Failure

2005-02-01 Thread Perry Taylor
I have an archiving program that I am porting from another platform
which I cannot get to compile on UniVerse.  I have included a
stripped-down test version incorporating the basics below.  The compiler
seems to have issue with

   IF @TRANSACTION THEN
  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID
   END

... as indicated by the compiler message...

   Compiling: Source = 'PBP/PTEST', Object = 'PBP.O/PTEST'
   *
   13ROLLBACK
^
   Cannot COMMIT or ROLLBACK - no transaction.

   14END TRANSACTION
 ^
   TRANSACTION unexpected, Was expecting: ';', End of Line
   19  UNTIL LEN(ERRMSG) DO
  ^
   WARNING: Text found after final END statement


   2 Errors detected, No Object Code Produced.

A guess is that the compiler is eating up the END from END TRANSACTION
to satisfy IF @TRANSACTION THEN but not sure about that.

Anyone have any ideas on what's going on here?

Thanks.

Perry Taylor


--
ERRMSG = ''
REC.ID = ''

OPEN 'HDR' TO F.HDR ELSE STOP 201,'HDR'
OPEN 'HDR.ARCHIVE' TO F.HDR.ARCHIVE ELSE STOP 201,'HDR.ARCHIVE'
OPEN 'DET' TO F.DET ELSE STOP 201,'DET'
OPEN 'DET.ARCHIVE' TO F.DET.ARCHIVE ELSE STOP 201,'DET.ARCHIVE'

SELECT F.HDR

LOOP

   IF @TRANSACTION THEN

  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID

   END

UNTIL LEN(ERRMSG) DO

   READNEXT REC.ID ELSE EXIT

   NULL; * SEE IF THE RECORD IS OLD ENOUGH TO ARCHIVE

   READV HDR.DATE FROM F.HDR, REC.ID, 1 ELSE

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   IF HDR.DATE  DATE() - 90 ELSE RETURN

   NULL; * OK WE HAVE A KEEPER, LET'S READ THE ENTIRE HDR RECORD,
   NULL; * TAKING A LOCK FOR CONTROL, AND ARCHIVE IT ALONG WITH THE
   NULL; * DETAIL RECORD.

   BEGIN TRANSACTION

   READU HDR FROM F.HDR, REC.ID LOCKED

  CRT REC.ID: ' locked, record skipped.'

  RETURN

   END ELSE

  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   READ DET FROM F.DET, REC.ID ELSE
  
  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.
 
  CRT REC.ID: ' not found in DET file.'

  RETURN

   END
 
   WRITE DET ON F.DET.ARCHIVE, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
   
  ERRMSG = 'Cannot write ': REC.ID: ' to DET.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END
 
   DELETE F.DET.ARCHIVE, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 
  ERRMSG = 'Cannot delete ': REC.ID: ' from DET file, STATUS=':
STATUS()

  RETURN

   END
 
   WRITE HDR ON F.HDR.ARCHIVE, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 
  ERRMSG = 'Cannot write ': REC.ID: ' to HDR.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END
 
   DELETE F.HDR, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 
  ERRMSG = 'Cannot delete ': REC.ID: ' from HDR file, STATUS=':
STATUS()

  RETURN

   END
 
   COMMIT
 
   END TRANSACTION
 
REPEAT

IF LEN(ERRMSG) THEN CRT ERRMSG

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] [UD] Max of 2 nested PERFORM CAPTUREs

2005-02-01 Thread Simon Lewington
UD 6.0.12 Win 2k ECLTYPE 'P'

UniBasic PCPERFORM COMM CAPTURING OUTPUT

gives an error 'Max of 2 nested PERFORM CAPTUREs'.

Does anyone know if this limit is configurable?  It doesn't appear in the
LIMIT list.  I'm running a command-stacker application with a web front-end
and this could do with a nesting of 3 CAPTURINGs.

Cheers
Simon
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] [UV] Transaction Compile Failure

2005-02-01 Thread Jerry Banker
END TRANSACTION is at the wrong level in the clip you sent us. Here is an 
example from the manual.
BEGIN TRANSACTION

   READU data1 FROM file1,rec1 ELSE ROLLBACK

   READU data2 FROM file2,rec2, ELSE ROLLBACK

   WRITE new.data1 ON file1,rec1 ELSE ROLLBACK

   WRITE new.data2 ON file2,rec2 ELSE ROLLBACK

   COMMIT WORK

END TRANSACTION


- Original Message - 
From: Perry Taylor [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Tuesday, February 01, 2005 9:39 AM
Subject: [U2] [UV] Transaction Compile Failure


I have an archiving program that I am porting from another platform
which I cannot get to compile on UniVerse.  I have included a
stripped-down test version incorporating the basics below.  The compiler
seems to have issue with

   IF @TRANSACTION THEN
  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID
   END

... as indicated by the compiler message...

   Compiling: Source = 'PBP/PTEST', Object = 'PBP.O/PTEST'
   *
   13ROLLBACK
^
   Cannot COMMIT or ROLLBACK - no transaction.

   14END TRANSACTION
 ^
   TRANSACTION unexpected, Was expecting: ';', End of Line
   19  UNTIL LEN(ERRMSG) DO
  ^
   WARNING: Text found after final END statement


   2 Errors detected, No Object Code Produced.

A guess is that the compiler is eating up the END from END TRANSACTION
to satisfy IF @TRANSACTION THEN but not sure about that.

Anyone have any ideas on what's going on here?

Thanks.

Perry Taylor


--
ERRMSG = ''
REC.ID = ''

OPEN 'HDR' TO F.HDR ELSE STOP 201,'HDR'
OPEN 'HDR.ARCHIVE' TO F.HDR.ARCHIVE ELSE STOP 201,'HDR.ARCHIVE'
OPEN 'DET' TO F.DET ELSE STOP 201,'DET'
OPEN 'DET.ARCHIVE' TO F.DET.ARCHIVE ELSE STOP 201,'DET.ARCHIVE'

SELECT F.HDR

LOOP

   IF @TRANSACTION THEN

  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID

   END

UNTIL LEN(ERRMSG) DO

   READNEXT REC.ID ELSE EXIT

   NULL; * SEE IF THE RECORD IS OLD ENOUGH TO ARCHIVE

   READV HDR.DATE FROM F.HDR, REC.ID, 1 ELSE

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   IF HDR.DATE  DATE() - 90 ELSE RETURN

   NULL; * OK WE HAVE A KEEPER, LET'S READ THE ENTIRE HDR RECORD,
   NULL; * TAKING A LOCK FOR CONTROL, AND ARCHIVE IT ALONG WITH THE
   NULL; * DETAIL RECORD.

   BEGIN TRANSACTION

   READU HDR FROM F.HDR, REC.ID LOCKED

  CRT REC.ID: ' locked, record skipped.'

  RETURN

   END ELSE

  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   READ DET FROM F.DET, REC.ID ELSE

  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.

  CRT REC.ID: ' not found in DET file.'

  RETURN

   END

   WRITE DET ON F.DET.ARCHIVE, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot write ': REC.ID: ' to DET.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END

   DELETE F.DET.ARCHIVE, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot delete ': REC.ID: ' from DET file, STATUS=':
STATUS()

  RETURN

   END

   WRITE HDR ON F.HDR.ARCHIVE, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot write ': REC.ID: ' to HDR.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END

   DELETE F.HDR, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot delete ': REC.ID: ' from HDR file, STATUS=':
STATUS()

  RETURN

   END

   COMMIT

   END TRANSACTION

REPEAT

IF LEN(ERRMSG) THEN CRT ERRMSG

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] Transaction Compile Failure

2005-02-01 Thread Perry Taylor
Correction to the code listing... All RETURNS should be CONTINUEs.

Appologies,

Perry 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Perry Taylor
Sent: Tuesday, February 01, 2005 8:40 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] [UV] Transaction Compile Failure

I have an archiving program that I am porting from another platform
which I cannot get to compile on UniVerse.  I have included a
stripped-down test version incorporating the basics below.  The compiler
seems to have issue with

   IF @TRANSACTION THEN
  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID
   END

... as indicated by the compiler message...

   Compiling: Source = 'PBP/PTEST', Object = 'PBP.O/PTEST'
   *
   13ROLLBACK
^
   Cannot COMMIT or ROLLBACK - no transaction.

   14END TRANSACTION
 ^
   TRANSACTION unexpected, Was expecting: ';', End of Line
   19  UNTIL LEN(ERRMSG) DO
  ^
   WARNING: Text found after final END statement


   2 Errors detected, No Object Code Produced.

A guess is that the compiler is eating up the END from END TRANSACTION
to satisfy IF @TRANSACTION THEN but not sure about that.

Anyone have any ideas on what's going on here?

Thanks.

Perry Taylor


--
ERRMSG = ''
REC.ID = ''

OPEN 'HDR' TO F.HDR ELSE STOP 201,'HDR'
OPEN 'HDR.ARCHIVE' TO F.HDR.ARCHIVE ELSE STOP 201,'HDR.ARCHIVE'
OPEN 'DET' TO F.DET ELSE STOP 201,'DET'
OPEN 'DET.ARCHIVE' TO F.DET.ARCHIVE ELSE STOP 201,'DET.ARCHIVE'

SELECT F.HDR

LOOP

   IF @TRANSACTION THEN

  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID

   END

UNTIL LEN(ERRMSG) DO

   READNEXT REC.ID ELSE EXIT

   NULL; * SEE IF THE RECORD IS OLD ENOUGH TO ARCHIVE

   READV HDR.DATE FROM F.HDR, REC.ID, 1 ELSE

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   IF HDR.DATE  DATE() - 90 ELSE RETURN

   NULL; * OK WE HAVE A KEEPER, LET'S READ THE ENTIRE HDR RECORD,
   NULL; * TAKING A LOCK FOR CONTROL, AND ARCHIVE IT ALONG WITH THE
   NULL; * DETAIL RECORD.

   BEGIN TRANSACTION

   READU HDR FROM F.HDR, REC.ID LOCKED

  CRT REC.ID: ' locked, record skipped.'

  RETURN

   END ELSE

  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   READ DET FROM F.DET, REC.ID ELSE
  
  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.
 
  CRT REC.ID: ' not found in DET file.'

  RETURN

   END
 
   WRITE DET ON F.DET.ARCHIVE, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
   
  ERRMSG = 'Cannot write ': REC.ID: ' to DET.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END
 
   DELETE F.DET.ARCHIVE, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 
  ERRMSG = 'Cannot delete ': REC.ID: ' from DET file, STATUS=':
STATUS()

  RETURN

   END
 
   WRITE HDR ON F.HDR.ARCHIVE, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 
  ERRMSG = 'Cannot write ': REC.ID: ' to HDR.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END
 
   DELETE F.HDR, REC.ID ON ERROR
  
  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 
  ERRMSG = 'Cannot delete ': REC.ID: ' from HDR file, STATUS=':
STATUS()

  RETURN

   END
 
   COMMIT
 
   END TRANSACTION
 
REPEAT

IF LEN(ERRMSG) THEN CRT ERRMSG

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] Transaction Compile Failure

2005-02-01 Thread Perry Taylor
Logically there *is* an END TRANSACTION at two places.  One at the
bottom of the loop..

COMMIT
END TRANSACTION

And the other at the top of the loop...

IF @TRANSACTION THEN
ROLLBACK
END TRANSACTION
END

This being the case it would seem to me that the compiler cannot deal
with a transaction not being in purely straight-line code.  The only
alternative I see at this point is to put an explicit ROLLBACK / END
TRANSACTION at every point along the loop where I would need to bail out
of the transaction.  Seems to reduce the usefulness of @TRANSACTION and
structured programming.  

Any other suggestion?

Perry

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker
Sent: Tuesday, February 01, 2005 10:04 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Transaction Compile Failure

END TRANSACTION is at the wrong level in the clip you sent us. Here is
an example from the manual.
BEGIN TRANSACTION

   READU data1 FROM file1,rec1 ELSE ROLLBACK

   READU data2 FROM file2,rec2, ELSE ROLLBACK

   WRITE new.data1 ON file1,rec1 ELSE ROLLBACK

   WRITE new.data2 ON file2,rec2 ELSE ROLLBACK

   COMMIT WORK

END TRANSACTION


- Original Message -
From: Perry Taylor [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Tuesday, February 01, 2005 9:39 AM
Subject: [U2] [UV] Transaction Compile Failure


I have an archiving program that I am porting from another platform
which I cannot get to compile on UniVerse.  I have included a
stripped-down test version incorporating the basics below.  The compiler
seems to have issue with

   IF @TRANSACTION THEN
  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID
   END

... as indicated by the compiler message...

   Compiling: Source = 'PBP/PTEST', Object = 'PBP.O/PTEST'
   *
   13ROLLBACK
^
   Cannot COMMIT or ROLLBACK - no transaction.

   14END TRANSACTION
 ^
   TRANSACTION unexpected, Was expecting: ';', End of Line
   19  UNTIL LEN(ERRMSG) DO
  ^
   WARNING: Text found after final END statement


   2 Errors detected, No Object Code Produced.

A guess is that the compiler is eating up the END from END TRANSACTION
to satisfy IF @TRANSACTION THEN but not sure about that.

Anyone have any ideas on what's going on here?

Thanks.

Perry Taylor


--
ERRMSG = ''
REC.ID = ''

OPEN 'HDR' TO F.HDR ELSE STOP 201,'HDR'
OPEN 'HDR.ARCHIVE' TO F.HDR.ARCHIVE ELSE STOP 201,'HDR.ARCHIVE'
OPEN 'DET' TO F.DET ELSE STOP 201,'DET'
OPEN 'DET.ARCHIVE' TO F.DET.ARCHIVE ELSE STOP 201,'DET.ARCHIVE'

SELECT F.HDR

LOOP

   IF @TRANSACTION THEN

  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID

   END

UNTIL LEN(ERRMSG) DO

   READNEXT REC.ID ELSE EXIT

   NULL; * SEE IF THE RECORD IS OLD ENOUGH TO ARCHIVE

   READV HDR.DATE FROM F.HDR, REC.ID, 1 ELSE

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   IF HDR.DATE  DATE() - 90 ELSE RETURN

   NULL; * OK WE HAVE A KEEPER, LET'S READ THE ENTIRE HDR RECORD,
   NULL; * TAKING A LOCK FOR CONTROL, AND ARCHIVE IT ALONG WITH THE
   NULL; * DETAIL RECORD.

   BEGIN TRANSACTION

   READU HDR FROM F.HDR, REC.ID LOCKED

  CRT REC.ID: ' locked, record skipped.'

  RETURN

   END ELSE

  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   READ DET FROM F.DET, REC.ID ELSE

  NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.

  CRT REC.ID: ' not found in DET file.'

  RETURN

   END

   WRITE DET ON F.DET.ARCHIVE, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot write ': REC.ID: ' to DET.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END

   DELETE F.DET.ARCHIVE, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot delete ': REC.ID: ' from DET file, STATUS=':
STATUS()

  RETURN

   END

   WRITE HDR ON F.HDR.ARCHIVE, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot write ': REC.ID: ' to HDR.ARCHIVE file, STATUS=':
STATUS()

  RETURN

   END

   DELETE F.HDR, REC.ID ON ERROR

  NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS

  ERRMSG = 'Cannot delete ': REC.ID: ' from HDR file, STATUS=':
STATUS()

  RETURN

   END

   COMMIT

   END TRANSACTION

REPEAT

IF LEN(ERRMSG) THEN CRT ERRMSG

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, 

Re: [U2] [UV] Transaction Compile Failure

2005-02-01 Thread Geoffrey Mitchell
The help for END TRANSACTION says:
Use the END TRANSACTION statement to specify where  processing is to 
continue after a transaction ends.

This implies to me that there must be exactly one end transaction for 
each begin transaction.  It also implies that if you do a rollback, 
execution will resume at your END TRANSACTION statement.  It seems to me 
that this is a pretty lousy syntax, as it seems to support only one 
active transaction (otherwise, how do you know which one you are acting 
on?), and, in fact, more than one trasaction in the same 
program/subroutine could make things pretty confusing. 

Keep in mind that I haven't tested or tried to use any of this, but I 
would think you could replace your CONTINUE's with ROLLBACK's, and get 
rid of your IF @TRANSACTION block, and it should work.

Perry Taylor wrote:
Logically there *is* an END TRANSACTION at two places.  One at the
bottom of the loop..
COMMIT
END TRANSACTION
And the other at the top of the loop...
IF @TRANSACTION THEN
ROLLBACK
END TRANSACTION
END
This being the case it would seem to me that the compiler cannot deal
with a transaction not being in purely straight-line code.  The only
alternative I see at this point is to put an explicit ROLLBACK / END
TRANSACTION at every point along the loop where I would need to bail out
of the transaction.  Seems to reduce the usefulness of @TRANSACTION and
structured programming.  

Any other suggestion?
Perry
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker
Sent: Tuesday, February 01, 2005 10:04 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Transaction Compile Failure
END TRANSACTION is at the wrong level in the clip you sent us. Here is
an example from the manual.
BEGIN TRANSACTION
  READU data1 FROM file1,rec1 ELSE ROLLBACK
  READU data2 FROM file2,rec2, ELSE ROLLBACK
  WRITE new.data1 ON file1,rec1 ELSE ROLLBACK
  WRITE new.data2 ON file2,rec2 ELSE ROLLBACK
  COMMIT WORK
END TRANSACTION
- Original Message -
From: Perry Taylor [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Tuesday, February 01, 2005 9:39 AM
Subject: [U2] [UV] Transaction Compile Failure
I have an archiving program that I am porting from another platform
which I cannot get to compile on UniVerse.  I have included a
stripped-down test version incorporating the basics below.  The compiler
seems to have issue with
  IF @TRANSACTION THEN
 ROLLBACK
 END TRANSACTION
 RELEASE F.HDR, REC.ID
  END
... as indicated by the compiler message...
  Compiling: Source = 'PBP/PTEST', Object = 'PBP.O/PTEST'
  *
  13ROLLBACK
   ^
  Cannot COMMIT or ROLLBACK - no transaction.
  14END TRANSACTION
^
  TRANSACTION unexpected, Was expecting: ';', End of Line
  19  UNTIL LEN(ERRMSG) DO
 ^
  WARNING: Text found after final END statement
  2 Errors detected, No Object Code Produced.
A guess is that the compiler is eating up the END from END TRANSACTION
to satisfy IF @TRANSACTION THEN but not sure about that.
Anyone have any ideas on what's going on here?
Thanks.
Perry Taylor

--
ERRMSG = ''
REC.ID = ''
OPEN 'HDR' TO F.HDR ELSE STOP 201,'HDR'
OPEN 'HDR.ARCHIVE' TO F.HDR.ARCHIVE ELSE STOP 201,'HDR.ARCHIVE'
OPEN 'DET' TO F.DET ELSE STOP 201,'DET'
OPEN 'DET.ARCHIVE' TO F.DET.ARCHIVE ELSE STOP 201,'DET.ARCHIVE'
SELECT F.HDR
LOOP
  IF @TRANSACTION THEN
 ROLLBACK
 END TRANSACTION
 RELEASE F.HDR, REC.ID
  END
UNTIL LEN(ERRMSG) DO
  READNEXT REC.ID ELSE EXIT
  NULL; * SEE IF THE RECORD IS OLD ENOUGH TO ARCHIVE
  READV HDR.DATE FROM F.HDR, REC.ID, 1 ELSE
 CRT REC.ID: ' not found in HDR file.'
 RETURN
  END
  IF HDR.DATE  DATE() - 90 ELSE RETURN
  NULL; * OK WE HAVE A KEEPER, LET'S READ THE ENTIRE HDR RECORD,
  NULL; * TAKING A LOCK FOR CONTROL, AND ARCHIVE IT ALONG WITH THE
  NULL; * DETAIL RECORD.
  BEGIN TRANSACTION
  READU HDR FROM F.HDR, REC.ID LOCKED
 CRT REC.ID: ' locked, record skipped.'
 RETURN
  END ELSE
 NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.
 CRT REC.ID: ' not found in HDR file.'
 RETURN
  END
  READ DET FROM F.DET, REC.ID ELSE
 NULL; * UNLIKELY BUT WE'LL JUST GO ON TO THE NEXT ONE.
 CRT REC.ID: ' not found in DET file.'
 RETURN
  END
  WRITE DET ON F.DET.ARCHIVE, REC.ID ON ERROR
 NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 ERRMSG = 'Cannot write ': REC.ID: ' to DET.ARCHIVE file, STATUS=':
STATUS()
 RETURN
  END
  DELETE F.DET.ARCHIVE, REC.ID ON ERROR
 NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 ERRMSG = 'Cannot delete ': REC.ID: ' from DET file, STATUS=':
STATUS()
 RETURN
  END
  WRITE HDR ON F.HDR.ARCHIVE, REC.ID ON ERROR
 NULL; * THIS IS SERIOUS ENOUGH TO TERMINATE THE PROCESS
 ERRMSG = 'Cannot write ': REC.ID: ' to 

RE: [U2] [UV] Transaction Compile Failure

2005-02-01 Thread Richard Taylor
A transaction may only have a single BEGIN and END statement.  You are
basically creating a logic block that contains the code that makes up the
'transaction'.  In your case you have two choices

First, you could move the begin transaction above the LOOP and the End
transaction after the REPEAT.  This would put all work done within the
loop into a single transaction.  This has some obvious disadvantages if
you are looping through many records and hold locks.

The Second is the way you coded it except you should not have the end
transaction prior to the UNTIL.  This is an error because no BEGIN
TRANSACTION occurs before it.  This is like having an REPEAT statement
with no LOOP.  Keep in mind that you MUST use a ROLLBACK or COMMIT if you
try to use an EXIT or CONTINUE statement within the loop.  This will 'end'
the transaction and allow a new Transaction to be started.  If memory
serves if the code encounters the END TRANSACTION without having had a
COMMIT or ROLLBACK done it would do an implicit commit, but I am not sure
of that.  I have always preferred to explicitly do a COMMIT at the end as
you have done.


Hope that helps.

Rich Taylor | Senior Programmer/Analyst| VERTIS
250 W. Pratt Street | Baltimore, MD 21201
P 410.361.8688 | F 410.528.0319 
[EMAIL PROTECTED] | http://www.vertisinc.com

Vertis is the premier provider of targeted advertising, media, and
marketing services that drive consumers to marketers more effectively.

The more they complicate the plumbing
  the easier it is to stop up the drain

- Montgomery Scott NCC-1701


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Perry Taylor
Sent: Tuesday, February 01, 2005 1:54 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] Transaction Compile Failure

Logically there *is* an END TRANSACTION at two places.  One at the
bottom of the loop..

COMMIT
END TRANSACTION

And the other at the top of the loop...

IF @TRANSACTION THEN
ROLLBACK
END TRANSACTION
END

This being the case it would seem to me that the compiler cannot deal
with a transaction not being in purely straight-line code.  The only
alternative I see at this point is to put an explicit ROLLBACK / END
TRANSACTION at every point along the loop where I would need to bail out
of the transaction.  Seems to reduce the usefulness of @TRANSACTION and
structured programming.  

Any other suggestion?

Perry

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker
Sent: Tuesday, February 01, 2005 10:04 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] Transaction Compile Failure

END TRANSACTION is at the wrong level in the clip you sent us. Here is
an example from the manual.
BEGIN TRANSACTION

   READU data1 FROM file1,rec1 ELSE ROLLBACK

   READU data2 FROM file2,rec2, ELSE ROLLBACK

   WRITE new.data1 ON file1,rec1 ELSE ROLLBACK

   WRITE new.data2 ON file2,rec2 ELSE ROLLBACK

   COMMIT WORK

END TRANSACTION


- Original Message -
From: Perry Taylor [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Tuesday, February 01, 2005 9:39 AM
Subject: [U2] [UV] Transaction Compile Failure


I have an archiving program that I am porting from another platform
which I cannot get to compile on UniVerse.  I have included a
stripped-down test version incorporating the basics below.  The compiler
seems to have issue with

   IF @TRANSACTION THEN
  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID
   END

... as indicated by the compiler message...

   Compiling: Source = 'PBP/PTEST', Object = 'PBP.O/PTEST'
   *
   13ROLLBACK
^
   Cannot COMMIT or ROLLBACK - no transaction.

   14END TRANSACTION
 ^
   TRANSACTION unexpected, Was expecting: ';', End of Line
   19  UNTIL LEN(ERRMSG) DO
  ^
   WARNING: Text found after final END statement


   2 Errors detected, No Object Code Produced.

A guess is that the compiler is eating up the END from END TRANSACTION
to satisfy IF @TRANSACTION THEN but not sure about that.

Anyone have any ideas on what's going on here?

Thanks.

Perry Taylor


--
ERRMSG = ''
REC.ID = ''

OPEN 'HDR' TO F.HDR ELSE STOP 201,'HDR'
OPEN 'HDR.ARCHIVE' TO F.HDR.ARCHIVE ELSE STOP 201,'HDR.ARCHIVE'
OPEN 'DET' TO F.DET ELSE STOP 201,'DET'
OPEN 'DET.ARCHIVE' TO F.DET.ARCHIVE ELSE STOP 201,'DET.ARCHIVE'

SELECT F.HDR

LOOP

   IF @TRANSACTION THEN

  ROLLBACK
  END TRANSACTION
  RELEASE F.HDR, REC.ID

   END

UNTIL LEN(ERRMSG) DO

   READNEXT REC.ID ELSE EXIT

   NULL; * SEE IF THE RECORD IS OLD ENOUGH TO ARCHIVE

   READV HDR.DATE FROM F.HDR, REC.ID, 1 ELSE

  CRT REC.ID: ' not found in HDR file.'

  RETURN

   END

   IF HDR.DATE  DATE() - 90 ELSE RETURN

   NULL; * OK WE HAVE A KEEPER, LET'S READ THE ENTIRE HDR RECORD,
   NULL; * TAKING A 

RE: [U2] [UV] Transaction Compile Failure

2005-02-01 Thread Pingilley, Ron
Perry,

You probably won't be able to have multiple END TRANSACTION statements. 
 One BEGIN TRANSACTION where you have it, and one END TRANSACTION at the bottom 
of the LOOP structure, should suffice.

Then just put a ROLLBACK and CONTINUE within each IF-, READ-, and 
WRITE-THEN-ELSE error trap.

It looks like the compiler treats the BEGIN TRANSACTION--END 
TRANSACTION like it does BEGIN CASE--END CASE as far as imposing a top-down 
coding structure.  It's not like a PRINTER ON/OFF toggle that you can set at 
will, as if it were TRANSACTION ON/OFF.  But you are right that it does force 
you to code the TRANSACTION in a specific top-down style.  Makes it tricky to 
add transaction processing to old code :)

--Ron P.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Perry Taylor
Sent: Tuesday, February 01, 2005 12:54 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] Transaction Compile Failure


Logically there *is* an END TRANSACTION at two places.  One at the
bottom of the loop..

COMMIT
END TRANSACTION

And the other at the top of the loop...

IF @TRANSACTION THEN
ROLLBACK
END TRANSACTION
END

This being the case it would seem to me that the compiler cannot deal
with a transaction not being in purely straight-line code.  The only
alternative I see at this point is to put an explicit ROLLBACK / END
TRANSACTION at every point along the loop where I would need to bail out
of the transaction.  Seems to reduce the usefulness of @TRANSACTION and
structured programming.  

Any other suggestion?

Perry
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


[U2] [AD] UniBasic Program with arguments

2005-02-01 Thread Chauhan, Savita
Hi,

I am trying to run a unibasic program (external subroutine) that takes
two arguments.
I don't know how do I pass it the arguments if I run it directly from
shel prompt instead of calling it from another program.
I have gone through the manual, but can't find anything. Pls help.

Thanks
Savita.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [AD] UniBasic Program with arguments

2005-02-01 Thread Kevin King
You'll have to write a wrapper that translates the two command line
parameters into subroutine arguments. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chauhan,
Savita
Sent: Tuesday, February 01, 2005 3:48 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] [AD] UniBasic Program with arguments

Hi,

I am trying to run a unibasic program (external subroutine) that takes
two arguments.
I don't know how do I pass it the arguments if I run it directly from
shel prompt instead of calling it from another program.
I have gone through the manual, but can't find anything. Pls help.

Thanks
Savita.
---
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] [AD] UniBasic Program with arguments

2005-02-01 Thread Bob Woodward
You can not run it directly from the command prompt.  There were a
number of options that were given in this list not that long ago that
would let you test external subroutines but they all require some kind
of priming process. 

BobW


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-u2-
 [EMAIL PROTECTED] On Behalf Of Chauhan, Savita
 Sent: Tuesday, February 01, 2005 2:48 PM
 To: u2-users@listserver.u2ug.org
 Subject: [U2] [AD] UniBasic Program with arguments
 
 Hi,
 
 I am trying to run a unibasic program (external subroutine) that takes
 two arguments.
 I don't know how do I pass it the arguments if I run it directly from
 shel prompt instead of calling it from another program.
 I have gone through the manual, but can't find anything. Pls help.
 
 Thanks
 Savita.
 ---
 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] [AD] UniBasic Program with arguments

2005-02-01 Thread Cliff Bennett
Hi, Savita.  I presume you mean running the program from TCL (:), the U2 
command prompt.

In UniData there are two built-in variables, synonyms actually, named 
@SENTENCE and @COMMAND.  These contain the raw command line used to 
invoke your subroutine.

I usually TRIM this (to eliminate multiple blanks) and then convert 
blanks to a U2 dynamic array delimiter.  I can then count and extract 
these arguments, sort of like argv and argc in C.  A snippet ...

SUBROUTINE TEST.ARGS
CMD.LINE = TRIM(@COMMAND)
CONVERT ' ' TO @AM IN CMD.LINE
NUM.CMD = DCOUNT(CMD.LINE, @AM)
SUB.NAME = CMD.LINE1
ARG1 = CMD.LINE2
ARG2 = CMD.LINE3
I believe UniVerse has @SENTENCE also; not sure about @COMMAND.
Regards, Cliff
Chauhan, Savita wrote:
Hi,
I am trying to run a unibasic program (external subroutine) that takes
two arguments.
I don't know how do I pass it the arguments if I run it directly from
shel prompt instead of calling it from another program.
I have gone through the manual, but can't find anything. Pls help.
Thanks
Savita.
---
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] [AD] UniBasic Program with arguments

2005-02-01 Thread Bob Woodward
In Universe you can not run a program that is created as an external
subroutine.  That is, any program that has the first executable line as:
SUBROUTINE MYPROG(PARAM1, PARAM2)

If you try to run it, directly or indirectly through a catalog entry in
the VOC you get the following message:

Cannot RUN a subroutine that has arguments.

If the program does not have arguments, THEN you could use the @SENTENCE
variable to see what other command line options were typed in.

BobW


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-u2-
 [EMAIL PROTECTED] On Behalf Of Cliff Bennett
 Sent: Tuesday, February 01, 2005 4:05 PM
 To: u2-users@listserver.u2ug.org
 Subject: Re: [U2] [AD] UniBasic Program with arguments
 
 Hi, Savita.  I presume you mean running the program from TCL (:), the
U2
 command prompt.
 
 In UniData there are two built-in variables, synonyms actually, named
 @SENTENCE and @COMMAND.  These contain the raw command line used to
 invoke your subroutine.
 
 I usually TRIM this (to eliminate multiple blanks) and then convert
 blanks to a U2 dynamic array delimiter.  I can then count and extract
 these arguments, sort of like argv and argc in C.  A snippet ...
 
 SUBROUTINE TEST.ARGS
 CMD.LINE = TRIM(@COMMAND)
 CONVERT ' ' TO @AM IN CMD.LINE
 NUM.CMD = DCOUNT(CMD.LINE, @AM)
 SUB.NAME = CMD.LINE1
 ARG1 = CMD.LINE2
 ARG2 = CMD.LINE3
 
 I believe UniVerse has @SENTENCE also; not sure about @COMMAND.
 
 Regards, Cliff
 
 Chauhan, Savita wrote:
 
  Hi,
 
  I am trying to run a unibasic program (external subroutine) that
takes
  two arguments.
  I don't know how do I pass it the arguments if I run it directly
from
  shel prompt instead of calling it from another program.
  I have gone through the manual, but can't find anything. Pls help.
 
  Thanks
  Savita.
  ---
  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] Unidebugger

2005-02-01 Thread Susan Joslyn
We're using the word 'locking' in two different ways, here.

Lock as in 'read lock' is indeed done by the unidebugger.

Locking as in -- calling a host subroutine to validate the available status
in a source library system (such as PRC (hah! You knew I'd plug!) is
something that the Unieditor (with Wintegrate, but not Dynamic Connect) can
do, but the Unidebugger (presently) cannot.

Everyone whine and beg and maybe they can put that in for us.  In the
meantime, Gordon, I would think that you could address it with file
triggers... any reason why you can't?

Susan


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gordon J
Glorfield
Sent: 01 February 2005 14:00
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Unidebugger

Now I'm confused.  You are now the second person to claim that the 
UniDebugger doesn't use locking when it reads/writes host Basic 
programs.  This is definitely not the case here.  We use the UniObjects

connect method and it does use and honor record locks.

I was hoping that someone could suggest a method utilizing triggers or 
something to get it to honor our check-in/check-out database.  I'm not 
really interested in investigating alternatives to UniDebugger.  I just 
want to explore making it work.  Perhaps I need to look at the
read/write 
permissions, as hinted at earlier, as a possible solution.

Cheers,
Gordon


Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839

[EMAIL PROTECTED] wrote on 02/01/2005 07:40:55 AM:

 The UniDebugger doesn't use locking when it reads/writes host Basic 
 programs as this would not fit the home-grown check-in/out systems 
 many people use.
 
 In the wIntegrate Editor we added the ability to call a custom 
 subroutine at the usual points which give 100% control, in the same 
 way as the service subroutine which is optionally called by the 
 Query Builder to filter what the users sees and does.
 
 However today the UniDebugger does not support custom host
subroutines.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Unidebugger

2005-02-01 Thread Stevenson, Charles
From: Susan Joslyn
 [snip] Gordon, I would think that you could address it with file
 triggers... any reason why you can't?

triggers wont work on type 19 files.
Programs have to be type 19 files.
Can PRC work around that one?

cds
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Unidebugger

2005-02-01 Thread Adrian Matthews
We use EditPlus with SourceSafe which works well as no-one can change a
program from within Universe or without unless it's been checked out
first.

We developed an add-in (as have others) to make the links to SourceSafe
an integral part of EditPlus so checking status, checking in/out,
promoting to test/pre-prod/prod is all done via a menu/single keystroke.

Before we started using EditPlus we used the command line facilities of
SourceSafe to link into the Universe shell.

Of course, maintaining version control over dictionaries and property
records is a bit trickier as SourceSafe will only work for type 1/19.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
Sent: 02 February 2005 03:36
To: u2-users@listserver.u2ug.org; [EMAIL PROTECTED]
Subject: RE: [U2] Unidebugger

We're using the word 'locking' in two different ways, here.

Lock as in 'read lock' is indeed done by the unidebugger.

Locking as in -- calling a host subroutine to validate the available
status
in a source library system (such as PRC (hah! You knew I'd plug!) is
something that the Unieditor (with Wintegrate, but not Dynamic Connect)
can
do, but the Unidebugger (presently) cannot.

Everyone whine and beg and maybe they can put that in for us.  In the
meantime, Gordon, I would think that you could address it with file
triggers... any reason why you can't?

Susan


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gordon J
Glorfield
Sent: 01 February 2005 14:00
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Unidebugger

Now I'm confused.  You are now the second person to claim that the 
UniDebugger doesn't use locking when it reads/writes host Basic 
programs.  This is definitely not the case here.  We use the UniObjects

connect method and it does use and honor record locks.

I was hoping that someone could suggest a method utilizing triggers or 
something to get it to honor our check-in/check-out database.  I'm not 
really interested in investigating alternatives to UniDebugger.  I just 
want to explore making it work.  Perhaps I need to look at the
read/write 
permissions, as hinted at earlier, as a possible solution.

Cheers,
Gordon


Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839

[EMAIL PROTECTED] wrote on 02/01/2005 07:40:55 AM:

 The UniDebugger doesn't use locking when it reads/writes host Basic 
 programs as this would not fit the home-grown check-in/out systems 
 many people use.
 
 In the wIntegrate Editor we added the ability to call a custom 
 subroutine at the usual points which give 100% control, in the same 
 way as the service subroutine which is optionally called by the 
 Query Builder to filter what the users sees and does.
 
 However today the UniDebugger does not support custom host
subroutines.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone +44 (0)20 7896 0011 and then delete the email and any 
copies of it. Opinions, conclusions (etc.) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it.  IG Markets Limited and IG Index Plc are authorised and regulated by the 
Financial Services Authority and, in Australia, by the Australian Securities 
and Investments Commission.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/