Re: [U2] [UD] Who's locking a record

[Bill Haskett]

Thanks Colin & David.  That's what I did; what a dance though!

I wonder why anyone would want STATUS() to return a value that doesn't 
give us the means to resolve the problem (as in what terminal, or what 
UO program was locking the record)? PORT.STATUS is of no value in a web 
environment because it's too slow and doesn't return a call stack on a 
UO process.


It's be really nice if we could get any information about a port/process 
simply by querying some object, instead of having to remember some 
esoteric function whose data we need to parse through.  Kind of like UD 
not telling us which darned dbms account a user is logged into!


Thanks again.

Bill
Untitled Page



- Original Message -
*From:* alfke...@hotmail.com
*To:* 'U2 Users List' 
*Date:* 1/28/2014 3:49 PM
*Subject:* Re: [U2] [UD] Who's locking a record

That's what we used to use. It's a little more of a pain as you have to
parse through the output to find the correct record - but it should give you
need. It's simply list.readu output in an array.

Hth
Colin

-Original Message-
From: David A. Green
Sent: Tuesday, January 28, 2014 2:19 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] Who's locking a record

Can you get what you need using GETREADU?

David A. Green
(480) 201-7953
DAG Consulting

-Original Message-
From: Bill Haskett
Sent: Tuesday, January 28, 2014 1:18 PM
To: U2 Mail List
Subject: [U2] [UD] Who's locking a record

In UniData, if you do a READU you can find out the User ID who has the
record locked by using the STATUS() function; this returns the 'UID'
value.  Here's a list of users:

3 Dev (0)-> lu

Licensed(UDT+CP)/Effective  Udt Sql iPhtm Pooled  Total

  (  24 + 1   ) / 25  1   0   0 0   1

UDTNO USRNBR  UID  USRNAME   USRTYPE  TTYIP-ADDRESSTIME DATE
1   2488 197612 AsiAdmin  phantom pts/1   Console   10:42:32 Jan 15 2014
2   3920 197610 JohnSmith udt pts/2   192.168.1.52  08:15:33 Jan 28 2014
3180 197608 udcsuser  udcspts/3   udcs  09:22:57 Jan 28 2014
4   3840 197608 udcsuser  udcspts/4   udcs  09:23:08 Jan 28 2014

Now, if John Smith goes to read and lock a record that is locked by port#3,
how can I figure out which port# actually has the record locked, since the
UniData GETUSER() function only returns the UID, and that user, because it
is a UniObjects user, is connected on more than one port#?

I have a file managed at login that keeps track of the PORT#s and the
associated users assigned by our application.  I want our logging to report
that a record lock by user so-and-so on port {n} is already in place.

Thanks.

Bill


___
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] [UD] Who's locking a record

[Colin Alfke]

That's what we used to use. It's a little more of a pain as you have to
parse through the output to find the correct record - but it should give you
need. It's simply list.readu output in an array.

Hth
Colin

-Original Message-
From: David A. Green
Sent: Tuesday, January 28, 2014 2:19 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] Who's locking a record

Can you get what you need using GETREADU?

David A. Green
(480) 201-7953
DAG Consulting

-Original Message-
From: Bill Haskett
Sent: Tuesday, January 28, 2014 1:18 PM
To: U2 Mail List
Subject: [U2] [UD] Who's locking a record

In UniData, if you do a READU you can find out the User ID who has the
record locked by using the STATUS() function; this returns the 'UID' 
value.  Here's a list of users:

3 Dev (0)-> lu

Licensed(UDT+CP)/Effective  Udt Sql iPhtm Pooled  Total

 (  24 + 1   ) / 25  1   0   0 0   1

UDTNO USRNBR  UID USRNAME   USRTYPE  TTYIP-ADDRESS TIME DATE
1   2488 197612 AsiAdmin  phantom pts/1   Console 10:42:32 Jan 15 2014
   2   3920 197610 JohnSmith udt pts/2   192.168.1.52  08:15:33 Jan 
28 2014
   3180 197608 udcsuser udcspts/3   udcs  09:22:57 Jan 
28 2014
   4   3840 197608 udcsuser  udcspts/4   udcs 09:23:08 Jan 28 2014

Now, if John Smith goes to read and lock a record that is locked by port#3,
how can I figure out which port# actually has the record locked, since the
UniData GETUSER() function only returns the UID, and that user, because it
is a UniObjects user, is connected on more than one port#?

I have a file managed at login that keeps track of the PORT#s and the
associated users assigned by our application.  I want our logging to report
that a record lock by user so-and-so on port {n} is already in place.

Thanks.

Bill


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

Re: [U2] [UD] Who's locking a record

[Bill Haskett]

Oops, I forgot to mention I'm using Windows.

Bill
Untitled Page



- Original Message -
*From:* bl...@shaklee.com
*To:* U2 Users List 
*Date:* 1/28/2014 1:12 PM
*Subject:* Re: [U2] [UD] Who's locking a record

Here's how we do it:



READU MASTER.REC FROM F.CNTRL, 'COM.MASTER' LOCKED
UID = STATUS()
CMD = '!grep :':UID:': /etc/passwd | cut -d -f5'
EXECUTE CMD CAPTURING USER.NAME
MSG = 'DIST record - ':DIST.NBR:' is locked by: ':USER.NAME<1>
CALL SB.DISP(9,MSG)
SLEEP 5
CALL SB.DISP(9.'')
RETURN
END ELSE
RELEASE F.CNTRL, 'COM.MASTER'
STOP
END


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, January 28, 2014 12:18 PM
To: U2 Mail List
Subject: [U2] [UD] Who's locking a record

In UniData, if you do a READU you can find out the User ID who has the
record locked by using the STATUS() function; this returns the 'UID'
value.  Here's a list of users:

3 Dev (0)-> lu

Licensed(UDT+CP)/Effective  Udt Sql iPhtm Pooled  Total

  (  24 + 1   ) / 25  1   0   0 0   1

UDTNO USRNBR  UID USRNAME   USRTYPE  TTYIP-ADDRESS TIME DATE
1   2488 197612 AsiAdmin  phantom pts/1   Console 10:42:32 Jan 15 2014
2   3920 197610 JohnSmith udt pts/2   192.168.1.52  08:15:33 Jan
28 2014
3180 197608 udcsuser udcspts/3   udcs  09:22:57 Jan
28 2014
4   3840 197608 udcsuser  udcspts/4   udcs 09:23:08 Jan 28 2014

Now, if John Smith goes to read and lock a record that is locked by
port#3, how can I figure out which port# actually has the record locked,
since the UniData GETUSER() function only returns the UID, and that
user, because it is a UniObjects user, is connected on more than one port#?

I have a file managed at login that keeps track of the PORT#s and the
associated users assigned by our application.  I want our logging to
report that a record lock by user so-and-so on port {n} is already in place.

Thanks.

Bill
___
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] [UD] Who's locking a record

[David A. Green]

Can you get what you need using GETREADU?

David A. Green
(480) 201-7953
DAG Consulting

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, January 28, 2014 1:18 PM
To: U2 Mail List
Subject: [U2] [UD] Who's locking a record

In UniData, if you do a READU you can find out the User ID who has the
record locked by using the STATUS() function; this returns the 'UID' 
value.  Here's a list of users:

3 Dev (0)-> lu

Licensed(UDT+CP)/Effective  Udt Sql iPhtm Pooled  Total

 (  24 + 1   ) / 25  1   0   0 0   1

UDTNO USRNBR  UID USRNAME   USRTYPE  TTYIP-ADDRESS TIME DATE
1   2488 197612 AsiAdmin  phantom pts/1   Console 10:42:32 Jan 15 2014
   2   3920 197610 JohnSmith udt pts/2   192.168.1.52  08:15:33 Jan 
28 2014
   3180 197608 udcsuser udcspts/3   udcs  09:22:57 Jan 
28 2014
   4   3840 197608 udcsuser  udcspts/4   udcs 09:23:08 Jan 28 2014

Now, if John Smith goes to read and lock a record that is locked by port#3,
how can I figure out which port# actually has the record locked, since the
UniData GETUSER() function only returns the UID, and that user, because it
is a UniObjects user, is connected on more than one port#?

I have a file managed at login that keeps track of the PORT#s and the
associated users assigned by our application.  I want our logging to report
that a record lock by user so-and-so on port {n} is already in place.

Thanks.

Bill
___
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] [UD] Who's locking a record

[Lunt, Bruce]

Here's how we do it:



READU MASTER.REC FROM F.CNTRL, 'COM.MASTER' LOCKED
   UID = STATUS()
   CMD = '!grep :':UID:': /etc/passwd | cut -d -f5'
   EXECUTE CMD CAPTURING USER.NAME
   MSG = 'DIST record - ':DIST.NBR:' is locked by: ':USER.NAME<1>
   CALL SB.DISP(9,MSG)
   SLEEP 5
   CALL SB.DISP(9.'')
   RETURN
END ELSE
   RELEASE F.CNTRL, 'COM.MASTER'
   STOP
END


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, January 28, 2014 12:18 PM
To: U2 Mail List
Subject: [U2] [UD] Who's locking a record

In UniData, if you do a READU you can find out the User ID who has the
record locked by using the STATUS() function; this returns the 'UID'
value.  Here's a list of users:

3 Dev (0)-> lu

Licensed(UDT+CP)/Effective  Udt Sql iPhtm Pooled  Total

 (  24 + 1   ) / 25  1   0   0 0   1

UDTNO USRNBR  UID USRNAME   USRTYPE  TTYIP-ADDRESS TIME DATE
1   2488 197612 AsiAdmin  phantom pts/1   Console 10:42:32 Jan 15 2014
   2   3920 197610 JohnSmith udt pts/2   192.168.1.52  08:15:33 Jan
28 2014
   3180 197608 udcsuser udcspts/3   udcs  09:22:57 Jan
28 2014
   4   3840 197608 udcsuser  udcspts/4   udcs 09:23:08 Jan 28 2014

Now, if John Smith goes to read and lock a record that is locked by
port#3, how can I figure out which port# actually has the record locked,
since the UniData GETUSER() function only returns the UID, and that
user, because it is a UniObjects user, is connected on more than one port#?

I have a file managed at login that keeps track of the PORT#s and the
associated users assigned by our application.  I want our logging to
report that a record lock by user so-and-so on port {n} is already in place.

Thanks.

Bill
___
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] UD PE 7.1.0 - Use of EXECUTE with the RTNLIST option

[Rutherford, Marc]

Bruce,

The order of the clauses is important.  I always use in the following sequence:

EXECUTE stmt PASSLIST RTNLIST CAPTURING RETURNING


Marc Rutherford
Principal Programmer/Analyst
Advanced Bionics LLC
661 362-1754


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bruce Decker
Sent: Wednesday, November 20, 2013 3:56 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UD PE 7.1.0 - Use of EXECUTE with the RTNLIST option

This is a reply to a old post but since this is the top search result for 
RTNLIST, I'll post a reply with useful info.  Unidata's BASIC compiler seems to 
be quite particular about the ORDER of the clauses on an Execute.  Put RTNLIST, 
RETURNING AND CAPTURING in the wrong order and you'll see a error like this:

Compiling Unibasic: mysource\test4 in mode 'p'.
main program: syntax error at or before
 EXECUTE \SELECT VOC\ RETURNING junk RTNLIST l.voc CAPTURING screen;
 --^
Misuse of reserved word 'RTNLIST'
Expecting: end-of-file,END

compilation failed

Here is the code with examples of proper order of the clauses on an execute and 
the final example of EXECUTE producing the failure message above...

done = @FALSE
l.voc = \\
i = 0
EXECUTE \SELECT VOC\ RTNLIST l.voc  
 
; *compiles ok
EXECUTE \SELECT VOC\ RTNLIST l.voc RETURNING junk  ;
*compiles ok
EXECUTE \SELECT VOC\ RTNLIST l.voc RETURNING junk CAPTURING screen; *compiles 
ok EXECUTE \SELECT VOC\ RETURNING junk RTNLIST l.voc CAPTURING screen; *fails 
compile LOOP READNEXT id FROM l.voc ELSE done = @TRUE UNTIL done DO
   i=+ 1
REPEAT
CRT i:\ records counted\
STOP 



--
View this message in context: 
http://u2-universe-unidata.1073795.n5.nabble.com/UD-PE-7-1-0-Use-of-EXECUTE-with-the-RTNLIST-option-tp7096p42187.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
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] UD PE 7.1.0 - Use of EXECUTE with the RTNLIST option

[Bill Haskett]

Bruce:

Thanks.  This always gets me so I never use the RTNLIST.  :-)

Bill
Untitled Page



- Original Message -
*From:* bdec...@bluepinc.com
*To:* u2-users@listserver.u2ug.org
*Date:* 11/20/2013 3:56 PM
*Subject:* Re: [U2] UD PE 7.1.0 - Use of EXECUTE with the RTNLIST option

This is a reply to a old post but since this is the top search result for
RTNLIST, I'll post a reply with useful info.  Unidata's BASIC compiler seems
to be quite particular about the ORDER of the clauses on an Execute.  Put
RTNLIST, RETURNING AND CAPTURING in the wrong order and you'll see a error
like this:

Compiling Unibasic: mysource\test4 in mode 'p'.
main program: syntax error at or before
 EXECUTE \SELECT VOC\ RETURNING junk RTNLIST l.voc CAPTURING screen;
  --^
Misuse of reserved word 'RTNLIST'
Expecting: end-of-file,END

compilation failed

Here is the code with examples of proper order of the clauses on an execute
and the final example of EXECUTE producing the failure message above...

done = @FALSE
l.voc = \\
i = 0
*
EXECUTE \SELECT VOC\ RTNLIST l.voc ; *compiles 
ok
EXECUTE \SELECT VOC\ RTNLIST l.voc RETURNING junk  ; *compiles 
ok
EXECUTE \SELECT VOC\ RTNLIST l.voc RETURNING junk CAPTURING screen ; *compiles 
ok
EXECUTE \SELECT VOC\ RETURNING junk RTNLIST l.voc CAPTURING screen ; *fails 
compile
*
LOOP
READNEXT id FROM l.voc ELSE done = @TRUE
UNTIL done DO
i=+ 1
REPEAT
CRT i:\ records counted\
STOP



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

Re: [U2] UD PE 7.1.0 - Use of EXECUTE with the RTNLIST option

[Bruce Decker]

This is a reply to a old post but since this is the top search result for
RTNLIST, I'll post a reply with useful info.  Unidata's BASIC compiler seems
to be quite particular about the ORDER of the clauses on an Execute.  Put
RTNLIST, RETURNING AND CAPTURING in the wrong order and you'll see a error
like this:

Compiling Unibasic: mysource\test4 in mode 'p'.
main program: syntax error at or before
 EXECUTE \SELECT VOC\ RETURNING junk RTNLIST l.voc CAPTURING screen;
 --^
Misuse of reserved word 'RTNLIST'
Expecting: end-of-file,END

compilation failed

Here is the code with examples of proper order of the clauses on an execute
and the final example of EXECUTE producing the failure message above...

done = @FALSE
l.voc = \\
i = 0
EXECUTE \SELECT VOC\ RTNLIST l.voc  
 
; *compiles ok
EXECUTE \SELECT VOC\ RTNLIST l.voc RETURNING junk  ;
*compiles ok
EXECUTE \SELECT VOC\ RTNLIST l.voc RETURNING junk CAPTURING screen;
*compiles ok
EXECUTE \SELECT VOC\ RETURNING junk RTNLIST l.voc CAPTURING screen; *fails
compile
LOOP
READNEXT id FROM l.voc ELSE done = @TRUE
UNTIL done DO
   i=+ 1
REPEAT
CRT i:\ records counted\
STOP 



--
View this message in context: 
http://u2-universe-unidata.1073795.n5.nabble.com/UD-PE-7-1-0-Use-of-EXECUTE-with-the-RTNLIST-option-tp7096p42187.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] UD hot backup/RFS options

[McGowan, Ian]

Thanks Ty and Rod.  Good to hear RFS works well - perhaps the lack of google 
hits is because it Just Works (tm).

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ty Haller
Sent: Friday, October 11, 2013 8:28 AM
To: U2 Users List
Subject: Re: [U2] UD hot backup/RFS options

We've been using RFS with Replication for years. Our entire DB is setup with 
RFS and is replicated, about 300GB. (AIX 7.1 UniData 7.2.13)

The RFS Logs are on a separate set of RAID 10 Disks, and doesn't seem to add 
that much overhead although we are utilizing SSDs now. GUIDE Runs pretty fast < 
1hr.

We run a triple mirror setup and split off the mirror nightly to backup. Any 
crashes (rare), RFS has been able to recover from.

If needed we could run off of our DR System or copy the data back again (couple 
of hours).


Ty Haller
SEFCU
Lead Administrator - System Services
thal...@sefcu.com


> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- 
> boun...@listserver.u2ug.org] On Behalf Of Baakkonen, Rodney A (Rod) 
> 46K
> Sent: Friday, October 11, 2013 11:19 AM
> To: U2 Users List
> Subject: Re: [U2] UD hot backup/RFS options
> 
>  We have used it for about 15 years. I can remember the last time we 
> crashed (Solaris).  IF the redo logs look ok and the Unidata logs 
> don't have issues, I don't run guide on our RFS files. We only have 
> our largest files defined as RFS (10 gigabytes to almost 100 
> gigabytes). We did not put in the begin/end transaction statements in 
> our code. So RFS uses a timing mechanism to figure out when to write data out.
> 
> There is a performance difference, as you are doing extra i/o for each 
> RFS read. But we can usually fully recover our site in a couple of 
> hours. We are on Unidata 7.1 and hope to move to Unidata 7.2.13 soon.
> 
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- 
> boun...@listserver.u2ug.org] On Behalf Of McGowan, Ian
> Sent: Friday, October 11, 2013 9:33 AM
> To: U2 Users List
> Subject: [U2] UD hot backup/RFS options
> 
> We had a server crash 4pm yesterday (very unusual for IBM RS6000) and 
> after guide/fixfile we had so much data corruption that a restore from 
> previous days backup was needed.
> 
> The question for the list is if anyone is successfully doing RFS or 
> other incremental type backups?  A quick google search shows a lot of 
> people asking questions, but not a lot of "it works great" success 
> stories.  Looking to get a sense of real world usage before heading 
> down that road, and potentially paying for consulting to implement.
> 
> Any input, opinions, advice appreciated!
> Ian
> -
> IMPORTANT NOTICE:   This message is intended only for the addressee
> and may contain confidential, privileged information.  If you are not 
> the intended recipient, you may not use, copy or disclose any 
> information contained in the message.  If you have received this 
> message in error, please notify the sender by reply e-mail and delete the 
> message.
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> 
> --
>  CONFIDENTIALITY NOTICE: If you have received this email in 
> error, please immediately notify the sender by e-mail at the address 
> shown.
> This email transmission may contain confidential information.  This 
> information is intended only for the use of the individual(s) or 
> entity to whom it is intended even if addressed incorrectly.  Please 
> delete it from your files if you are not the intended recipient.  
> Thank you for your compliance.  Copyright (c) 2013 Cigna 
> ===
> ===
> 
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users

This message may contain confidential information and is intended for the sole 
purpose of communication with the addressee. Dissemination or publication in 
any format is strictly prohibited. If you have received this communication in 
error please notify SEFCU immediately.

Help save a tree. Please print this e-mail only if it is truly necessary. Thank 
you.
___
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] UD hot backup/RFS options

[Ty Haller]

We've been using RFS with Replication for years. Our entire DB is setup with 
RFS and is replicated, about 300GB. (AIX 7.1 UniData 7.2.13)

The RFS Logs are on a separate set of RAID 10 Disks, and doesn't seem to add 
that much overhead although we are utilizing SSDs now. GUIDE Runs pretty fast < 
1hr.

We run a triple mirror setup and split off the mirror nightly to backup. Any 
crashes (rare), RFS has been able to recover from.

If needed we could run off of our DR System or copy the data back again (couple 
of hours).


Ty Haller
SEFCU
Lead Administrator - System Services
thal...@sefcu.com


> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
> boun...@listserver.u2ug.org] On Behalf Of Baakkonen, Rodney A (Rod) 46K
> Sent: Friday, October 11, 2013 11:19 AM
> To: U2 Users List
> Subject: Re: [U2] UD hot backup/RFS options
> 
>  We have used it for about 15 years. I can remember the last time we
> crashed (Solaris).  IF the redo logs look ok and the Unidata logs don't have
> issues, I don't run guide on our RFS files. We only have our largest files
> defined as RFS (10 gigabytes to almost 100 gigabytes). We did not put in the
> begin/end transaction statements in our code. So RFS uses a timing
> mechanism to figure out when to write data out.
> 
> There is a performance difference, as you are doing extra i/o for each RFS
> read. But we can usually fully recover our site in a couple of hours. We are
> on Unidata 7.1 and hope to move to Unidata 7.2.13 soon.
> 
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
> boun...@listserver.u2ug.org] On Behalf Of McGowan, Ian
> Sent: Friday, October 11, 2013 9:33 AM
> To: U2 Users List
> Subject: [U2] UD hot backup/RFS options
> 
> We had a server crash 4pm yesterday (very unusual for IBM RS6000) and
> after guide/fixfile we had so much data corruption that a restore from
> previous days backup was needed.
> 
> The question for the list is if anyone is successfully doing RFS or other
> incremental type backups?  A quick google search shows a lot of people
> asking questions, but not a lot of "it works great" success stories.  Looking 
> to
> get a sense of real world usage before heading down that road, and
> potentially paying for consulting to implement.
> 
> Any input, opinions, advice appreciated!
> Ian
> -
> IMPORTANT NOTICE:   This message is intended only for the addressee
> and may contain confidential, privileged information.  If you are not the
> intended recipient, you may not use, copy or disclose any information
> contained in the message.  If you have received this message in error,
> please notify the sender by reply e-mail and delete the message.
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> 
> --
> CONFIDENTIALITY NOTICE: If you have received this email in error, please
> immediately notify the sender by e-mail at the address shown.
> This email transmission may contain confidential information.  This
> information is intended only for the use of the individual(s) or entity to
> whom it is intended even if addressed incorrectly.  Please delete it from
> your files if you are not the intended recipient.  Thank you for your
> compliance.  Copyright (c) 2013 Cigna
> ===
> ===
> 
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users

This message may contain confidential information and is intended for the sole 
purpose of communication with the addressee. Dissemination or publication in 
any format is strictly prohibited. If you have received this communication in 
error please notify SEFCU immediately.

Help save a tree. Please print this e-mail only if it is truly necessary. Thank 
you.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] UD hot backup/RFS options

[Baakkonen, Rodney A (Rod) 46K]

 We have used it for about 15 years. I can remember the last time we crashed 
(Solaris).  IF the redo logs look ok and the Unidata logs don't have issues, I 
don't run guide on our RFS files. We only have our largest files defined as RFS 
(10 gigabytes to almost 100 gigabytes). We did not put in the begin/end 
transaction statements in our code. So RFS uses a timing mechanism to figure 
out when to write data out. 

There is a performance difference, as you are doing extra i/o for each RFS 
read. But we can usually fully recover our site in a couple of hours. We are on 
Unidata 7.1 and hope to move to Unidata 7.2.13 soon.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of McGowan, Ian
Sent: Friday, October 11, 2013 9:33 AM
To: U2 Users List
Subject: [U2] UD hot backup/RFS options

We had a server crash 4pm yesterday (very unusual for IBM RS6000) and after 
guide/fixfile we had so much data corruption that a restore from previous days 
backup was needed.

The question for the list is if anyone is successfully doing RFS or other 
incremental type backups?  A quick google search shows a lot of people asking 
questions, but not a lot of "it works great" success stories.  Looking to get a 
sense of real world usage before heading down that road, and potentially paying 
for consulting to implement.

Any input, opinions, advice appreciated!
Ian
-
IMPORTANT NOTICE:   This message is intended only for the addressee
and may contain confidential, privileged information.  If you are not the 
intended recipient, you may not use, copy or disclose any information contained 
in the message.  If you have received this message in error, please notify the 
sender by reply e-mail and delete the message.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

--
CONFIDENTIALITY NOTICE: If you have received this email in error,
please immediately notify the sender by e-mail at the address shown. 
This email transmission may contain confidential information.  This
information is intended only for the use of the individual(s) or entity to
whom it is intended even if addressed incorrectly.  Please delete it from
your files if you are not the intended recipient.  Thank you for your
compliance.  Copyright (c) 2013 Cigna
==

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

Re: [U2] [UD] BASIC Code Failing

[Wjhonson]

If you were to copy your source code to another location and then compile and 
compare the object, would the two objects be the same?


 

 

 

-Original Message-
From: Brian Leach 
To: 'U2 Users List' 
Sent: Thu, Aug 1, 2013 4:10 am
Subject: Re: [U2] [UD] BASIC Code Failing


David

I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course. 

The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.

Brian



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

In UV we're had similar strange problems with seemingly unchanged
source/object code - not work as per normal and things going amiss for no
good reason...once we found the object code in BP and the catalog space were
mismatched and simply re-catalog'd it. Another time we re-compiled a program
- as it was always invoked via RUN BP PROGNAME... in both instances the
problem seem to go away.  This was in a controlled product environment so
it's in highly unlikely someone could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually
catalogued...

All of these issues made me wonder if our implementation routines need to
have a more robust. More robust in terms of storing some control information
for both pre/post verification - hence being able to detect 'unauthorised
changes' through the various stages. This could include calculating and
storing (say) MD5 (etc) hashes on the source and object to cross verify
changes. Hence, make it more easy to detect object or source changes outside
the authorised/control deployment process... without having to go through
every single file and comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account
every night, so I do have the last 10 days object code in a backup (plus the
last four months weekly backups).  I'll look at this the next time it
happens.  Thanks,

Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I would also consider the possibility of data corruption at the 
> hardware level.  Granted, I would expect that you'd also occasionally 
> find anomalies within your source code and data files if this were the 
> case, but I don't know how your filesystems are set up.  If the object 
> code has become corrupt, that would explain why recompiling fixes the 
> problem.  The newly created object code will be stored on a new 
> location in the filesystem.  Fortunately this possibility is very easy 
> to test for.  Just make a copy of your application account on 
> alternate storage and wait for the problem to recur.  When it does, 
> open the live object file and your backup copy in an editor with diff 
> capability (Notepad++ is a good one) and see if they still match.
>
> -John


** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. 
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line. 
**



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

Re: [U2] [UD] BASIC Code Failing

[Hona, David]

Hi Brian

That's a good idea to do what you have done and do in mvStamp...

I guess what I'm also look at is that the use of MD5 checksums (for example) is 
a 'well known/accepted and platform independent' mechanism to verify files are 
'as they should be'.

Hence, in theory you quickly detect changes that have occurred to the object, 
source and catalog version in simple independent way without even referencing 
back a source control system. Plus in UV BASIC you now have the ENCODE and 
ENCRYPT functions to help you check/secure your code - if you so desire - 
post-implementation.

Here's simple compilation comparison before and after...obviously you can 
extend it to the source changes in catdir, etc.


$ openssl md5 /my/PROGRAMS/BP.O/test123
MD5(/my/PROGRAMS/BP.O/test123)= 7e3743a1ac709cca2f9e1dd034e19048
$ nbasic BP test123
Compiling: Source = '/my/PROGRAMS/BP/test123, Object = 
'/my/PROGRAMS/BP.O/test123
***

Compilation Complete.
$ openssl md5 /my/PROGRAMS/BP.O/test123
MD5(/my/PROGRAMS/BP.O/test123)= 080524f5d4da1c363298e2e538d3cf49

$ openssl md5 `cat /.uvhome`/catdir/'*test123
MD5(/usr/ibm/uv/catdir/*test123)= 05b3b02a4369915e448af6837160ac8f
$


Regards,
David


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, 1 August 2013 11:13 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] BASIC Code Failing

Dale

The stamp I use assigns a dummy variable using strings that contain searchable 
keys. That means when the code is compiled these strings end up unaltered in 
the object code string table, so that they can be easily found and extracted.

For example:

VERDATA=''
   VERDATA := 'Version=001000136;'
   VERDATA := 'VerBeta=;'
   VERDATA := 'VerDate=16637;'
   VERDATA := 'VerProd=mvPDF;'
   VERDATA := 'VerTM=mvPDF;'
   VERDATA := 'VerCopy=2013 Brian Leach Consulting Limited;'
   VERDATA := 'VerCo=Brian Leach Consulting Limited;'
   VERDATA := 'VerDesc=Produce a PDF Document by merging data;'
   VERDATA := 'CatName=PDF.MERGE;'
   VERDATA := 'VerModule=GENERAL;'
   VERDATA := 'VerModVer=002003022;'
   VERDATA := 'VerHist=19 JUL 13 1.0.136 Release 2.3.22;'


A useful addition is that I have a I Descriptor that returns this, so I can 
list the source or object file and rip out these details:


LIST pdf.bp.O "PDF.MERGE" 01:02:24pm  01 Aug 2013  PAGE1
pdf.bp.O.. Version.. Version 
Description... Module Version

PDF.MERGE  1.0.136   Produce a PDF Document by merging
data 2.3.22

I did put some free code on my website to do this - look for mvStamp.

As for cutting or build scripts, these refer to anything that builds your 
software.. every site should have something to do this, to ensure a smooth and 
automated transition from test to live or for deployment.

In my case, the build process usually consists of a script written in vbscript 
(WSH) that runs the various client side builds (for Delphi, C#
etc.) then uses UniObjects to execute a server side cutting paragraph passing 
the new version number. This typically updates the version stamps, recompiles 
everything, handles any platform builds (most of my stuff runs on UniVerse, 
UniData, QM and D3), updates a README document from my task system, adds them 
all into revision control, then calls mvInstaller to build the release package. 
Then control passes back to the vbscript to assemble the setup (InstallShield 
or visual studio) and zip  the resulting setup ready for upload.

I did think about kicking off all the unit tests as well but I prefer to do 
that after a test installation.

All of which took some setting up to begin with but has saved enormous amounts 
of time and agony since.

Brian

-----Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: 01 August 2013 12:27
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

Brian,

Is the stamp just

VERSION = "123"  ,?

Could you explain what you mean by "cutting routines",  I've either never heard 
that term or my "old timers" is kicking in.

dale

On 08/01/2013 06:09 AM, Brian Leach wrote:
> David
>
> I add version stamps to my code that compile into the object code, so 
> at least I can easily check that the source and object (including that 
> in
> catdir) matches what I expect. That's at least a small and easy step 
> in the right direction, though that doesn't rule out changes that 
> don't updat

Re: [U2] [UD] BASIC Code Failing

[Brian Leach]

Dale

The stamp I use assigns a dummy variable using strings that contain
searchable keys. That means when the code is compiled these strings end up
unaltered in the object code string table, so that they can be easily found
and extracted.

For example:

VERDATA=''
   VERDATA := 'Version=001000136;'
   VERDATA := 'VerBeta=;'
   VERDATA := 'VerDate=16637;'
   VERDATA := 'VerProd=mvPDF;'
   VERDATA := 'VerTM=mvPDF;'
   VERDATA := 'VerCopy=2013 Brian Leach Consulting Limited;'
   VERDATA := 'VerCo=Brian Leach Consulting Limited;'
   VERDATA := 'VerDesc=Produce a PDF Document by merging data;'
   VERDATA := 'CatName=PDF.MERGE;'
   VERDATA := 'VerModule=GENERAL;'
   VERDATA := 'VerModVer=002003022;'
   VERDATA := 'VerHist=19 JUL 13 1.0.136 Release 2.3.22;'


A useful addition is that I have a I Descriptor that returns this, so I can
list the source or object file and rip out these details:


LIST pdf.bp.O "PDF.MERGE" 01:02:24pm  01 Aug 2013  PAGE1
pdf.bp.O.. Version.. Version
Description... Module Version

PDF.MERGE  1.0.136   Produce a PDF Document by merging
data 2.3.22

I did put some free code on my website to do this - look for mvStamp.

As for cutting or build scripts, these refer to anything that builds your
software.. every site should have something to do this, to ensure a smooth
and automated transition from test to live or for deployment.

In my case, the build process usually consists of a script written in
vbscript (WSH) that runs the various client side builds (for Delphi, C#
etc.) then uses UniObjects to execute a server side cutting paragraph
passing the new version number. This typically updates the version stamps,
recompiles everything, handles any platform builds (most of my stuff runs on
UniVerse, UniData, QM and D3), updates a README document from my task
system, adds them all into revision control, then calls mvInstaller to build
the release package. Then control passes back to the vbscript to assemble
the setup (InstallShield or visual studio) and zip  the resulting setup
ready for upload.

I did think about kicking off all the unit tests as well but I prefer to do
that after a test installation.

All of which took some setting up to begin with but has saved enormous
amounts of time and agony since.

Brian

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: 01 August 2013 12:27
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

Brian,

Is the stamp just

VERSION = "123"  ,?

Could you explain what you mean by "cutting routines",  I've either never
heard that term or my "old timers" is kicking in.

dale

On 08/01/2013 06:09 AM, Brian Leach wrote:
> David
>
> I add version stamps to my code that compile into the object code, so 
> at least I can easily check that the source and object (including that 
> in
> catdir) matches what I expect. That's at least a small and easy step 
> in the right direction, though that doesn't rule out changes that 
> don't update the stamp of course.
>
> The stamps are always updated by my cutting routines and then the 
> items are then added to source control as part of the cut... If you 
> did something similar you can always diff what you've got against your 
> source code control system rather than reinventing the wheel.
>
> Brian
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
> Sent: 01 August 2013 10:49
> To: U2 Users List
> Subject: Re: [U2] [UD] BASIC Code Failing
>
> In UV we're had similar strange problems with seemingly unchanged 
> source/object code - not work as per normal and things going amiss for 
> no good reason...once we found the object code in BP and the catalog 
> space were mismatched and simply re-catalog'd it. Another time we 
> re-compiled a program
> - as it was always invoked via RUN BP PROGNAME... in both instances 
> the problem seem to go away.  This was in a controlled product 
> environment so it's in highly unlikely someone could of or would've
changed the code...
>
> In UV you can do a VCATALOG to verify the BASIC object to what is 
> actually catalogued...
>
> All of these issues made me wonder if our implementation routines need 
> to have a more robust. More robust in terms of storing some control 
> information for both pre/post verification - hence being able to 
> detect 'unauthorised changes' through the various stages. This could 
> 

Re: [U2] [UD] BASIC Code Failing

[dale kelley]

Brian,

Is the stamp just

VERSION = "123"  ,?

Could you explain what you mean by "cutting routines",  I've either 
never heard that term or my "old timers" is kicking in.


dale

On 08/01/2013 06:09 AM, Brian Leach wrote:

David

I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course.

The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.

Brian



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

In UV we're had similar strange problems with seemingly unchanged
source/object code - not work as per normal and things going amiss for no
good reason...once we found the object code in BP and the catalog space were
mismatched and simply re-catalog'd it. Another time we re-compiled a program
- as it was always invoked via RUN BP PROGNAME... in both instances the
problem seem to go away.  This was in a controlled product environment so
it's in highly unlikely someone could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually
catalogued...

All of these issues made me wonder if our implementation routines need to
have a more robust. More robust in terms of storing some control information
for both pre/post verification - hence being able to detect 'unauthorised
changes' through the various stages. This could include calculating and
storing (say) MD5 (etc) hashes on the source and object to cross verify
changes. Hence, make it more easy to detect object or source changes outside
the authorised/control deployment process... without having to go through
every single file and comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account
every night, so I do have the last 10 days object code in a backup (plus the
last four months weekly backups).  I'll look at this the next time it
happens.  Thanks,

Bill
Untitled Page



- Original Message -----
*From:* jhes...@momtex.com
*To:* U2 Users List
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing

I would also consider the possibility of data corruption at the
hardware level.  Granted, I would expect that you'd also occasionally
find anomalies within your source code and data files if this were the
case, but I don't know how your filesystems are set up.  If the object
code has become corrupt, that would explain why recompiling fixes the
problem.  The newly created object code will be stored on a new
location in the filesystem.  Fortunately this possibility is very easy
to test for.  Just make a copy of your application account on
alternate storage and wait for the problem to recur.  When it does,
open the live object file and your backup copy in an editor with diff
capability (Notepad++ is a good one) and see if they still match.

-John


** IMPORTANT MESSAGE *
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential.
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries.
We can be contacted through our web site: commbank.com.au.
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line.
**



___
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] [UD] BASIC Code Failing

[Brian Leach]

David

I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course. 

The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.

Brian



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

In UV we're had similar strange problems with seemingly unchanged
source/object code - not work as per normal and things going amiss for no
good reason...once we found the object code in BP and the catalog space were
mismatched and simply re-catalog'd it. Another time we re-compiled a program
- as it was always invoked via RUN BP PROGNAME... in both instances the
problem seem to go away.  This was in a controlled product environment so
it's in highly unlikely someone could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually
catalogued...

All of these issues made me wonder if our implementation routines need to
have a more robust. More robust in terms of storing some control information
for both pre/post verification - hence being able to detect 'unauthorised
changes' through the various stages. This could include calculating and
storing (say) MD5 (etc) hashes on the source and object to cross verify
changes. Hence, make it more easy to detect object or source changes outside
the authorised/control deployment process... without having to go through
every single file and comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account
every night, so I do have the last 10 days object code in a backup (plus the
last four months weekly backups).  I'll look at this the next time it
happens.  Thanks,

Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I would also consider the possibility of data corruption at the 
> hardware level.  Granted, I would expect that you'd also occasionally 
> find anomalies within your source code and data files if this were the 
> case, but I don't know how your filesystems are set up.  If the object 
> code has become corrupt, that would explain why recompiling fixes the 
> problem.  The newly created object code will be stored on a new 
> location in the filesystem.  Fortunately this possibility is very easy 
> to test for.  Just make a copy of your application account on 
> alternate storage and wait for the problem to recur.  When it does, 
> open the live object file and your backup copy in an editor with diff 
> capability (Notepad++ is a good one) and see if they still match.
>
> -John


** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. 
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line. 
**



___
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] [UD] BASIC Code Failing

[Hona, David]

In UV we're had similar strange problems with seemingly unchanged source/object 
code - not work as per normal and things going amiss for no good reason...once 
we found the object code in BP and the catalog space were mismatched and simply 
re-catalog'd it. Another time we re-compiled a program - as it was always 
invoked via RUN BP PROGNAME... in both instances the problem seem to go away.  
This was in a controlled product environment so it's in highly unlikely someone 
could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually 
catalogued...

All of these issues made me wonder if our implementation routines need to have 
a more robust. More robust in terms of storing some control information for 
both pre/post verification - hence being able to detect 'unauthorised changes' 
through the various stages. This could include calculating and storing (say) 
MD5 (etc) hashes on the source and object to cross verify changes. Hence, make 
it more easy to detect object or source changes outside the authorised/control 
deployment process... without having to go through every single file and 
comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account every 
night, so I do have the last 10 days object code in a backup (plus the last 
four months weekly backups).  I'll look at this the next time it happens.  
Thanks,

Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I would also consider the possibility of data corruption at the 
> hardware level.  Granted, I would expect that you'd also occasionally 
> find anomalies within your source code and data files if this were the 
> case, but I don't know how your filesystems are set up.  If the object 
> code has become corrupt, that would explain why recompiling fixes the 
> problem.  The newly created object code will be stored on a new 
> location in the filesystem.  Fortunately this possibility is very easy 
> to test for.  Just make a copy of your application account on 
> alternate storage and wait for the problem to recur.  When it does, 
> open the live object file and your backup copy in an editor with diff 
> capability (Notepad++ is a good one) and see if they still match.
>
> -John


** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains 
information which may be
confidential. 
If you are not the intended recipient please advise the sender by return email, 
do not use or
disclose the contents, and delete the message and any attachments from your 
system. Unless
specifically indicated, this email does not constitute formal advice or 
commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us, please 
reply to this
e-mail by typing Unsubscribe in the subject line. 
**



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

Re: [U2] [UD] BASIC Code Failing

[Bill Haskett]

John:

That's an interesting thought.  We do backups of the application account 
every night, so I do have the last 10 days object code in a backup (plus 
the last four months weekly backups).  I'll look at this the next time 
it happens.  Thanks,


Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing

I would also consider the possibility of data corruption at the hardware
level.  Granted, I would expect that you'd also occasionally find
anomalies within your source code and data files if this were the case,
but I don't know how your filesystems are set up.  If the object code
has become corrupt, that would explain why recompiling fixes the
problem.  The newly created object code will be stored on a new location
in the filesystem.  Fortunately this possibility is very easy to test
for.  Just make a copy of your application account on alternate storage
and wait for the problem to recur.  When it does, open the live object
file and your backup copy in an editor with diff capability (Notepad++
is a good one) and see if they still match.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, July 25, 2013 12:25 PM
To: U2 Mail List
Subject: [U2] [UD] BASIC Code Failing

We've been having an anomaly that has occurred over the past 7 years
we've been using UniData on Windows.

Yesterday one of the accounts on our ASP server, that contains about 30
accounts, had a billing issue.  This issue was created because a single
BASIC program didn't run a couple of lines of code, thus a particular
type of charge wasn't created for anyone on this account.  The BASIC
code is compiled in an "application" account then cataloged locally in
each account (a pointer to the program file exists on every account).

When I make a copy of this particular account, then run the offending
program in it, I see the same problem.  When I put a DEBUG statement (in
the offending program) just above where I suspect the problem occurs,
recompile then rerun it, there is no problem.  After futzing around with
placing the DEBUG statement in several different locations, with no
further issue, I remove the DEBUG statement and finally re-compile the
offending program.  I've changed nothing in the program, but it now
works.  This particular program runs maybe 250,000 billings every month
with nothing wrong happening.  In fact, I haven't seen this problem in
this billing program for the past seven years, which means that maybe
over 20 million transactions have been created with no issues.

This happens about once every six months or so on one BASIC program or
another, where I look at an offending program, see something like five
lines of code writing to five different files, and the issue is the last
two lines didn't execute.  When I put a DEBUG into the program
everything works fine.  When I remove the DEBUG statement and recompile
everything works fine from then on.

Has anyone else seen this?  Maybe there's something I should do to
prevent this.

Bill
___
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] [UD] BASIC Code Failing

[John Hester]

I would also consider the possibility of data corruption at the hardware
level.  Granted, I would expect that you'd also occasionally find
anomalies within your source code and data files if this were the case,
but I don't know how your filesystems are set up.  If the object code
has become corrupt, that would explain why recompiling fixes the
problem.  The newly created object code will be stored on a new location
in the filesystem.  Fortunately this possibility is very easy to test
for.  Just make a copy of your application account on alternate storage
and wait for the problem to recur.  When it does, open the live object
file and your backup copy in an editor with diff capability (Notepad++
is a good one) and see if they still match.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, July 25, 2013 12:25 PM
To: U2 Mail List
Subject: [U2] [UD] BASIC Code Failing

We've been having an anomaly that has occurred over the past 7 years
we've been using UniData on Windows.

Yesterday one of the accounts on our ASP server, that contains about 30
accounts, had a billing issue.  This issue was created because a single
BASIC program didn't run a couple of lines of code, thus a particular
type of charge wasn't created for anyone on this account.  The BASIC
code is compiled in an "application" account then cataloged locally in
each account (a pointer to the program file exists on every account).

When I make a copy of this particular account, then run the offending
program in it, I see the same problem.  When I put a DEBUG statement (in
the offending program) just above where I suspect the problem occurs,
recompile then rerun it, there is no problem.  After futzing around with
placing the DEBUG statement in several different locations, with no
further issue, I remove the DEBUG statement and finally re-compile the
offending program.  I've changed nothing in the program, but it now
works.  This particular program runs maybe 250,000 billings every month
with nothing wrong happening.  In fact, I haven't seen this problem in
this billing program for the past seven years, which means that maybe
over 20 million transactions have been created with no issues.

This happens about once every six months or so on one BASIC program or
another, where I look at an offending program, see something like five
lines of code writing to five different files, and the issue is the last
two lines didn't execute.  When I put a DEBUG into the program
everything works fine.  When I remove the DEBUG statement and recompile
everything works fine from then on.

Has anyone else seen this?  Maybe there's something I should do to
prevent this.

Bill
___
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] [UD] BASIC Code Failing

[Tony Gravagno]

> From: Charlie Noah 
> 1. If POLREC<6> is null, an empty value won't be inserted...
> 2. INSERT sometimes doesn't like delimited source
> 3. If POLREC<6> has multivalues itself...

Charlie, you present a valid discussion of a failure with the Insert
statement, but that might not be the problem at all. Bill Haskett's
original statement says he just inserted a DEBUG statement before the
problem line and the problem went away. We're not talking about syntax
or any one statement. We're talking about a run-time failure to
execute any random statement in your code base. The ramifications for
that are huge.

The best thing that can happen to anyone here is to find one of these
buggers in some non-critical location. The worst thing anyone can do
is to hide the condition so that the problem doesn't occur in a benign
area - that just leaves the problem undiagnosed and unresolved for
potentially critical areas in the current application or others. I
can't emphasize strongly enough how devastating a problem like this
could be ... if indeed this is the problem.

I strongly encourage any sites still covered by support to report this
issue to RS if they have a repeatable case. Diagnosing these issues in
the wild can be extremely difficult, making it easy for too many
people to get lazy, delay, defer, work-around, and not get aggressive
about the problem. But any manager of any large site here should be
thinking about how much damage an issue like this can do to their
business if it's not resolved. People who do Not see this problem in
their systems should be as assertive about seeing it resolved as those
who Do see it.

And Rocket stands to reap huge rewards in terms of customer
satisfaction if they pro-actively take steps to resolve this issue
with anyone who reports it. It doesn't make sense to avoid an
opportunity to resolve an issue for paying clients just because a
system where it's repeatable isn't currently covered.

T

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

Re: [U2] [UD] BASIC Code Failing

[dale kelley]

On 07/26/2013 04:37 PM, Charlie Noah wrote:

Tony,

I think Bob may have a good troubleshooting technique here. It would 
be simple to eliminate causes. Line 107 has a couple of potential 
problems:


0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)

I have seen these 3 situations in more than 1 MV implementation/flavor -

1. If POLREC<6> is null, an empty value won't be inserted, throwing 
associated values out of sync. Fix by prefixing or suffixing POLREC<6> 
with a character that won't be in the data, then converting it out later.
POLREC<6> is the unit price of the line item.  When it was entered 
earlier or just now on the fly, my input routine required numeric and I 
filter for unprintables.  So they can't get to receiving without a 
numeric price, though it could be zero.


2. INSERT sometimes doesn't like delimited source. Fix by moving 
POLREC<6> to a variable and inserting that.

I can try this.  The intermittence is still troubling.


3. If POLREC<6> has multivalues itself, that presents a whole 
different problem. Check it first.


Should not be possible unless I've stepped on it through miscoding in 
some other programs.


All these things can be checked in a little test program in just a few 
minutes, and a safer coding technique used.


Charlie


Thanks

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

Re: [U2] [UD] BASIC Code Failing

[Robert]

Could you post the entire program in case there are the frame boundary 
issues that Tony talked about?


Thanks,

Robert Norman
ROBERT NORMAN AND ASSOCIATES
23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
(951) 541-1668
i...@keyway.net 
http://users.keyway.net/~ice/ 
Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, 
UniVerse

Basic, UniBasic, R/BASIC, jBC.

On 7/26/2013 6:41 AM, dale kelley wrote:
This is all very interesting to hear.  I have a customer who has 
occasional instances when they complain that a supply receipt has 
failed to update the "last receipt" fields. This is the code:


0092: 
***

0093: 7000:* UPDATE SUPPLIES
0094: 
***

0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 
107 - 110 do not.


My customer refers to it as "the lawnmower man".

dale

___
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] [UD] BASIC Code Failing

[Charlie Noah]

Tony,

I think Bob may have a good troubleshooting technique here. It would be 
simple to eliminate causes. Line 107 has a couple of potential problems:


0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)

I have seen these 3 situations in more than 1 MV implementation/flavor -

1. If POLREC<6> is null, an empty value won't be inserted, throwing 
associated values out of sync. Fix by prefixing or suffixing POLREC<6> 
with a character that won't be in the data, then converting it out later.


2. INSERT sometimes doesn't like delimited source. Fix by moving 
POLREC<6> to a variable and inserting that.


3. If POLREC<6> has multivalues itself, that presents a whole different 
problem. Check it first.


All these things can be checked in a little test program in just a few 
minutes, and a safer coding technique used.


Charlie

If this occasional problem is consistently the same lines then just
validate the insert afterwards:

0106.1 MV.CNT = DCOUNT(SUPREC<2>,@VM)
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0107.1 IF SUPREC<2,1> NE POLREC<6> THEN
0107.2MV.CNT2 = DCOUNT(SUPREC<2>,@VM)
0107.3IF MV.CNT = MV.CNT2 THEN GOSUB REPORT.ERROR
0107.4 END

With this logic, you're verifying the value and that a new value is, in
fact, being created in the attribute.  You may want to tweak the logic a
bit to match your exact specifics, like if POLREC<6> is a non-null
value, but this should give you an idea.


Tiny Bear's Wild Bird Store
Home of "Safety Net Shipping"
http://www.TinyBearWildBirdStore.com
Toll Free: 1-855-TinyBear (855-846-9232)

On 07-26-2013 12:13 PM, Tony Gravagno wrote:

From: Woodward, Bob
If this occasional problem is consistently the same lines then just
validate the insert afterwards...

Dale, don't accept that solution. (Sorry Bob)

Note, we're still not really Sure yet that this is a good definition
of the problem, just a working theory...

Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random
lines of code in different systems. The problem might not be something
wrong with the statements themselves but just where they happen to be
in the program. The issues might be fixed with some extra code, or by
putting the few lines in question into an internal subroutine just to
move the bytecode to a different location. But a "solution" like that
is random and subject to just moving the problem to an as yet unknown
and perhaps more critical location.

When you can't trust a line of code to be executed in a linear series
of statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.

It's tough to call in Support when the problem is so vaguely defined
but having "sat in the chair" as a QA Manager and Product Manager for
a related product, I can tell you the resolution starts with finding
sites that seem to have this issue, assigning someone to the task of
gathering data and scheduling tests on the target systems, getting
engineers to verify the issue, and establishing a pattern from which a
problem can be diagnosed.

I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with
Support and committing to follow-through toward a resolution. And
while re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!

HTH
T

___
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] [UD] BASIC Code Failing

[dale kelley]

Tony made a key qualification in his suggestion, "paying customer".  In 
this case, the system has been unupgraded for 7 and unsupported for 6 
years.  (With this exception UniVerse is just so dependable!)  I've 
noticed that hard to track problems just become albatrosses around the 
customer service persons neck and smells worse and worse as the ticket 
ages on their supervisors daily report.   The customer is just a small 
county highway department.  I'm going to do 2 things; put in the 
validation(s) and build a little repair screen that lets them take their 
exception report and correct the "last" info.  This is the first time 
I've even had any plan for it except a log file which has reflected nothing.


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

Re: [U2] [UD] BASIC Code Failing

[Woodward, Bob]

Not a problem, Tony.  I never want someone to just blindly accept a
quick fix.  It would be great if manufacturer's would commit the kind of
resources you mention when I submit an intermittent/can't
replicate/seems to only be on my system type of problem, but my
experience is with this kind of one-off, small potato client's problem,
I'm lucky if I get a first-tier, new to their helpline, fresh out of
training rookie to even give me a call to verify if I knew what I was
saying.

To me, a work-around is far more desirable to try and gather more
information in the error reporting than to leave the situation as is
with nothing to give back to the system owner besides a shoulder shrug.
If the problem changes, this is as good a piece of information as any
that it's most likely not data related and that the problem really does
need the type of resources you mentioned.

As always, Tony, you have very good, valid information that you
generously share with everyone.  We all appreciate that of you.

BobW

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Friday, July 26, 2013 10:13 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] BASIC Code Failing

> From: Woodward, Bob
> If this occasional problem is consistently the same lines then just 
> validate the insert afterwards...

Dale, don't accept that solution. (Sorry Bob)

Note, we're still not really Sure yet that this is a good definition of
the problem, just a working theory...

Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random lines
of code in different systems. The problem might not be something wrong
with the statements themselves but just where they happen to be in the
program. The issues might be fixed with some extra code, or by putting
the few lines in question into an internal subroutine just to move the
bytecode to a different location. But a "solution" like that is random
and subject to just moving the problem to an as yet unknown and perhaps
more critical location.

When you can't trust a line of code to be executed in a linear series of
statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.

It's tough to call in Support when the problem is so vaguely defined but
having "sat in the chair" as a QA Manager and Product Manager for a
related product, I can tell you the resolution starts with finding sites
that seem to have this issue, assigning someone to the task of gathering
data and scheduling tests on the target systems, getting engineers to
verify the issue, and establishing a pattern from which a problem can be
diagnosed.

I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with Support
and committing to follow-through toward a resolution. And while
re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!

HTH
T

___
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] [UD] BASIC Code Failing

[Tony Gravagno]

> From: Woodward, Bob 
> If this occasional problem is consistently the same lines then just
> validate the insert afterwards...

Dale, don't accept that solution. (Sorry Bob)

Note, we're still not really Sure yet that this is a good definition
of the problem, just a working theory...

Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random
lines of code in different systems. The problem might not be something
wrong with the statements themselves but just where they happen to be
in the program. The issues might be fixed with some extra code, or by
putting the few lines in question into an internal subroutine just to
move the bytecode to a different location. But a "solution" like that
is random and subject to just moving the problem to an as yet unknown
and perhaps more critical location.

When you can't trust a line of code to be executed in a linear series
of statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.

It's tough to call in Support when the problem is so vaguely defined
but having "sat in the chair" as a QA Manager and Product Manager for
a related product, I can tell you the resolution starts with finding
sites that seem to have this issue, assigning someone to the task of
gathering data and scheduling tests on the target systems, getting
engineers to verify the issue, and establishing a pattern from which a
problem can be diagnosed.

I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with
Support and committing to follow-through toward a resolution. And
while re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!

HTH
T

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

Re: [U2] [UD] BASIC Code Failing

[David A. Green]

Intermittent data issues can be one of the hardest to debug.  One way that
has helped me out is to create a log file to log the transaction
information, then verify the data and when it is incorrect, send off an
email with the log file key to investigate.

David A. Green
(480) 813-1725
DAG Consulting

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: Friday, July 26, 2013 9:32 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

Thanks Bob,

I'll try that validation, maybe even write SUPREC and read it back for
another validation.  (It's a low intensity system.)  At least that way I
could be telling them rather than them telling me!

dale
___
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] [UD] BASIC Code Failing

[dale kelley]

Thanks Bob,

I'll try that validation, maybe even write SUPREC and read it back for 
another validation.  (It's a low intensity system.)  At least that way I 
could be telling them rather than them telling me!


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

Re: [U2] [UD] BASIC Code Failing

[Woodward, Bob]

If this occasional problem is consistently the same lines then just
validate the insert afterwards:

0106.1 MV.CNT = DCOUNT(SUPREC<2>,@VM)
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0107.1 IF SUPREC<2,1> NE POLREC<6> THEN
0107.2MV.CNT2 = DCOUNT(SUPREC<2>,@VM)
0107.3IF MV.CNT = MV.CNT2 THEN GOSUB REPORT.ERROR
0107.4 END

With this logic, you're verifying the value and that a new value is, in
fact, being created in the attribute.  You may want to tweak the logic a
bit to match your exact specifics, like if POLREC<6> is a non-null
value, but this should give you an idea.

BobW

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: Friday, July 26, 2013 6:42 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

This is all very interesting to hear.  I have a customer who has
occasional instances when they complain that a supply receipt has failed
to update the "last receipt" fields.  This is the code:

0092: 
***
0093: 7000:* UPDATE SUPPLIES
0094: 
***
0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 107
- 110 do not.

My customer refers to it as "the lawnmower man".

dale

___
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] [UD] BASIC Code Failing

[Israel, John R.]

It is worth noting that lines 107 - 110 are all doing an INSERT.  The lines 
before and after do not.

I'm not sure what that may or may not point to, but it is worth noting.  Any 
chance that what they are inserting is the problem (i.e. POLREC and VNDKEY are 
null or something other than what you suspect)?

JRI

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: Friday, July 26, 2013 9:42 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

This is all very interesting to hear.  I have a customer who has occasional 
instances when they complain that a supply receipt has failed to update the 
"last receipt" fields.  This is the code:

0092: 
***
0093: 7000:* UPDATE SUPPLIES
0094: 
***
0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 107
- 110 do not.

My customer refers to it as "the lawnmower man".

dale

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://cp.mcafee.com/d/FZsScz8scCQmhP3P3yb3NKVJ6WarZQrFCzASzt5d-Waq9EVdEThjvKztCVJ6WapEVvpood79Kl8XUz458qmDm56RLzaIundEqmDm56RLzaIundImIejthvW_8IfecnpWZOWtTCujhKUepLORQr8EGTKVOEuvkzaT0QSyrhdTdTdw0PVkDjUCvzPqrp7w0e2qKMM-l9OwXn6QOXtfzgSSCnrFYq5O5mUm-wafBitfyp-fdFJAu00CS7TbCMnWhEwdbojjdbFEwdboj3ziWq81Ag60Qid40Bl3Ph0bX8-k29KVLbCN1DxO_sIf
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[dale kelley]

This is all very interesting to hear.  I have a customer who has 
occasional instances when they complain that a supply receipt has failed 
to update the "last receipt" fields.  This is the code:


0092: 
***

0093: 7000:* UPDATE SUPPLIES
0094: 
***

0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 107 
- 110 do not.


My customer refers to it as "the lawnmower man".

dale

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

Re: [U2] [UD] BASIC Code Failing

[Ed Clark]

don't worry about the color of the suit. It's the hat that matters. I think the 
choices are black, white, and red.

On Jul 25, 2013, at 8:40 PM, Bob Wyatt  wrote:

> We never knew which guys to ask for - the guys in the black suits or the
> white suits?
> 
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
> Sent: Thursday, July 25, 2013 8:36 PM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] [UD] BASIC Code Failing
> 
> Do you have the two-inch lead shielding around your server room to block
> cosmic rays?
> 
> 
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Bob Wyatt 
> To: 'U2 Users List' 
> Sent: Thu, Jul 25, 2013 5:28 pm
> Subject: Re: [U2] [UD] BASIC Code Failing
> 
> 
> I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris.
> I recall seeing and reporting this issue back in UniData 5.something on AIX.
> Both times, support calls were opened.
> Both times, as we had done much of what you have already done, the call was
> closed as No Fault Found because we were unable to reproduce the fault.
> 
> There are also prior reports of this or a similar issue in the archives here
> (to the best of my recollection).
> 
> None of these occurred after an upgrade or update to the system or UniData;
> administratively, the machines had been stagnant for a while.
> 
> Best of luck!
> 
> Regards,
> 
> Bob Wyatt
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
> Sent: Thursday, July 25, 2013 6:11 PM
> To: U2 Users List
> Subject: Re: [U2] [UD] BASIC Code Failing
> 
> As always, thanks G-Man!
> 
> I can't replicate it.  It just comes up every six months (or so) with
> something totally different happening within our application, not to
> everybody, but to someone.  The testing is always the same; test to confirm,
> put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile,
> test to confirm fix, then move on.  In the meantime, hundreds of thousands
> of transactions have taken place with no problems.
> 
> All I can say is; it could be worse!  :-)
> 
> Bill
> 
> ------------
> - Original Message -
> *From:* 3xk547...@sneakemail.com
> *To:* u2-users@listserver.u2ug.org
> *Date:* 7/25/2013 1:04 PM
> *Subject:* Re: [U2] [UD] BASIC Code Failing
>> Bill, at Pick Systems we occasionally saw issues like this, where the 
>> object code would behave differently if specific statements (their
>> opcodes/tokens) were broken across frame boundaries. Until DBMS 
>> patches become available, the problem could be avoided with some 
>> carefully-placed NULL statements. I've seen this with RPL too, for 
>> exactly the same reasons. I know nothing of U2 internals but the 
>> internals are of course similar. Unfortunately without a confirmed 
>> cause/effect scenario defined by engineers, it's a crap shoot as to 
>> whether inserting NULLs will help, or where they can be inserted to 
>> ensure they work.
>> 
>> I suggest you contact Rocket and ask them to pursue this as a 
>> byte-level issue in your object code. Sending them the code might not 
>> help if they test in an environment that's different from your own.
>> They need to see it on your system. I'm just trying to save you some 
>> wasted diagnostic time...
>> 
>> Best,
>> T
>> 
>>> From: Bill Haskett
>>> ... a single BASIC program didn't run a couple of lines of code...
>> ___
>> 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
> 
> ___
> 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] [UD] BASIC Code Failing

[Bob Wyatt]

We never knew which guys to ask for - the guys in the black suits or the
white suits?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Thursday, July 25, 2013 8:36 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] BASIC Code Failing

Do you have the two-inch lead shielding around your server room to block
cosmic rays?


 

 

 

-Original Message-
From: Bob Wyatt 
To: 'U2 Users List' 
Sent: Thu, Jul 25, 2013 5:28 pm
Subject: Re: [U2] [UD] BASIC Code Failing


I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris.
I recall seeing and reporting this issue back in UniData 5.something on AIX.
Both times, support calls were opened.
Both times, as we had done much of what you have already done, the call was
closed as No Fault Found because we were unable to reproduce the fault.

There are also prior reports of this or a similar issue in the archives here
(to the best of my recollection).

None of these occurred after an upgrade or update to the system or UniData;
administratively, the machines had been stagnant for a while.

Best of luck!

Regards,

Bob Wyatt
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, July 25, 2013 6:11 PM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

As always, thanks G-Man!

I can't replicate it.  It just comes up every six months (or so) with
something totally different happening within our application, not to
everybody, but to someone.  The testing is always the same; test to confirm,
put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile,
test to confirm fix, then move on.  In the meantime, hundreds of thousands
of transactions have taken place with no problems.

All I can say is; it could be worse!  :-)

Bill


- Original Message -
*From:* 3xk547...@sneakemail.com
*To:* u2-users@listserver.u2ug.org
*Date:* 7/25/2013 1:04 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> Bill, at Pick Systems we occasionally saw issues like this, where the 
> object code would behave differently if specific statements (their
> opcodes/tokens) were broken across frame boundaries. Until DBMS 
> patches become available, the problem could be avoided with some 
> carefully-placed NULL statements. I've seen this with RPL too, for 
> exactly the same reasons. I know nothing of U2 internals but the 
> internals are of course similar. Unfortunately without a confirmed 
> cause/effect scenario defined by engineers, it's a crap shoot as to 
> whether inserting NULLs will help, or where they can be inserted to 
> ensure they work.
>
> I suggest you contact Rocket and ask them to pursue this as a 
> byte-level issue in your object code. Sending them the code might not 
> help if they test in an environment that's different from your own.
> They need to see it on your system. I'm just trying to save you some 
> wasted diagnostic time...
>
> Best,
> T
>
>> From: Bill Haskett
>> ... a single BASIC program didn't run a couple of lines of code...
> ___
> 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

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

Re: [U2] [UD] BASIC Code Failing

[Wjhonson]

Do you have the two-inch lead shielding around your server room to block cosmic 
rays?


 

 

 

-Original Message-
From: Bob Wyatt 
To: 'U2 Users List' 
Sent: Thu, Jul 25, 2013 5:28 pm
Subject: Re: [U2] [UD] BASIC Code Failing


I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris.
I recall seeing and reporting this issue back in UniData 5.something on AIX.
Both times, support calls were opened.
Both times, as we had done much of what you have already done, the call was
closed as No Fault Found because we were unable to reproduce the fault.

There are also prior reports of this or a similar issue in the archives here
(to the best of my recollection).

None of these occurred after an upgrade or update to the system or UniData;
administratively, the machines had been stagnant for a while.

Best of luck!

Regards,

Bob Wyatt
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, July 25, 2013 6:11 PM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

As always, thanks G-Man!

I can't replicate it.  It just comes up every six months (or so) with
something totally different happening within our application, not to
everybody, but to someone.  The testing is always the same; test to confirm,
put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile,
test to confirm fix, then move on.  In the meantime, hundreds of thousands
of transactions have taken place with no problems.

All I can say is; it could be worse!  :-)

Bill


- Original Message -
*From:* 3xk547...@sneakemail.com
*To:* u2-users@listserver.u2ug.org
*Date:* 7/25/2013 1:04 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> Bill, at Pick Systems we occasionally saw issues like this, where the 
> object code would behave differently if specific statements (their
> opcodes/tokens) were broken across frame boundaries. Until DBMS 
> patches become available, the problem could be avoided with some 
> carefully-placed NULL statements. I've seen this with RPL too, for 
> exactly the same reasons. I know nothing of U2 internals but the 
> internals are of course similar. Unfortunately without a confirmed 
> cause/effect scenario defined by engineers, it's a crap shoot as to 
> whether inserting NULLs will help, or where they can be inserted to 
> ensure they work.
>
> I suggest you contact Rocket and ask them to pursue this as a 
> byte-level issue in your object code. Sending them the code might not 
> help if they test in an environment that's different from your own.
> They need to see it on your system. I'm just trying to save you some 
> wasted diagnostic time...
>
> Best,
> T
>
>> From: Bill Haskett
>> ... a single BASIC program didn't run a couple of lines of code...
> ___
> 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] [UD] BASIC Code Failing

[Bob Wyatt]

I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris.
I recall seeing and reporting this issue back in UniData 5.something on AIX.
Both times, support calls were opened.
Both times, as we had done much of what you have already done, the call was
closed as No Fault Found because we were unable to reproduce the fault.

There are also prior reports of this or a similar issue in the archives here
(to the best of my recollection).

None of these occurred after an upgrade or update to the system or UniData;
administratively, the machines had been stagnant for a while.

Best of luck!

Regards,

Bob Wyatt
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, July 25, 2013 6:11 PM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

As always, thanks G-Man!

I can't replicate it.  It just comes up every six months (or so) with
something totally different happening within our application, not to
everybody, but to someone.  The testing is always the same; test to confirm,
put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile,
test to confirm fix, then move on.  In the meantime, hundreds of thousands
of transactions have taken place with no problems.

All I can say is; it could be worse!  :-)

Bill


- Original Message -
*From:* 3xk547...@sneakemail.com
*To:* u2-users@listserver.u2ug.org
*Date:* 7/25/2013 1:04 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> Bill, at Pick Systems we occasionally saw issues like this, where the 
> object code would behave differently if specific statements (their
> opcodes/tokens) were broken across frame boundaries. Until DBMS 
> patches become available, the problem could be avoided with some 
> carefully-placed NULL statements. I've seen this with RPL too, for 
> exactly the same reasons. I know nothing of U2 internals but the 
> internals are of course similar. Unfortunately without a confirmed 
> cause/effect scenario defined by engineers, it's a crap shoot as to 
> whether inserting NULLs will help, or where they can be inserted to 
> ensure they work.
>
> I suggest you contact Rocket and ask them to pursue this as a 
> byte-level issue in your object code. Sending them the code might not 
> help if they test in an environment that's different from your own.
> They need to see it on your system. I'm just trying to save you some 
> wasted diagnostic time...
>
> Best,
> T
>
>> From: Bill Haskett
>> ... a single BASIC program didn't run a couple of lines of code...
> ___
> 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] [UD] BASIC Code Failing

[Wjhonson]

You can turn off automatic reboots.
 

 

 

-Original Message-
From: Bill Haskett 
To: U2 Users List 
Sent: Thu, Jul 25, 2013 3:11 pm
Subject: Re: [U2] [UD] BASIC Code Failing


Robert:

"...the object code became corrupt due to a system crash."  That sounds 
plausible.  Our systems rarely go down, but they do get rebooted with 
Windows Updates.  UO connections often fail, then get picked up.  Telnet 
often freezes or aborts (mostly client issues) then they log in again.  
Then there's ...

It's always something...and these moron kids think everything works just 
fine (because they haven't lived long enough to see it not work).  :-)

Bill
Untitled Page



- Original Message -
*From:* i...@keyway.net
*To:* U2 Users List 
*Date:* 7/25/2013 1:57 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I just remembered another situation I saw once where a program behaved 
> strangely. When we used the command to verify the object code 
> (BVERIFY?) it didn't verify. A recompile fixed it because the object 
> code became corrupt due to a system crash.
>
> Sometimes you can have the same thing happen, but in the catalog space.
>
> Robert Norman
> ROBERT NORMAN AND ASSOCIATES
> 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
> (951) 541-1668
> i...@keyway.net <mailto:i...@keyway.net>
> http://users.keyway.net/~ice/ <http://users.keyway.net/%7Eice/>
> Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, 
> UniVerse
> Basic, UniBasic, R/BASIC, jBC.
>
> On 7/25/2013 1:36 PM, Woodward, Bob wrote:
>> I agree with Tony.  I once had a program that my fix was just adding a
>> "JUNK = 0" line near the top of the program.  With that do-nothing line
>> the program worked.  Comment the line out or remove it completely and
>> the program seemed to skip lines of code.
>>
>> This was a LONG time ago, though.
>>
>> -Original Message-
>> From: u2-users-boun...@listserver.u2ug.org
>> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
>> Sent: Thursday, July 25, 2013 1:05 PM
>> To: u2-users@listserver.u2ug.org
>> Subject: Re: [U2] [UD] BASIC Code Failing
>>
>> Bill, at Pick Systems we occasionally saw issues like this, where the
>> object code would behave differently if specific statements (their
>> opcodes/tokens) were broken across frame boundaries. Until DBMS patches
>> become available, the problem could be avoided with some
>> carefully-placed NULL statements. I've seen this with RPL too, for
>> exactly the same reasons. I know nothing of U2 internals but the
>> internals are of course similar. Unfortunately without a confirmed
>> cause/effect scenario defined by engineers, it's a crap shoot as to
>> whether inserting NULLs will help, or where they can be inserted to
>> ensure they work.
>>
>> I suggest you contact Rocket and ask them to pursue this as a byte-level
>> issue in your object code. Sending them the code might not help if they
>> test in an environment that's different from your own.
>> They need to see it on your system. I'm just trying to save you some
>> wasted diagnostic time...
>>
>> Best,
>> T
>>
>>> From: Bill Haskett
>>> ... a single BASIC program didn't run a couple of lines of code...
>> ___
>> 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

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

Re: [U2] [UD] BASIC Code Failing

[Bill Haskett]

Robert:

"...the object code became corrupt due to a system crash."  That sounds 
plausible.  Our systems rarely go down, but they do get rebooted with 
Windows Updates.  UO connections often fail, then get picked up.  Telnet 
often freezes or aborts (mostly client issues) then they log in again.  
Then there's ...


It's always something...and these moron kids think everything works just 
fine (because they haven't lived long enough to see it not work).  :-)


Bill
Untitled Page



- Original Message -
*From:* i...@keyway.net
*To:* U2 Users List 
*Date:* 7/25/2013 1:57 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing
I just remembered another situation I saw once where a program behaved 
strangely. When we used the command to verify the object code 
(BVERIFY?) it didn't verify. A recompile fixed it because the object 
code became corrupt due to a system crash.


Sometimes you can have the same thing happen, but in the catalog space.

Robert Norman
ROBERT NORMAN AND ASSOCIATES
23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
(951) 541-1668
i...@keyway.net <mailto:i...@keyway.net>
http://users.keyway.net/~ice/ <http://users.keyway.net/%7Eice/>
Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, 
UniVerse

Basic, UniBasic, R/BASIC, jBC.

On 7/25/2013 1:36 PM, Woodward, Bob wrote:

I agree with Tony.  I once had a program that my fix was just adding a
"JUNK = 0" line near the top of the program.  With that do-nothing line
the program worked.  Comment the line out or remove it completely and
the program seemed to skip lines of code.

This was a LONG time ago, though.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Thursday, July 25, 2013 1:05 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] BASIC Code Failing

Bill, at Pick Systems we occasionally saw issues like this, where the
object code would behave differently if specific statements (their
opcodes/tokens) were broken across frame boundaries. Until DBMS patches
become available, the problem could be avoided with some
carefully-placed NULL statements. I've seen this with RPL too, for
exactly the same reasons. I know nothing of U2 internals but the
internals are of course similar. Unfortunately without a confirmed
cause/effect scenario defined by engineers, it's a crap shoot as to
whether inserting NULLs will help, or where they can be inserted to
ensure they work.

I suggest you contact Rocket and ask them to pursue this as a byte-level
issue in your object code. Sending them the code might not help if they
test in an environment that's different from your own.
They need to see it on your system. I'm just trying to save you some
wasted diagnostic time...

Best,
T


From: Bill Haskett
... a single BASIC program didn't run a couple of lines of code...

___
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] [UD] BASIC Code Failing

[Bill Haskett]

As always, thanks G-Man!

I can't replicate it.  It just comes up every six months (or so) with 
something totally different happening within our application, not to 
everybody, but to someone.  The testing is always the same; test to 
confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, 
recompile, test to confirm fix, then move on.  In the meantime, hundreds 
of thousands of transactions have taken place with no problems.


All I can say is; it could be worse!  :-)

Bill


- Original Message -
*From:* 3xk547...@sneakemail.com
*To:* u2-users@listserver.u2ug.org
*Date:* 7/25/2013 1:04 PM
*Subject:* Re: [U2] [UD] BASIC Code Failing

Bill, at Pick Systems we occasionally saw issues like this, where the
object code would behave differently if specific statements (their
opcodes/tokens) were broken across frame boundaries. Until DBMS
patches become available, the problem could be avoided with some
carefully-placed NULL statements. I've seen this with RPL too, for
exactly the same reasons. I know nothing of U2 internals but the
internals are of course similar. Unfortunately without a confirmed
cause/effect scenario defined by engineers, it's a crap shoot as to
whether inserting NULLs will help, or where they can be inserted to
ensure they work.

I suggest you contact Rocket and ask them to pursue this as a
byte-level issue in your object code. Sending them the code might not
help if they test in an environment that's different from your own.
They need to see it on your system. I'm just trying to save you some
wasted diagnostic time...

Best,
T


From: Bill Haskett
... a single BASIC program didn't run a couple of lines of code...

___
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] [UD] BASIC Code Failing

[Robert]

I just remembered another situation I saw once where a program behaved 
strangely. When we used the command to verify the object code (BVERIFY?) 
it didn't verify. A recompile fixed it because the object code became 
corrupt due to a system crash.


Sometimes you can have the same thing happen, but in the catalog space.

Robert Norman
ROBERT NORMAN AND ASSOCIATES
23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
(951) 541-1668
i...@keyway.net <mailto:i...@keyway.net>
http://users.keyway.net/~ice/ <http://users.keyway.net/%7Eice/>
Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, 
UniVerse

Basic, UniBasic, R/BASIC, jBC.

On 7/25/2013 1:36 PM, Woodward, Bob wrote:

I agree with Tony.  I once had a program that my fix was just adding a
"JUNK = 0" line near the top of the program.  With that do-nothing line
the program worked.  Comment the line out or remove it completely and
the program seemed to skip lines of code.

This was a LONG time ago, though.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Thursday, July 25, 2013 1:05 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] BASIC Code Failing

Bill, at Pick Systems we occasionally saw issues like this, where the
object code would behave differently if specific statements (their
opcodes/tokens) were broken across frame boundaries. Until DBMS patches
become available, the problem could be avoided with some
carefully-placed NULL statements. I've seen this with RPL too, for
exactly the same reasons. I know nothing of U2 internals but the
internals are of course similar. Unfortunately without a confirmed
cause/effect scenario defined by engineers, it's a crap shoot as to
whether inserting NULLs will help, or where they can be inserted to
ensure they work.

I suggest you contact Rocket and ask them to pursue this as a byte-level
issue in your object code. Sending them the code might not help if they
test in an environment that's different from your own.
They need to see it on your system. I'm just trying to save you some
wasted diagnostic time...

Best,
T


From: Bill Haskett
... a single BASIC program didn't run a couple of lines of code...

___
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] [UD] BASIC Code Failing

[Robert]

I have seen this recently with either UNIVERSE or UNIDATA. I don't 
remember which. I have very very rarely seen this happen in 26 years. I 
believe it is a glitch in the compiler or in the RUN command. I was able 
to rewrite the offending part of the program and it would work. I wish I 
had the example handy. The following is not an actual example, but will 
allow you to understand what I did to fix it:


Let's say you found a section of code that behaves strange and you 
confirmed that there is absolutely nothing wrong with it. Here's the 
existing logic:


0001: I=0;VM=CHAR(253);STRING=''
0002: 10*
0003: STRING:=VM
0004: I=I+1
0005: IF I<10 THEN GOTO 10

Simply rewrite and even try restructuring it slightly. For example:

0001: I=0
0002: VM=CHAR(253)
0003: STRING=''
0004: FOR I=1 TO 10
0005:STRING=STRING:VM
0006: NEXT I
0007: *

I think I even had it happen once on one system that failed, I did the 
above and it worked. But at a later point, I put the code back and it 
worked fine. This might actually be a hardware problem in disguise. In 
the old days, there was a program that would write blocks of data to a 
tape. A block of 512 letter As, then a block of 512 letter Bs, etc. Then 
it would rewind and read it back it. If the blocks had anything 
different when they read it in, it would complain that there was a tape 
problem (bad tape, dirty tape heads, bad tape controller card, etc.). It 
might be wise to run an overnight memory test using a diagnostic 
program. I have been able to do in that in the past and detect hard to 
find memory problems. For example, you run the quick memory test and it 
checks out okay. You run it overnight over and over, and it eventually 
finds the intermittent memory problem.Keep in mind that with many 
virtual memory systems (all PICK-type systems are), you are not looking 
at memory chip problems, but hard drive problems. So in some cases, this 
means the hard drive might have a bad spot or intermittent problem.


Please let us know what you find out. Or perhaps post the program for us 
to take a look at and sharpen our skills even more.


Thanks,

Robert Norman
ROBERT NORMAN AND ASSOCIATES
23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
(951) 541-1668
i...@keyway.net 
http://users.keyway.net/~ice/ 
Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, 
UniVerse

Basic, UniBasic, R/BASIC, jBC.

On 7/25/2013 12:25 PM, Bill Haskett wrote:
We've been having an anomaly that has occurred over the past 7 years 
we've been using UniData on Windows.


Yesterday one of the accounts on our ASP server, that contains about 
30 accounts, had a billing issue.  This issue was created because a 
single BASIC program didn't run a couple of lines of code, thus a 
particular type of charge wasn't created for anyone on this account.  
The BASIC code is compiled in an "application" account then cataloged 
locally in each account (a pointer to the program file exists on every 
account).


When I make a copy of this particular account, then run the offending 
program in it, I see the same problem.  When I put a DEBUG statement 
(in the offending program) just above where I suspect the problem 
occurs, recompile then rerun it, there is no problem.  After futzing 
around with placing the DEBUG statement in several different 
locations, with no further issue, I remove the DEBUG statement and 
finally re-compile the offending program. I've changed nothing in the 
program, but it now works.  This particular program runs maybe 250,000 
billings every month with nothing wrong happening.  In fact, I haven't 
seen this problem in this billing program for the past seven years, 
which means that maybe over 20 million transactions have been created 
with no issues.


This happens about once every six months or so on one BASIC program or 
another, where I look at an offending program, see something like five 
lines of code writing to five different files, and the issue is the 
last two lines didn't execute.  When I put a DEBUG into the program 
everything works fine.  When I remove the DEBUG statement and 
recompile everything works fine from then on.


Has anyone else seen this?  Maybe there's something I should do to 
prevent this.


Bill
___
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] [UD] BASIC Code Failing

[Woodward, Bob]

I agree with Tony.  I once had a program that my fix was just adding a
"JUNK = 0" line near the top of the program.  With that do-nothing line
the program worked.  Comment the line out or remove it completely and
the program seemed to skip lines of code.

This was a LONG time ago, though.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Thursday, July 25, 2013 1:05 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] BASIC Code Failing

Bill, at Pick Systems we occasionally saw issues like this, where the
object code would behave differently if specific statements (their
opcodes/tokens) were broken across frame boundaries. Until DBMS patches
become available, the problem could be avoided with some
carefully-placed NULL statements. I've seen this with RPL too, for
exactly the same reasons. I know nothing of U2 internals but the
internals are of course similar. Unfortunately without a confirmed
cause/effect scenario defined by engineers, it's a crap shoot as to
whether inserting NULLs will help, or where they can be inserted to
ensure they work.

I suggest you contact Rocket and ask them to pursue this as a byte-level
issue in your object code. Sending them the code might not help if they
test in an environment that's different from your own.
They need to see it on your system. I'm just trying to save you some
wasted diagnostic time...

Best,
T

> From: Bill Haskett
> ... a single BASIC program didn't run a couple of lines of code...

___
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] [UD] BASIC Code Failing

[Tony Gravagno]

Bill, at Pick Systems we occasionally saw issues like this, where the
object code would behave differently if specific statements (their
opcodes/tokens) were broken across frame boundaries. Until DBMS
patches become available, the problem could be avoided with some
carefully-placed NULL statements. I've seen this with RPL too, for
exactly the same reasons. I know nothing of U2 internals but the
internals are of course similar. Unfortunately without a confirmed
cause/effect scenario defined by engineers, it's a crap shoot as to
whether inserting NULLs will help, or where they can be inserted to
ensure they work.

I suggest you contact Rocket and ask them to pursue this as a
byte-level issue in your object code. Sending them the code might not
help if they test in an environment that's different from your own.
They need to see it on your system. I'm just trying to save you some
wasted diagnostic time...

Best,
T

> From: Bill Haskett 
> ... a single BASIC program didn't run a couple of lines of code...

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

Re: [U2] [UD] BASIC Code Failing

[George Gallen]

It almost sounds like maybe the last time you did a major upgrade and had to 
recompile
Your code, rather than just port it to the new version, something didn't 
compile correctly
Maybe due to a bug, but then you upgraded without having to recompile, and that 
bug
Was fixed and only seems like recompiling fixed it??

Maybe a pre-emptive strike and recompile/catalog all your programs?

George

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, July 25, 2013 3:25 PM
To: U2 Mail List
Subject: [U2] [UD] BASIC Code Failing

We've been having an anomaly that has occurred over the past 7 years 
we've been using UniData on Windows.

Yesterday one of the accounts on our ASP server, that contains about 30 
accounts, had a billing issue.  This issue was created because a single 
BASIC program didn't run a couple of lines of code, thus a particular 
type of charge wasn't created for anyone on this account.  The BASIC 
code is compiled in an "application" account then cataloged locally in 
each account (a pointer to the program file exists on every account).

When I make a copy of this particular account, then run the offending 
program in it, I see the same problem.  When I put a DEBUG statement (in 
the offending program) just above where I suspect the problem occurs, 
recompile then rerun it, there is no problem.  After futzing around with 
placing the DEBUG statement in several different locations, with no 
further issue, I remove the DEBUG statement and finally re-compile the 
offending program.  I've changed nothing in the program, but it now 
works.  This particular program runs maybe 250,000 billings every month 
with nothing wrong happening.  In fact, I haven't seen this problem in 
this billing program for the past seven years, which means that maybe 
over 20 million transactions have been created with no issues.

This happens about once every six months or so on one BASIC program or 
another, where I look at an offending program, see something like five 
lines of code writing to five different files, and the issue is the last 
two lines didn't execute.  When I put a DEBUG into the program 
everything works fine.  When I remove the DEBUG statement and recompile 
everything works fine from then on.

Has anyone else seen this?  Maybe there's something I should do to 
prevent this.

Bill
___
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] [UD] BASIC Code Failing

[Wjhonson]

Put the five into a single transaction.
You will never see the issue again

 

 

 

-Original Message-
From: Bill Haskett 
To: U2 Mail List 
Sent: Thu, Jul 25, 2013 12:25 pm
Subject: [U2] [UD] BASIC Code Failing


We've been having an anomaly that has occurred over the past 7 years 
we've been using UniData on Windows.

Yesterday one of the accounts on our ASP server, that contains about 30 
accounts, had a billing issue.  This issue was created because a single 
BASIC program didn't run a couple of lines of code, thus a particular 
type of charge wasn't created for anyone on this account.  The BASIC 
code is compiled in an "application" account then cataloged locally in 
each account (a pointer to the program file exists on every account).

When I make a copy of this particular account, then run the offending 
program in it, I see the same problem.  When I put a DEBUG statement (in 
the offending program) just above where I suspect the problem occurs, 
recompile then rerun it, there is no problem.  After futzing around with 
placing the DEBUG statement in several different locations, with no 
further issue, I remove the DEBUG statement and finally re-compile the 
offending program.  I've changed nothing in the program, but it now 
works.  This particular program runs maybe 250,000 billings every month 
with nothing wrong happening.  In fact, I haven't seen this problem in 
this billing program for the past seven years, which means that maybe 
over 20 million transactions have been created with no issues.

This happens about once every six months or so on one BASIC program or 
another, where I look at an offending program, see something like five 
lines of code writing to five different files, and the issue is the last 
two lines didn't execute.  When I put a DEBUG into the program 
everything works fine.  When I remove the DEBUG statement and recompile 
everything works fine from then on.

Has anyone else seen this?  Maybe there's something I should do to 
prevent this.

Bill
___
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] UD - Display Current Terminal Type

[Bill Haskett]

Thanks, Martin.

This does the same thing "!echo %TERM%" does, where I noted that my 
SYSTEM(7) variable was "Actwy60" while the results of this Windows 
environment variable was "wyse60".  When I noticed this my thoughts went 
to why?  :-)


Thanks again,

Bill
Untitled Page



- Original Message -
*From:* mbr...@epicor.com
*To:* U2 Users List 
*Date:* 4/24/2013 5:57 AM
*Subject:* Re: [U2] UD - Display Current Terminal Type

Not ECL, but UniBasic and should work in UD on either Unix or NT

X=GETENV("TERM")
PRINT X

vt220




-
Epicor Software (UK) is a limited company registered in England & Wales.
Registration Number: 2338274.   Registered Office:  6th Floor, One London Wall, 
London EC2Y 5EB
This e-mail and any attachments to it are confidential and is for the use of 
the intended recipient(s) only. If you have received this e-mail in error, 
please notify the sender immediately and then delete it. If you are not the 
intended recipient, you must not use, disclose or distribute this e-mail 
without the author's prior permission. We have taken precautions to minimize 
the risk of transmitting software viruses, but we advise you to carry out your 
own virus checks on any attachment to this message. We cannot accept liability 
for any loss or damage caused by software viruses. Any views and/or opinions 
expressed in this e-mail are of the author only and do not represent the views 
of Epicor Software (UK) Limited or any other company within its group.
-

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tom Whitmore
Sent: 24 April 2013 13:23
To: U2 Users List
Subject: Re: [U2] UD - Display Current Terminal Type

Sorry, I thought it was available on both UV and UD.  It is a valid verb on UV:


GET.TERM.TYPE

Wyse Technology 50/60 (W)
Width : 127
Depth : 40

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 9:09 PM
To: U2 Users List
Subject: Re: [U2] UD - Display Current Terminal Type

:GET.TERM.TYPE
Not a verb
   GET.TERM.TYPE
:version

  Module Name Version   Licensed

UniData RDBMS 7.3 Yes
Connection Pooling... 7.3 Yes
Device License... 7.3 Yes
NFA.. 7.3 No
RFS.. 7.3 No
EDA.. 7.3 No
733

Bill
Untitled Page



- Original Message -
*From:* tewhitm...@ratex.com
*To:* U2 Users List 
*Date:* 4/23/2013 5:11 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type

GET.TERM.TYPE will display the terminal type, width and depth.

Tom Whitmore
RATEX Business Solutions

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 5:12 PM
To: U2 Mail List
Subject: [U2] UD - Display Current Terminal Type

I've had a brain-freeze and can't remember how to display the current terminal 
type at ECL.  I know it's SYSTEM(7) but what ECL command do I need to display 
it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill

___
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


Click https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==  to report this 
email as spam.


This message has been scanned for malware by Websense. www.websense.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] UD - Display Current Terminal Type

[Martin Braid]

Not ECL, but UniBasic and should work in UD on either Unix or NT

X=GETENV("TERM")
PRINT X

vt220




-
Epicor Software (UK) is a limited company registered in England & Wales.
Registration Number: 2338274.   Registered Office:  6th Floor, One London Wall, 
London EC2Y 5EB
This e-mail and any attachments to it are confidential and is for the use of 
the intended recipient(s) only. If you have received this e-mail in error, 
please notify the sender immediately and then delete it. If you are not the 
intended recipient, you must not use, disclose or distribute this e-mail 
without the author's prior permission. We have taken precautions to minimize 
the risk of transmitting software viruses, but we advise you to carry out your 
own virus checks on any attachment to this message. We cannot accept liability 
for any loss or damage caused by software viruses. Any views and/or opinions 
expressed in this e-mail are of the author only and do not represent the views 
of Epicor Software (UK) Limited or any other company within its group.
-

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tom Whitmore
Sent: 24 April 2013 13:23
To: U2 Users List
Subject: Re: [U2] UD - Display Current Terminal Type

Sorry, I thought it was available on both UV and UD.  It is a valid verb on UV:

>GET.TERM.TYPE
Wyse Technology 50/60 (W)
Width : 127
Depth : 40

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 9:09 PM
To: U2 Users List
Subject: Re: [U2] UD - Display Current Terminal Type

:GET.TERM.TYPE
Not a verb
  GET.TERM.TYPE
:version

 Module Name Version   Licensed

UniData RDBMS 7.3 Yes
Connection Pooling... 7.3 Yes
Device License... 7.3 Yes
NFA.. 7.3 No
RFS.. 7.3 No
EDA.. 7.3 No
733

Bill
Untitled Page



- Original Message -
*From:* tewhitm...@ratex.com
*To:* U2 Users List 
*Date:* 4/23/2013 5:11 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type
> GET.TERM.TYPE will display the terminal type, width and depth.
>
> Tom Whitmore
> RATEX Business Solutions
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org 
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
> Sent: Tuesday, April 23, 2013 5:12 PM
> To: U2 Mail List
> Subject: [U2] UD - Display Current Terminal Type
>
> I've had a brain-freeze and can't remember how to display the current 
> terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I need 
> to display it?
>
> TERM doesn't work (although I can set it by entering "TERM WYSE60").
> PTERM doesn't work (it gives me all kinds of other things).
>
> Any help would be appreciated.
>
> Bill

___
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


Click https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==  to report this 
email as spam.


This message has been scanned for malware by Websense. www.websense.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] UD - Display Current Terminal Type

[Tom Whitmore]

Sorry, I thought it was available on both UV and UD.  It is a valid verb on UV:

>GET.TERM.TYPE
Wyse Technology 50/60 (W)
Width : 127
Depth : 40

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 9:09 PM
To: U2 Users List
Subject: Re: [U2] UD - Display Current Terminal Type

:GET.TERM.TYPE
Not a verb
  GET.TERM.TYPE
:version

 Module Name Version   Licensed

UniData RDBMS 7.3 Yes
Connection Pooling... 7.3 Yes
Device License... 7.3 Yes
NFA.. 7.3 No
RFS.. 7.3 No
EDA.. 7.3 No
733

Bill
Untitled Page



- Original Message -
*From:* tewhitm...@ratex.com
*To:* U2 Users List 
*Date:* 4/23/2013 5:11 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type
> GET.TERM.TYPE will display the terminal type, width and depth.
>
> Tom Whitmore
> RATEX Business Solutions
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org 
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
> Sent: Tuesday, April 23, 2013 5:12 PM
> To: U2 Mail List
> Subject: [U2] UD - Display Current Terminal Type
>
> I've had a brain-freeze and can't remember how to display the current 
> terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I need 
> to display it?
>
> TERM doesn't work (although I can set it by entering "TERM WYSE60").
> PTERM doesn't work (it gives me all kinds of other things).
>
> Any help would be appreciated.
>
> Bill

___
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] UD - Display Current Terminal Type

[Bill Haskett]

:GET.TERM.TYPE
Not a verb
 GET.TERM.TYPE
:version

Module Name Version   Licensed

UniData RDBMS 7.3 Yes
Connection Pooling... 7.3 Yes
Device License... 7.3 Yes
NFA.. 7.3 No
RFS.. 7.3 No
EDA.. 7.3 No
733

Bill
Untitled Page



- Original Message -
*From:* tewhitm...@ratex.com
*To:* U2 Users List 
*Date:* 4/23/2013 5:11 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type

GET.TERM.TYPE will display the terminal type, width and depth.

Tom Whitmore
RATEX Business Solutions

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 5:12 PM
To: U2 Mail List
Subject: [U2] UD - Display Current Terminal Type

I've had a brain-freeze and can't remember how to display the current terminal 
type at ECL.  I know it's SYSTEM(7) but what ECL command do I need to display 
it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill


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

Re: [U2] UD - Display Current Terminal Type

[Tom Whitmore]

GET.TERM.TYPE will display the terminal type, width and depth.

Tom Whitmore
RATEX Business Solutions

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 5:12 PM
To: U2 Mail List
Subject: [U2] UD - Display Current Terminal Type

I've had a brain-freeze and can't remember how to display the current terminal 
type at ECL.  I know it's SYSTEM(7) but what ECL command do I need to display 
it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill
___
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] UD - Display Current Terminal Type

[Bill Haskett]

Thanks, but that's not it for UniData.

Bill
Untitled Page



- Original Message -
*From:* antli...@youngman.org.uk
*To:* u2-users@listserver.u2ug.org
*Date:* 4/23/2013 3:48 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type

On 23/04/13 22:12, Bill Haskett wrote:

I've had a brain-freeze and can't remember how to display the current
terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I
need to display it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).


Dunno whether it works for UD, but the UV command is GET.TERM.TYPE.

Cheers,
Wol


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

Re: [U2] UD - Display Current Terminal Type

[Wols Lists]

On 23/04/13 22:12, Bill Haskett wrote:
> I've had a brain-freeze and can't remember how to display the current
> terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I
> need to display it?
> 
> TERM doesn't work (although I can set it by entering "TERM WYSE60").
> PTERM doesn't work (it gives me all kinds of other things).
> 
Dunno whether it works for UD, but the UV command is GET.TERM.TYPE.

Cheers,
Wol

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

Re: [U2] UD - Display Current Terminal Type

[Bill Haskett]

Well, that doesn't work, which I tried originally as this is what other 
mvDbms products use (at least what I'm used to).  UniData doesn't 
respond with the terminal type.


4 Dev (0)-> TERM
TERM parameters are all numeric:
TERM A,B,C,D
For the terminal
A=number of characters in a line(132).
B=number of lines per page(42).
For the line printer
C=number of characters in a line(146).
D=number of lines per page(61).
4 Dev (0)->

Bill
Untitled Page



- Original Message -
*From:* bob_woodw...@k2sports.com
*To:* U2 Users List 
*Date:* 4/23/2013 2:48 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type

In Unidata 6.1, TERM with no arguments gives me a brief syntax help
message.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Tuesday, April 23, 2013 2:42 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UD - Display Current Terminal Type

TERM with no arguments will *display* your current settings, at the
bottom of the display it will say 'wyse50'



  

  

  


-Original Message-
From: Bill Haskett 
To: U2 Mail List 
Sent: Tue, Apr 23, 2013 2:11 pm
Subject: [U2] UD - Display Current Terminal Type


I've had a brain-freeze and can't remember how to display the current
terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I
need to display it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill
___
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] UD - Display Current Terminal Type

[Woodward, Bob]

In Unidata 6.1, TERM with no arguments gives me a brief syntax help
message.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Tuesday, April 23, 2013 2:42 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UD - Display Current Terminal Type

TERM with no arguments will *display* your current settings, at the
bottom of the display it will say 'wyse50'



 

 

 

-Original Message-
From: Bill Haskett 
To: U2 Mail List 
Sent: Tue, Apr 23, 2013 2:11 pm
Subject: [U2] UD - Display Current Terminal Type


I've had a brain-freeze and can't remember how to display the current
terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I
need to display it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill
___
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] UD - Display Current Terminal Type

[Wjhonson]

TERM with no arguments will *display* your current settings, at the bottom of 
the display it will say 'wyse50'



 

 

 

-Original Message-
From: Bill Haskett 
To: U2 Mail List 
Sent: Tue, Apr 23, 2013 2:11 pm
Subject: [U2] UD - Display Current Terminal Type


I've had a brain-freeze and can't remember how to display the current 
terminal type at ECL.  I know it's SYSTEM(7) but what ECL command do I 
need to display it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill
___
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] UD - Display Current Terminal Type

[Bill Haskett]

Ahh!

4 Dev (0)-> !echo %TERM%
wyse60

4 Dev (0)-> BPTEST CRT SYSTEM(7) ; END

Compiling Unibasic: SAVEDLISTS\BpTest_516680981 in mode 'p'.
compilation finished
ACTWY60

I ran the command "TERM  ACTWY60" when I logged in.  I wonder why the 
difference?


Thanks,

Bill


- Original Message -
*From:* dda...@harriscomputer.com
*To:* U2 Users List 
*Date:* 4/23/2013 2:19 PM
*Subject:* Re: [U2] UD - Display Current Terminal Type

"!echo $TERM"

perhaps.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 5:12 PM
To: U2 Mail List
Subject: [U2] UD - Display Current Terminal Type

I've had a brain-freeze and can't remember how to display the current terminal 
type at ECL.  I know it's SYSTEM(7) but what ECL command do I need to display 
it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill
___
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.jpg]

[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]<http://www.harriscomputer.com/>
 6110 Enterprise Parkway
Grove City, OH
43123
www.harris-schoolsolutions.com<http://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] UD - Display Current Terminal Type

[Dave Davis]

"!echo $TERM"

perhaps.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Tuesday, April 23, 2013 5:12 PM
To: U2 Mail List
Subject: [U2] UD - Display Current Terminal Type

I've had a brain-freeze and can't remember how to display the current terminal 
type at ECL.  I know it's SYSTEM(7) but what ECL command do I need to display 
it?

TERM doesn't work (although I can set it by entering "TERM WYSE60").
PTERM doesn't work (it gives me all kinds of other things).

Any help would be appreciated.

Bill
___
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.jpg]

[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] [UD] correlative syntax

[Charles Stevenson]

Isn't there a "T" missing?

OCONV(@ID,"G*1"); OCONV(@,"FILE;X;0;0"); @#""
   
   TFILE ?
should be:
OCONV(@ID,"G*1"); OCONV(@,"TFILE;X;0;0"); @#""




another way is to do both correlatives in 1 oconv:

OCONV(@ID,("G*1":@VM:"TFILE;X;0;0"))#""


On 2/28/2013 3:29 PM, bradley.sch...@usbank.com wrote:

A coworker just ran across the following in one of our DICTs. The name of
the item indicates it was written by someone who is no longer with the
organization and was well known for knowing wonderful arcane UniData
tidbits. We can't find anything describing what exactly is going on. The
end result is very useful. I'm wondering if anyone can explain the @#""
bit.


OCONV(@ID,"G*1"); OCONV(@,"FILE;X;0;0"); @#""


The file the DICT is in has a compound key: ACCOUNT.NUMBER*sequential.
What this item does is grab the account number, attempt to read from FILE
and return a 0 if the account doesn't exist in FILE or a 1 if it does.
Pretty nifty.

UD7.1
AIX5.3


TIA,
Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by


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

Re: [U2] [UD] correlative syntax

[bradley . schrag]

d'oh!  That's exactly what it is. I just needed someone to put the space 
between the # and the "".  Thanks.


> 
> I believe this means "if result of last expression is not empty", 
> where "last expression" is oconv(@,"file;x;0;0") in this case.
> 
> Written another way:
> 
> OCONV(OCONV(@ID,"G0*1"),"FILE;X;0;0") # ""
> 

U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

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

Re: [U2] [UD] correlative syntax

[Dave Davis]

I believe this means "if result of last expression is not empty", where "last 
expression" is oconv(@,"file;x;0;0") in this case.

Written another way:

OCONV(OCONV(@ID,"G0*1"),"FILE;X;0;0") # ""

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Thursday, February 28, 2013 4:29 PM
To: 'U2 Users List'
Subject: [U2] [UD] correlative syntax

A coworker just ran across the following in one of our DICTs. The name of the 
item indicates it was written by someone who is no longer with the organization 
and was well known for knowing wonderful arcane UniData tidbits. We can't find 
anything describing what exactly is going on. The end result is very useful. 
I'm wondering if anyone can explain the @#""
bit.


OCONV(@ID,"G*1"); OCONV(@,"FILE;X;0;0"); @#""


The file the DICT is in has a compound key: ACCOUNT.NUMBER*sequential.
What this item does is grab the account number, attempt to read from FILE and 
return a 0 if the account doesn't exist in FILE or a 1 if it does.
Pretty nifty.

UD7.1
AIX5.3


TIA,
Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

___
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.jpg]

[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] [UD] SETPTR

[Bill Haskett]

Doug:

Great eye!  I ran into this after moving to Windows 2008 R2 (which is 64 
bit) back in the summer of 2010.  Fortunately, Wally worked to get this 
fixed in UD v7.2.7.  I've implemented UDT.OPTIONS 116 ON ever since, but 
it wasn't set in our "demo" account on this particular server.  I must 
have moved the demo account from somewhere else.  I knew this was 
familiar but couldn't remember what.


Anyway, thanks very much!  :-)

Bill


- Original Message -
*From:* dave...@u2logic.com
*To:* U2 Users List 
*Date:* 2/2/2013 7:02 AM
*Subject:* Re: [U2] [UD] SETPTR

Hi Bill:

We had this problem a while ago.  You might try setting this UDT option.

UDT.OPTIONS 116 OFF/ON

Regards
Doug
www.u2logic.com
"Applications and tools for U2 shops"

On Fri, Feb 1, 2013 at 7:12 PM, Bill Haskett  wrote:


David:

The ping doesn't respond on either machine.  The printer is "local" on
both dbms servers, not a network printer; although it is "shared".

Bill

--**--**

- Original Message -
*From:* dgr...@dagconsulting.com
*To:* 'U2 Users List' 
*Date:* 2/1/2013 5:54 PM
*Subject:* Re: [U2] [UD] SETPTR

  Bill, sounds like a domain name network issue.  How does a ping to

UDGENERIC
respond?  Maybe you can add the IP address to your host file?

David A. Green
(480) 813-1725
DAG Consulting

-Original Message-
From: 
u2-users-bounces@listserver.**u2ug.org
[mailto:u2-users-bounces@**listserver.u2ug.org]
On Behalf Of Bill Haskett
Sent: Friday, February 01, 2013 6:14 PM
To: U2 Mail List
Subject: [U2] [UD] SETPTR

Does anyone know why UniData (v7.2.12) responds differently to the SETPTR
command between two different machines? I created a local printer, which I
share as "UDGENERIC", that is a generic/text printer to a file.  I did
this
on both machines.

Machine 1 - Windows 2008 R2 fully updated - UniData 77 user Standard
Edition.
:version

   Module Name Version   Licensed

UniData RDBMS 7.2 Yes
Connection Pooling... 7.2 No
Device License... 7.2 No
NFA.. 7.2 No
RFS.. 7.2 No
EDA.. 7.2 No
7212

:SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,**NOHEAD,DEST UDGENERIC

This command takes exactly 60 seconds to return to ECL.

Machine 2 - Windows 2008 R2 fully updated - UniData 24 user Workgroup
Edition.
:version

   Module Name Version   Licensed

UniData RDBMS 7.2 Yes
Connection Pooling... 7.2 Yes
Device License... 7.2 Yes
NFA.. 7.2 No
RFS.. 7.2 No
EDA.. 7.2 No
7212

:SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,**NOHEAD,DEST UDGENERIC

This command returns to ECL immediately.

Both machines are Dell R210 rack-mount servers.  I'm having the
"udt.errlog"
fill up with messages:

Fri Feb 01 18:19:34 pid=2828 In E:\DataTrust\DTA\BP\BP\_RESET.**STANDARDS
at line 33 Fri Feb 01 18:19:34 pid=2828 errno=1801: The printer name is
invalid.
Fri Feb 01 18:19:56 pid=3696 pid=3696,uid=197875,udtno=2:

...which is caused by one of our subroutines, used everywhere in our
application.  This error occurs nowhere else where our application is
installed, because I execute the above SETPTR command within the LOGIN
process at login.  I can't execute it on our 77 user machine because
logging
on will take over a minute!

Any ideas?  Thanks,

Bill Haskett
__**_
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>

__**_
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>


__**_
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>


___
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] [UD] SETPTR

[Doug Averch]

Hi Bill:

We had this problem a while ago.  You might try setting this UDT option.

UDT.OPTIONS 116 OFF/ON

Regards
Doug
www.u2logic.com
"Applications and tools for U2 shops"

On Fri, Feb 1, 2013 at 7:12 PM, Bill Haskett  wrote:

> David:
>
> The ping doesn't respond on either machine.  The printer is "local" on
> both dbms servers, not a network printer; although it is "shared".
>
> Bill
>
> --**--**
> 
> - Original Message -
> *From:* dgr...@dagconsulting.com
> *To:* 'U2 Users List' 
> *Date:* 2/1/2013 5:54 PM
> *Subject:* Re: [U2] [UD] SETPTR
>
>  Bill, sounds like a domain name network issue.  How does a ping to
>> UDGENERIC
>> respond?  Maybe you can add the IP address to your host file?
>>
>> David A. Green
>> (480) 813-1725
>> DAG Consulting
>>
>> -Original Message-
>> From: 
>> u2-users-bounces@listserver.**u2ug.org
>> [mailto:u2-users-bounces@**listserver.u2ug.org]
>> On Behalf Of Bill Haskett
>> Sent: Friday, February 01, 2013 6:14 PM
>> To: U2 Mail List
>> Subject: [U2] [UD] SETPTR
>>
>> Does anyone know why UniData (v7.2.12) responds differently to the SETPTR
>> command between two different machines? I created a local printer, which I
>> share as "UDGENERIC", that is a generic/text printer to a file.  I did
>> this
>> on both machines.
>>
>> Machine 1 - Windows 2008 R2 fully updated - UniData 77 user Standard
>> Edition.
>> :version
>>
>>   Module Name Version   Licensed
>>
>> UniData RDBMS 7.2 Yes
>> Connection Pooling... 7.2 No
>> Device License... 7.2 No
>> NFA.. 7.2 No
>> RFS.. 7.2 No
>> EDA.. 7.2 No
>> 7212
>>
>> :SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,**NOHEAD,DEST UDGENERIC
>>
>> This command takes exactly 60 seconds to return to ECL.
>>
>> Machine 2 - Windows 2008 R2 fully updated - UniData 24 user Workgroup
>> Edition.
>> :version
>>
>>   Module Name Version   Licensed
>>
>> UniData RDBMS 7.2 Yes
>> Connection Pooling... 7.2 Yes
>> Device License... 7.2 Yes
>> NFA.. 7.2 No
>> RFS.. 7.2 No
>> EDA.. 7.2 No
>> 7212
>>
>> :SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,**NOHEAD,DEST UDGENERIC
>>
>> This command returns to ECL immediately.
>>
>> Both machines are Dell R210 rack-mount servers.  I'm having the
>> "udt.errlog"
>> fill up with messages:
>>
>> Fri Feb 01 18:19:34 pid=2828 In E:\DataTrust\DTA\BP\BP\_RESET.**STANDARDS
>> at line 33 Fri Feb 01 18:19:34 pid=2828 errno=1801: The printer name is
>> invalid.
>> Fri Feb 01 18:19:56 pid=3696 pid=3696,uid=197875,udtno=2:
>>
>> ...which is caused by one of our subroutines, used everywhere in our
>> application.  This error occurs nowhere else where our application is
>> installed, because I execute the above SETPTR command within the LOGIN
>> process at login.  I can't execute it on our 77 user machine because
>> logging
>> on will take over a minute!
>>
>> Any ideas?  Thanks,
>>
>> Bill Haskett
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>
>>
>> __**_
>> U2-Users mailing list
>> U2-Users@listserver.u2ug.org
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>
>>
>
> __**_
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] SETPTR

[Bill Haskett]

David:

The ping doesn't respond on either machine.  The printer is "local" on 
both dbms servers, not a network printer; although it is "shared".


Bill


- Original Message -
*From:* dgr...@dagconsulting.com
*To:* 'U2 Users List' 
*Date:* 2/1/2013 5:54 PM
*Subject:* Re: [U2] [UD] SETPTR

Bill, sounds like a domain name network issue.  How does a ping to UDGENERIC
respond?  Maybe you can add the IP address to your host file?

David A. Green
(480) 813-1725
DAG Consulting

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Friday, February 01, 2013 6:14 PM
To: U2 Mail List
Subject: [U2] [UD] SETPTR

Does anyone know why UniData (v7.2.12) responds differently to the SETPTR
command between two different machines? I created a local printer, which I
share as "UDGENERIC", that is a generic/text printer to a file.  I did this
on both machines.

Machine 1 - Windows 2008 R2 fully updated - UniData 77 user Standard
Edition.
:version

  Module Name Version   Licensed

UniData RDBMS 7.2 Yes
Connection Pooling... 7.2 No
Device License... 7.2 No
NFA.. 7.2 No
RFS.. 7.2 No
EDA.. 7.2 No
7212

:SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,NOHEAD,DEST UDGENERIC

This command takes exactly 60 seconds to return to ECL.

Machine 2 - Windows 2008 R2 fully updated - UniData 24 user Workgroup
Edition.
:version

  Module Name Version   Licensed

UniData RDBMS 7.2 Yes
Connection Pooling... 7.2 Yes
Device License... 7.2 Yes
NFA.. 7.2 No
RFS.. 7.2 No
EDA.. 7.2 No
7212

:SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,NOHEAD,DEST UDGENERIC

This command returns to ECL immediately.

Both machines are Dell R210 rack-mount servers.  I'm having the "udt.errlog"
fill up with messages:

Fri Feb 01 18:19:34 pid=2828 In E:\DataTrust\DTA\BP\BP\_RESET.STANDARDS
at line 33 Fri Feb 01 18:19:34 pid=2828 errno=1801: The printer name is
invalid.
Fri Feb 01 18:19:56 pid=3696 pid=3696,uid=197875,udtno=2:

...which is caused by one of our subroutines, used everywhere in our
application.  This error occurs nowhere else where our application is
installed, because I execute the above SETPTR command within the LOGIN
process at login.  I can't execute it on our 77 user machine because logging
on will take over a minute!

Any ideas?  Thanks,

Bill Haskett
___
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] [UD] SETPTR

[David A. Green]

Bill, sounds like a domain name network issue.  How does a ping to UDGENERIC
respond?  Maybe you can add the IP address to your host file?

David A. Green
(480) 813-1725
DAG Consulting

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Friday, February 01, 2013 6:14 PM
To: U2 Mail List
Subject: [U2] [UD] SETPTR

Does anyone know why UniData (v7.2.12) responds differently to the SETPTR
command between two different machines? I created a local printer, which I
share as "UDGENERIC", that is a generic/text printer to a file.  I did this
on both machines.

Machine 1 - Windows 2008 R2 fully updated - UniData 77 user Standard
Edition.
:version

 Module Name Version   Licensed

UniData RDBMS 7.2 Yes
Connection Pooling... 7.2 No
Device License... 7.2 No
NFA.. 7.2 No
RFS.. 7.2 No
EDA.. 7.2 No
7212

:SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,NOHEAD,DEST UDGENERIC

This command takes exactly 60 seconds to return to ECL.

Machine 2 - Windows 2008 R2 fully updated - UniData 24 user Workgroup
Edition.
:version

 Module Name Version   Licensed

UniData RDBMS 7.2 Yes
Connection Pooling... 7.2 Yes
Device License... 7.2 Yes
NFA.. 7.2 No
RFS.. 7.2 No
EDA.. 7.2 No
7212

:SETPTR 0,146,61,0,0,1,BRIEF,NOEJECT,NOHEAD,DEST UDGENERIC

This command returns to ECL immediately.

Both machines are Dell R210 rack-mount servers.  I'm having the "udt.errlog"
fill up with messages:

Fri Feb 01 18:19:34 pid=2828 In E:\DataTrust\DTA\BP\BP\_RESET.STANDARDS
at line 33 Fri Feb 01 18:19:34 pid=2828 errno=1801: The printer name is
invalid.
Fri Feb 01 18:19:56 pid=3696 pid=3696,uid=197875,udtno=2:

...which is caused by one of our subroutines, used everywhere in our
application.  This error occurs nowhere else where our application is
installed, because I execute the above SETPTR command within the LOGIN
process at login.  I can't execute it on our 77 user machine because logging
on will take over a minute!

Any ideas?  Thanks,

Bill Haskett
___
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] [UD] Disabling/blocking ODBC

[Gregor Scott]

I asked Rocket Support about the ODBCLOGIN "feature" availability in UV.

They have confirmed that it does not currently exist in UV.
There is an enhancement request for it (UNV-13746) to be added.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Wednesday, 30 January 2013 11:25 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Hi David

Thanks - this was probably back on version 10.x when I first heard about the 
UniData version so it may have been added since.

Brian



This email and any attachments to it are confidential.
You must not use, disclose or act on the email if you are not the intended
recipient.  Liability limited by a scheme approved under Professional
Standards Legislation.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] Disabling/blocking ODBC

[Brian Leach]

Hi David

Thanks - this was probably back on version 10.x when I first heard about the
UniData version so it may have been added since.

Brian

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 30 January 2013 10:41
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Brian,

*UOLOGIN works for me in UV11.1.9 AIX. What arguments are you specifying?


I haven't got been able to get *ODBCLOGIN to work. I'm speculating if the
arguments the same though - such is the nature of "undocumented" features?

Perhaps they should have *APILOGIN to for all API clients? Plus a new
@-variable that can identify what server-side interface is handling the call
- thus eliminating the need for UOLOGIN and ODBCLOGIN... ?

Cheers,
David

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Tuesday, 29 January 2013 8:05 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Sadly these appear to be UniData only.

Or at least, in the past I've tried with local catalog, global catalog as
*UOLOGIN and global catalog as the (illegal) UOLOGIN. None of these got
fired.

Would be really useful as a central consolidation point for things like
setting DATE.FORMAT.

Brian

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Phil Walker
Sent: 28 January 2013 21:23
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Is this only Unidata or Universe?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Daniel McGrath
Sent: Tuesday, 29 January 2013 9:15 a.m.
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Glad to hear that!

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
bradley.sch...@usbank.com
Sent: Monday, January 28, 2013 12:25 PM
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine 
> that is called for every ODBC call. You can use this to either blank 
> prevent ODBC, or setting up restricted login access & login.
 
Dan, I got the info from our VAR and it works great. Thanks!

Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains
information that is, or may be, covered by electronic communications privacy
laws, and is also confidential and proprietary in nature. If you are not the
intended recipient, please be advised that you are legally prohibited from
retaining, using, copying, distributing, or otherwise disclosing this
information in any manner. Instead, please reply to the sender that you have
received this communication in error, and then immediately delete it. Thank
you in advance for your cooperation.



-

___
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

** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. 
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line. 
**



___
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] [UD] Disabling/blocking ODBC

[Hona, David]

Brian,

*UOLOGIN works for me in UV11.1.9 AIX. What arguments are you specifying?


I haven't got been able to get *ODBCLOGIN to work. I'm speculating if the 
arguments the same though - such is the nature of "undocumented" features?

Perhaps they should have *APILOGIN to for all API clients? Plus a new 
@-variable that can identify what server-side interface is handling the call - 
thus eliminating the need for UOLOGIN and ODBCLOGIN... ?

Cheers,
David

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Tuesday, 29 January 2013 8:05 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Sadly these appear to be UniData only.

Or at least, in the past I've tried with local catalog, global catalog as 
*UOLOGIN and global catalog as the (illegal) UOLOGIN. None of these got fired.

Would be really useful as a central consolidation point for things like setting 
DATE.FORMAT.

Brian

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Phil Walker
Sent: 28 January 2013 21:23
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Is this only Unidata or Universe?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Daniel McGrath
Sent: Tuesday, 29 January 2013 9:15 a.m.
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Glad to hear that!

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Monday, January 28, 2013 12:25 PM
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine 
> that is called for every ODBC call. You can use this to either blank 
> prevent ODBC, or setting up restricted login access & login.
 
Dan, I got the info from our VAR and it works great. Thanks!

Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

___
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

** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains 
information which may be
confidential. 
If you are not the intended recipient please advise the sender by return email, 
do not use or
disclose the contents, and delete the message and any attachments from your 
system. Unless
specifically indicated, this email does not constitute formal advice or 
commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us, please 
reply to this
e-mail by typing Unsubscribe in the subject line. 
**



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

Re: [U2] [UD] Disabling/blocking ODBC

[Brian Leach]

Sadly these appear to be UniData only.

Or at least, in the past I've tried with local catalog, global catalog as
*UOLOGIN and global catalog as the (illegal) UOLOGIN. None of these got
fired.

Would be really useful as a central consolidation point for things like
setting DATE.FORMAT.

Brian

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Phil Walker
Sent: 28 January 2013 21:23
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Is this only Unidata or Universe?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Daniel McGrath
Sent: Tuesday, 29 January 2013 9:15 a.m.
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Glad to hear that!

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
bradley.sch...@usbank.com
Sent: Monday, January 28, 2013 12:25 PM
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine 
> that is called for every ODBC call. You can use this to either blank 
> prevent ODBC, or setting up restricted login access & login.
 
Dan, I got the info from our VAR and it works great. Thanks!

Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains
information that is, or may be, covered by electronic communications privacy
laws, and is also confidential and proprietary in nature. If you are not the
intended recipient, please be advised that you are legally prohibited from
retaining, using, copying, distributing, or otherwise disclosing this
information in any manner. Instead, please reply to the sender that you have
received this communication in error, and then immediately delete it. Thank
you in advance for your cooperation.



-

___
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] [UD] Disabling/blocking ODBC

[Phil Walker]

Is this only Unidata or Universe?

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Daniel McGrath
Sent: Tuesday, 29 January 2013 9:15 a.m.
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

Glad to hear that!

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Monday, January 28, 2013 12:25 PM
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine 
> that is called for every ODBC call. You can use this to either blank 
> prevent ODBC, or setting up restricted login access & login.
 
Dan, I got the info from our VAR and it works great. Thanks!

Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

___
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] [UD] Disabling/blocking ODBC

[John Jenkins]

Don't forget UOLOGIN.

Regards

JayJay


On 28 Jan 2013, at 19:25, bradley.sch...@usbank.com wrote:

>> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine
>> that is called for every ODBC call. You can use this to either blank
>> prevent ODBC, or setting up restricted login access & login.
> 
> Dan, I got the info from our VAR and it works great. Thanks!
> 
> Brad.
> U.S. BANCORP made the following annotations
> -
> Electronic Privacy Notice. This e-mail, and any attachments, contains 
> information that is, or may be, covered by electronic communications privacy 
> laws, and is also confidential and proprietary in nature. If you are not the 
> intended recipient, please be advised that you are legally prohibited from 
> retaining, using, copying, distributing, or otherwise disclosing this 
> information in any manner. Instead, please reply to the sender that you have 
> received this communication in error, and then immediately delete it. Thank 
> you in advance for your cooperation.
> 
> 
> 
> -
> 
> ___
> 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] [UD] Disabling/blocking ODBC

[Daniel McGrath]

Glad to hear that!

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Monday, January 28, 2013 12:25 PM
To: U2 Users List
Subject: Re: [U2] [UD] Disabling/blocking ODBC

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine 
> that is called for every ODBC call. You can use this to either blank 
> prevent ODBC, or setting up restricted login access & login.
 
Dan, I got the info from our VAR and it works great. Thanks!

Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

___
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] [UD] Disabling/blocking ODBC

[bradley . schrag]

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine
> that is called for every ODBC call. You can use this to either blank
> prevent ODBC, or setting up restricted login access & login.
 
Dan, I got the info from our VAR and it works great. Thanks!

Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

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

Re: [U2] [UD] Disabling/blocking ODBC

[Bill Haskett]

Just as an aside, there's also a UOLOGIN global cataloged routine that 
is always called before a UO login (I created it with that name).  It's 
a very handy routine to use to manage connections.


Bill


- Original Message -
*From:* aeger...@pobox.com
*To:* U2 Users List 
*Date:* 1/25/2013 11:23 AM
*Subject:* Re: [U2] [UD] Disabling/blocking ODBC

Dan,

Is this also available in Universe? (Release 10.3.7 for windows)

(Allen - Sent from my paperweight)

On Jan 25, 2013, at 1:49 PM, Daniel McGrath  wrote:


There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine that is called 
for every ODBC call. You can use this to either blank prevent ODBC, or setting up 
restricted login access & login.

If you are under a support contract, contact your support provider and they 
should be able to help you get ODBCLOGIN up and running.

Cheers,

Dan McGrath
Managing Director, U2 Servers Lab
Rocket Software
4600 South Ulster Street  ·  Suite 1100  ·   Denver, CO 80237 ·  USA
T: +1 720 475 8098 · E: dmcgr...@rocketsoftware.com · W: u2.rocketsoftware.com


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Friday, January 25, 2013 11:23 AM
To: 'U2 Users List'
Subject: [U2] [UD] Disabling/blocking ODBC

We may need to figure out a way to disable ODBC access to UniData due to data 
access concerns. I've set up connections before, but have never approached ODBC 
from this perspective. I'm hoping there's a service we can turn off or a port 
we can block. One possible constraint is that we still need to be able to 
connect to UniData via DataStage. We use the native unidata connector, so I'm 
hoping that won't get in the way. Thoughts?

UniData 7.1
AIX 5.3


TIA,
Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



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

Re: [U2] [UD] Disabling/blocking ODBC

[Allen Egerton]

Dan,

Is this also available in Universe? (Release 10.3.7 for windows)

(Allen - Sent from my paperweight)

On Jan 25, 2013, at 1:49 PM, Daniel McGrath  wrote:

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine that is 
> called for every ODBC call. You can use this to either blank prevent ODBC, or 
> setting up restricted login access & login.
> 
> If you are under a support contract, contact your support provider and they 
> should be able to help you get ODBCLOGIN up and running.
> 
> Cheers,
> 
> Dan McGrath
> Managing Director, U2 Servers Lab
> Rocket Software
> 4600 South Ulster Street  ·  Suite 1100  ·   Denver, CO 80237 ·  USA
> T: +1 720 475 8098 · E: dmcgr...@rocketsoftware.com · W: u2.rocketsoftware.com
> 
> 
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org 
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
> bradley.sch...@usbank.com
> Sent: Friday, January 25, 2013 11:23 AM
> To: 'U2 Users List'
> Subject: [U2] [UD] Disabling/blocking ODBC
> 
> We may need to figure out a way to disable ODBC access to UniData due to data 
> access concerns. I've set up connections before, but have never approached 
> ODBC from this perspective. I'm hoping there's a service we can turn off or a 
> port we can block. One possible constraint is that we still need to be able 
> to connect to UniData via DataStage. We use the native unidata connector, so 
> I'm hoping that won't get in the way. Thoughts?
> 
> UniData 7.1
> AIX 5.3
> 
> 
> TIA,
> Brad.
> U.S. BANCORP made the following annotations
> -
> Electronic Privacy Notice. This e-mail, and any attachments, contains 
> information that is, or may be, covered by electronic communications privacy 
> laws, and is also confidential and proprietary in nature. If you are not the 
> intended recipient, please be advised that you are legally prohibited from 
> retaining, using, copying, distributing, or otherwise disclosing this 
> information in any manner. Instead, please reply to the sender that you have 
> received this communication in error, and then immediately delete it. Thank 
> you in advance for your cooperation.
> 
> 
> 
> -
> 
> ___
> 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] [UD] Disabling/blocking ODBC

[Allen Egerton]

(Allen - Sent from my paperweight)

On Jan 25, 2013, at 1:49 PM, Daniel McGrath  wrote:

> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine that is 
> called for every ODBC call. You can use this to either blank prevent ODBC, or 
> setting up restricted login access & login.
> 
> If you are under a support contract, contact your support provider and they 
> should be able to help you get ODBCLOGIN up and running.
> 
> Cheers,
> 
> Dan McGrath
> Managing Director, U2 Servers Lab
> Rocket Software
> 4600 South Ulster Street  ·  Suite 1100  ·   Denver, CO 80237 ·  USA
> T: +1 720 475 8098 · E: dmcgr...@rocketsoftware.com · W: u2.rocketsoftware.com
> 
> 
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org 
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
> bradley.sch...@usbank.com
> Sent: Friday, January 25, 2013 11:23 AM
> To: 'U2 Users List'
> Subject: [U2] [UD] Disabling/blocking ODBC
> 
> We may need to figure out a way to disable ODBC access to UniData due to data 
> access concerns. I've set up connections before, but have never approached 
> ODBC from this perspective. I'm hoping there's a service we can turn off or a 
> port we can block. One possible constraint is that we still need to be able 
> to connect to UniData via DataStage. We use the native unidata connector, so 
> I'm hoping that won't get in the way. Thoughts?
> 
> UniData 7.1
> AIX 5.3
> 
> 
> TIA,
> Brad.
> U.S. BANCORP made the following annotations
> -
> Electronic Privacy Notice. This e-mail, and any attachments, contains 
> information that is, or may be, covered by electronic communications privacy 
> laws, and is also confidential and proprietary in nature. If you are not the 
> intended recipient, please be advised that you are legally prohibited from 
> retaining, using, copying, distributing, or otherwise disclosing this 
> information in any manner. Instead, please reply to the sender that you have 
> received this communication in error, and then immediately delete it. Thank 
> you in advance for your cooperation.
> 
> 
> 
> -
> 
> ___
> 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] [UD] Disabling/blocking ODBC

[Dan Fitzgerald]

You could take out the path(s) to the Unidata accounts in the UCI file; I don't 
know if that would affect datastage, but it might be worth checking.
 
> Date: Fri, 25 Jan 2013 11:40:42 -0700
> From: jscha...@gmail.com
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] [UD] Disabling/blocking ODBC
> 
> I believe both Universe and Unidata run ODBC via the standard UniRPC 
> port 31438 unless you are running UniRPC on a different port.
> 
> bradley.sch...@usbank.com wrote:
> > We may need to figure out a way to disable ODBC access to UniData due to 
> > data access concerns. I've set up connections before, but have never 
> > approached ODBC from this perspective. I'm hoping there's a service we can 
> > turn off or a port we can block. One possible constraint is that we still 
> > need to be able to connect to UniData via DataStage. We use the native 
> > unidata connector, so I'm hoping that won't get in the way. Thoughts?
> >
> > UniData 7.1
> > AIX 5.3
> >
> >
> > TIA,
> > Brad.
> > U.S. BANCORP made the following annotations
> > -
> > Electronic Privacy Notice. This e-mail, and any attachments, contains 
> > information that is, or may be, covered by electronic communications 
> > privacy laws, and is also confidential and proprietary in nature. If you 
> > are not the intended recipient, please be advised that you are legally 
> > prohibited from retaining, using, copying, distributing, or otherwise 
> > disclosing this information in any manner. Instead, please reply to the 
> > sender that you have received this communication in error, and then 
> > immediately delete it. Thank you in advance for your cooperation.
> >
> >
> >
> > -
> >
> > ___
> > 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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] Disabling/blocking ODBC

[bradley . schrag]

This sounds very promising. I will pursue this route. Thanks, Dan.

> From: Daniel McGrath 
> To: U2 Users List , 
> Date: 01/25/2013 12:49 PM
> Subject: Re: [U2] [UD] Disabling/blocking ODBC
> Sent by: u2-users-boun...@listserver.u2ug.org
> 
> There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine
> that is called for every ODBC call. You can use this to either blank
> prevent ODBC, or setting up restricted login access & login.
> 
> If you are under a support contract, contact your support provider 
> and they should be able to help you get ODBCLOGIN up and running.
> 
> Cheers,
> 
> Dan McGrath

U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

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

Re: [U2] [UD] Disabling/blocking ODBC

[bradley . schrag]

> You can can kill the unirpc process ?

That would do it. Unfortunately, it would also take down UO and UOJ, which 
we use. Hmmm.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

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

Re: [U2] [UD] Disabling/blocking ODBC

[Daniel McGrath]

There is an undocumented feature: ' ODBCLOGIN'. This is a subroutine that is 
called for every ODBC call. You can use this to either blank prevent ODBC, or 
setting up restricted login access & login.

If you are under a support contract, contact your support provider and they 
should be able to help you get ODBCLOGIN up and running.

Cheers,

Dan McGrath
Managing Director, U2 Servers Lab
Rocket Software
4600 South Ulster Street  ·  Suite 1100  ·   Denver, CO 80237 ·  USA
T: +1 720 475 8098 · E: dmcgr...@rocketsoftware.com · W: u2.rocketsoftware.com


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Friday, January 25, 2013 11:23 AM
To: 'U2 Users List'
Subject: [U2] [UD] Disabling/blocking ODBC

We may need to figure out a way to disable ODBC access to UniData due to data 
access concerns. I've set up connections before, but have never approached ODBC 
from this perspective. I'm hoping there's a service we can turn off or a port 
we can block. One possible constraint is that we still need to be able to 
connect to UniData via DataStage. We use the native unidata connector, so I'm 
hoping that won't get in the way. Thoughts?

UniData 7.1
AIX 5.3


TIA,
Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

___
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] [UD] Disabling/blocking ODBC

[Wjhonson]

You can can kill the unirpc process ?


 

 

 

-Original Message-
From: Jeff Schasny 
To: U2 Users List 
Sent: Fri, Jan 25, 2013 10:41 am
Subject: Re: [U2] [UD] Disabling/blocking ODBC


I believe both Universe and Unidata run ODBC via the standard UniRPC 
port 31438 unless you are running UniRPC on a different port.

bradley.sch...@usbank.com wrote:
> We may need to figure out a way to disable ODBC access to UniData due to 
> data access concerns. I've set up connections before, but have never 
> approached ODBC from this perspective. I'm hoping there's a service we can 
> turn off or a port we can block. One possible constraint is that we still 
> need to be able to connect to UniData via DataStage. We use the native 
> unidata connector, so I'm hoping that won't get in the way. Thoughts?
>
> UniData 7.1
> AIX 5.3
>
>
> TIA,
> Brad.
> U.S. BANCORP made the following annotations
> -
> Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.
>
>
>
> -
>
> ___
> 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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] Disabling/blocking ODBC

[Jeff Schasny]

I believe both Universe and Unidata run ODBC via the standard UniRPC 
port 31438 unless you are running UniRPC on a different port.


bradley.sch...@usbank.com wrote:
We may need to figure out a way to disable ODBC access to UniData due to 
data access concerns. I've set up connections before, but have never 
approached ODBC from this perspective. I'm hoping there's a service we can 
turn off or a port we can block. One possible constraint is that we still 
need to be able to connect to UniData via DataStage. We use the native 
unidata connector, so I'm hoping that won't get in the way. Thoughts?


UniData 7.1
AIX 5.3


TIA,
Brad.
U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-

___
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] [UD] Select - Suppress "...IDs do not exist:" Message

[Bill Haskett]

David:

I could probably do a jig too, but I'd probably hurt myself.  :-)

Bill


- Original Message -
*From:* dgr...@dagconsulting.com
*To:* 'U2 Users List' 
*Date:* 11/30/2012 12:24 PM
*Subject:* Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

You can always turn it on and off inside your program or paragraph.

David A. Green
(480) 813-1725
DAG Consulting


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Friday, November 30, 2012 1:16 PM
To: U2 Users List
Subject: Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

Wally:

Global, eh?  Ouch!  I was hoping to find a keyword like "NE.SUPP", kind of
like "NI.SUPP".

Anyway, this'll do for the time being.  Many thanks for your Christmas
spirit!  :-)

Bill
Untitled Page



- Original Message -
*From:* wterh...@rocketsoftware.com
*To:* U2 Users List 
*Date:* 11/30/2012 12:00 PM
*Subject:* Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

I think you are looking for UDT.OPTIONS 55

Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w:
u2.rocketsoftware.com


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill
Haskett
Sent: Friday, November 30, 2012 12:43 PM
To: U2 Mail List
Subject: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

Does anyone know what the keyword is to suppress the "The following record

ids do not exist:" message when items in a select list are not in the target
file being selected?

Thanks,

Bill Haskett


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

Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

[David A. Green]

You can always turn it on and off inside your program or paragraph.

David A. Green
(480) 813-1725
DAG Consulting


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Friday, November 30, 2012 1:16 PM
To: U2 Users List
Subject: Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

Wally:

Global, eh?  Ouch!  I was hoping to find a keyword like "NE.SUPP", kind of
like "NI.SUPP".

Anyway, this'll do for the time being.  Many thanks for your Christmas
spirit!  :-)

Bill
Untitled Page



- Original Message -
*From:* wterh...@rocketsoftware.com
*To:* U2 Users List 
*Date:* 11/30/2012 12:00 PM
*Subject:* Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message
> I think you are looking for UDT.OPTIONS 55
>
> Wally Terhune
> Technical Support Engineer
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: 
> u2.rocketsoftware.com
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org 
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill 
> Haskett
> Sent: Friday, November 30, 2012 12:43 PM
> To: U2 Mail List
> Subject: [U2] [UD] Select - Suppress "...IDs do not exist:" Message
>
> Does anyone know what the keyword is to suppress the "The following record
ids do not exist:" message when items in a select list are not in the target
file being selected?
>
> Thanks,
>
> Bill Haskett
> ___
> 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] [UD] Select - Suppress "...IDs do not exist:" Message

[Bill Haskett]

Wally:

Global, eh?  Ouch!  I was hoping to find a keyword like "NE.SUPP", kind 
of like "NI.SUPP".


Anyway, this'll do for the time being.  Many thanks for your Christmas 
spirit!  :-)


Bill
Untitled Page



- Original Message -
*From:* wterh...@rocketsoftware.com
*To:* U2 Users List 
*Date:* 11/30/2012 12:00 PM
*Subject:* Re: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

I think you are looking for UDT.OPTIONS 55

Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: u2.rocketsoftware.com


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Friday, November 30, 2012 12:43 PM
To: U2 Mail List
Subject: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

Does anyone know what the keyword is to suppress the "The following record ids do 
not exist:" message when items in a select list are not in the target file being 
selected?

Thanks,

Bill Haskett
___
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] [UD] Select - Suppress "...IDs do not exist:" Message

[Wally Terhune]

I think you are looking for UDT.OPTIONS 55

Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: u2.rocketsoftware.com


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Friday, November 30, 2012 12:43 PM
To: U2 Mail List
Subject: [U2] [UD] Select - Suppress "...IDs do not exist:" Message

Does anyone know what the keyword is to suppress the "The following record ids 
do not exist:" message when items in a select list are not in the target file 
being selected?

Thanks,

Bill Haskett
___
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] [UD] Pause When Executing Query

[Bill Haskett]

Dan:

Thanks for your thoughts.  We're using UD v7.3.3 on Windows 2008 R2 
servers and IIS v7.5.  I also seem to have noticed a slowness with our 
UO connections too.  These aren't phantom processes but telnet (and 
UO).  UO is significantly slower.  I tested this on both UD v7.2.12 and 
UD v7.3.0 and don't seem to see any of this.


I don't see any settings for PHANTOM_WAIT in the UD configurations.  
This is pretty aggravating in that everything has slowed down 
dramatically.  (I hate upgrading!)


Thanks again,

Bill


- Original Message -
*From:* dan.go...@interlinebrands.com
*To:* U2 Users List 
*Date:* 11/13/2012 7:58 AM
*Subject:* Re: [U2] [UD] Pause When Executing Query

I found this in the Unidata 7.3.0 release notes that I was reviewing earlier  
... HTH

UDT-4176 - Problem Description

UniData -- On UniData for UNIX only, when the EXECUTE "PHANTOM process"
CAPTURING OUTPUT statement was executed, there was a hard 2 second delay to
make sure that the information about the newly spawned PROCESS, including the
pid and como filename, was included in the CAPTURING output. An environment
variable, PHANTOM_WAIT, could be set to 1 or more seconds to control the
delay. If you set the value to 0, the setting had no effect.

Beginning at UniData 7.3, you can now set the PHANTOM_WAIT value to 0 so no
delay will occur.




Dan Goble | Senior Systems Engineer

Interline Brands, Inc.
804 East Gate Drive Suite 100, Mount Laurel, NJ 08054
Office: 856.533.3110 | Mobile: 609.792.6855
E-mail: dan.go...@interlinebrands.com | Website: www.interlinebrands.com


This e-mail and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed.  Please notify 
the sender immediately by e-mail if you have received this e-mail in error and 
delete all copies of this message.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble
Sent: Tuesday, November 13, 2012 10:50 AM
To: U2 Users List
Subject: Re: [U2] [UD] Pause When Executing Query

We have been using Unidata 7.2.12 for about a year and have not come across 
that issue.My first question would be what OS are you using.   We are using 
AIX 6.1.

-Dan


Dan Goble | Senior Systems Engineer

Interline Brands, Inc.
804 East Gate Drive Suite 100, Mount Laurel, NJ 08054
Office: 856.533.3110 | Mobile: 609.792.6855
E-mail: dan.go...@interlinebrands.com | Website: www.interlinebrands.com


This e-mail and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed.  Please notify 
the sender immediately by e-mail if you have received this e-mail in error and 
delete all copies of this message.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, November 12, 2012 11:33 PM
To: U2 Mail List
Subject: Re: [U2] [UD] Pause When Executing Query

Actually, it's fine on UD v7.2.12 and v7.3.0.  I have the persistent pause on 
v7.3.2.

Bill
Untitled Page



- Original Message -
*From:* wphask...@advantos.net
*To:* U2 Mail List 
*Date:* 11/12/2012 7:51 PM
*Subject:* [UD] Pause When Executing Query

Our application is full of various selects to get data to parse to
display in a window of our character-based interface.  We mostly use a
standard subroutine that does this, but a couple of our programs
don't.  We've been doing this for about the last 20 years.

Since we've upgrade to UD v7.3, however, we've noticed about a 1
second pause before the sub-window displays.  They have always
displayed almost immediately.  I've been using UD for the past six
years, or so, and there's never been such a problem, until v 7.3. I've
been having various problems with v7.3 over the past six months or so,
but wonder if anyone else is experiencing such delays.

Thanks,

Bill

___
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] [UD] Pause When Executing Query

[Dan Goble]

I found this in the Unidata 7.3.0 release notes that I was reviewing earlier  
... HTH

UDT-4176 - Problem Description

UniData -- On UniData for UNIX only, when the EXECUTE "PHANTOM process"
CAPTURING OUTPUT statement was executed, there was a hard 2 second delay to
make sure that the information about the newly spawned PROCESS, including the
pid and como filename, was included in the CAPTURING output. An environment
variable, PHANTOM_WAIT, could be set to 1 or more seconds to control the
delay. If you set the value to 0, the setting had no effect.

Beginning at UniData 7.3, you can now set the PHANTOM_WAIT value to 0 so no
delay will occur.




Dan Goble | Senior Systems Engineer

Interline Brands, Inc.
804 East Gate Drive Suite 100, Mount Laurel, NJ 08054
Office: 856.533.3110 | Mobile: 609.792.6855
E-mail: dan.go...@interlinebrands.com | Website: www.interlinebrands.com


This e-mail and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed.  Please notify 
the sender immediately by e-mail if you have received this e-mail in error and 
delete all copies of this message.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble
Sent: Tuesday, November 13, 2012 10:50 AM
To: U2 Users List
Subject: Re: [U2] [UD] Pause When Executing Query

We have been using Unidata 7.2.12 for about a year and have not come across 
that issue.My first question would be what OS are you using.   We are using 
AIX 6.1.

-Dan


Dan Goble | Senior Systems Engineer

Interline Brands, Inc.
804 East Gate Drive Suite 100, Mount Laurel, NJ 08054
Office: 856.533.3110 | Mobile: 609.792.6855
E-mail: dan.go...@interlinebrands.com | Website: www.interlinebrands.com


This e-mail and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed.  Please notify 
the sender immediately by e-mail if you have received this e-mail in error and 
delete all copies of this message.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, November 12, 2012 11:33 PM
To: U2 Mail List
Subject: Re: [U2] [UD] Pause When Executing Query

Actually, it's fine on UD v7.2.12 and v7.3.0.  I have the persistent pause on 
v7.3.2.

Bill
Untitled Page



- Original Message -
*From:* wphask...@advantos.net
*To:* U2 Mail List 
*Date:* 11/12/2012 7:51 PM
*Subject:* [UD] Pause When Executing Query
> Our application is full of various selects to get data to parse to
> display in a window of our character-based interface.  We mostly use a
> standard subroutine that does this, but a couple of our programs
> don't.  We've been doing this for about the last 20 years.
>
> Since we've upgrade to UD v7.3, however, we've noticed about a 1
> second pause before the sub-window displays.  They have always
> displayed almost immediately.  I've been using UD for the past six
> years, or so, and there's never been such a problem, until v 7.3. I've
> been having various problems with v7.3 over the past six months or so,
> but wonder if anyone else is experiencing such delays.
>
> Thanks,
>
> Bill

___
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] [UD] Pause When Executing Query

[Dan Goble]

We have been using Unidata 7.2.12 for about a year and have not come across 
that issue.My first question would be what OS are you using.   We are using 
AIX 6.1.

-Dan


Dan Goble | Senior Systems Engineer

Interline Brands, Inc.
804 East Gate Drive Suite 100, Mount Laurel, NJ 08054
Office: 856.533.3110 | Mobile: 609.792.6855
E-mail: dan.go...@interlinebrands.com | Website: www.interlinebrands.com


This e-mail and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed.  Please notify 
the sender immediately by e-mail if you have received this e-mail in error and 
delete all copies of this message.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, November 12, 2012 11:33 PM
To: U2 Mail List
Subject: Re: [U2] [UD] Pause When Executing Query

Actually, it's fine on UD v7.2.12 and v7.3.0.  I have the persistent pause on 
v7.3.2.

Bill
Untitled Page



- Original Message -
*From:* wphask...@advantos.net
*To:* U2 Mail List 
*Date:* 11/12/2012 7:51 PM
*Subject:* [UD] Pause When Executing Query
> Our application is full of various selects to get data to parse to
> display in a window of our character-based interface.  We mostly use a
> standard subroutine that does this, but a couple of our programs
> don't.  We've been doing this for about the last 20 years.
>
> Since we've upgrade to UD v7.3, however, we've noticed about a 1
> second pause before the sub-window displays.  They have always
> displayed almost immediately.  I've been using UD for the past six
> years, or so, and there's never been such a problem, until v 7.3. I've
> been having various problems with v7.3 over the past six months or so,
> but wonder if anyone else is experiencing such delays.
>
> Thanks,
>
> Bill

___
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] [UD] Pause When Executing Query

[Bill Haskett]

Actually, it's fine on UD v7.2.12 and v7.3.0.  I have the persistent 
pause on v7.3.2.


Bill
Untitled Page



- Original Message -
*From:* wphask...@advantos.net
*To:* U2 Mail List 
*Date:* 11/12/2012 7:51 PM
*Subject:* [UD] Pause When Executing Query
Our application is full of various selects to get data to parse to 
display in a window of our character-based interface.  We mostly use a 
standard subroutine that does this, but a couple of our programs 
don't.  We've been doing this for about the last 20 years.


Since we've upgrade to UD v7.3, however, we've noticed about a 1 
second pause before the sub-window displays.  They have always 
displayed almost immediately.  I've been using UD for the past six 
years, or so, and there's never been such a problem, until v 7.3. I've 
been having various problems with v7.3 over the past six months or so, 
but wonder if anyone else is experiencing such delays.


Thanks,

Bill 


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

Re: [U2] [UD] Multi-Level Files

[Bill Haskett]

Thanks Brett.

It turns out that UD works this way.  The solution was to also pass in 
@RECORD.  Even though @ID passed in the wrong ID, @RECORD passed in the 
correct VOC item.  So, I was able to read attribute #2 (the data file 
path) then proceed from there.  In addition, if this was an "LF" file 
then I parsed through the dictionary to find the data files, then got 
each data file's information.  Passing back as an MV comes out just 
fine.  So a query can look like:


2 Dev (0)-> LIST VOC 'APOPEN''APPO' F_DATA F_SIZE
LIST VOC 'APOPEN''APPO' F_DATA F_SIZE 09:12:59 Nov 07 2012 1
VOC... Data Location FileInfo..

APOPEN APOPEN  31,4
   HISTORY   1999,4
   HOLD 5,1
APPO   APPO11,1
2 records listed

Although this doesn't work well for multi-level files in other accounts, 
especially using environment variables for the path, it worked for my 
purposes here.


Bill
Untitled Page



- Original Message -
*From:* bre...@gpmdev.co.uk
*To:* u2-users@listserver.u2ug.org 
*Date:* 11/7/2012 8:51 AM
*Subject:* Re: [U2] [UD] Multi-Level Files

Am not sure why you would be getting the last hashed dictionary item passed.

However, I think you would need to pass something other than @ID to your subroutine - a 
multivalue of files via another I descriptor with subroutine.  Don't know about in UniData but in 
UniVerse VOC<4> has M and <7> an mv of data sections.  The file to open is 
/APOPEN/HISTORY for instance.

As an alternative you could try using a Q pointer to each data section.

HTH

Brett

"Bill Haskett"  wrote in message 
news:<5095a055.8090...@advantos.net>...

I build the following subroutine to be used by a dictionary.

SUBROUTINE D.GETFILEINFO ( Value, atID )
*
** Get information on file using FILEINFO()
*
** Initialize local variables
SP1   = ' '
NULL$ = ''
*
** Assign passed variables
Value= NULL$ ; ** initialize return variable
FileName = atID  ; ** the name of the file (key)
*
** Open the file and get the file information to pass back
OPEN '', FileName TO FileName.FV THEN
 Modulo= FILEINFO(FileName.FV, 5)
 BlockSize = FILEINFO(FileName.FV, 8)
 BlockCode = INT(BlockSize / 1024)
 Value = Modulo : ',' : BlockCode
 CLOSE FileName.FV
END ELSE
 Value = NULL$
END
*
RETURN
END

I use this program in a dictionary item called "F_SIZE".

3 Dev (0)-> AE VOC F_SIZE
Top of "F_SIZE" in "VOC", 6 lines, 95 characters.
*--: P
001: I Return the file information on the defined size
002: SUBR ( "D.GETFILEINFO", @ID )
003:
004: FileInfo
005: 10R
006: S
Bottom.

...which returns the size of the file.  When I use this on a multi-level
file it fails to return the file size.  e.g.

3 Dev (0)-> LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE
LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE 14:50:50 Nov 03 2012 1
VOC... Data Location FileInfo..

APOPEN APOPEN
HISTORY
HOLD
APPO   APPO11,1
2 records listed

It works fine on regular files.  I tracked the problem down to UniData
doesn't pass in the name of the file to the called subroutine, @ID
doesn't work.  What is passed is the last hashed dictionary item of the
APOPEN dictionary file.  When I put a "CRT" statement in the program
code just below where the "FileName" variable is assigned...

CRT FileName

...the list output looks like this:

3 Dev (0)-> LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE
*BALANCE*
LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE 14:50:50 Nov 03 2012 1
VOC... Data Location FileInfo..

APOPEN APOPEN
 HISTORY
 HOLD
*APPO*
APPO APPO11,1
2 records listed

I discovered this because I listed the dictionary of the APOPEN file;
which looks like:

3 Dev (0)-> LIST DICT APOPEN NOPAGE
LIST DICT APOPEN NOPAGE 14:51:11 Nov 03 2012 1
Dict Name..

ACCT_F
REP
TEST2
@UQ
ACCT_L
.
CHECK_ID
@HOLD
@APOPEN
VNAME20
.
APPROVED
@ID
AS_LKS
.
BNAME
CBALANCE
ACCTS_VCNT
ACCT_CNT
AMTS1
APMY
*BALANCE*
99 records listed

...and "BALANCE", which UD passes into the subroutine, happens to be the
last dictionary item hashed into the APOPEN dictionary file.  Any idea
why this is the case, or is this some kind of feature.
--
Untitled Page

Bill Haskett


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

Re: [U2] [UD] Multi-Level Files

[Brett Callacher]

Am not sure why you would be getting the last hashed dictionary item passed.

However, I think you would need to pass something other than @ID to your 
subroutine - a multivalue of files via another I descriptor with subroutine.  
Don't know about in UniData but in UniVerse VOC<4> has M and <7> an mv of data 
sections.  The file to open is /APOPEN/HISTORY for instance.

As an alternative you could try using a Q pointer to each data section.

HTH

Brett

"Bill Haskett"  wrote in message 
news:<5095a055.8090...@advantos.net>...
> I build the following subroutine to be used by a dictionary.
> 
> SUBROUTINE D.GETFILEINFO ( Value, atID )
> *
> ** Get information on file using FILEINFO()
> *
> ** Initialize local variables
> SP1   = ' '
> NULL$ = ''
> *
> ** Assign passed variables
> Value= NULL$ ; ** initialize return variable
> FileName = atID  ; ** the name of the file (key)
> *
> ** Open the file and get the file information to pass back
> OPEN '', FileName TO FileName.FV THEN
> Modulo= FILEINFO(FileName.FV, 5)
> BlockSize = FILEINFO(FileName.FV, 8)
> BlockCode = INT(BlockSize / 1024)
> Value = Modulo : ',' : BlockCode
> CLOSE FileName.FV
> END ELSE
> Value = NULL$
> END
> *
> RETURN
> END
> 
> I use this program in a dictionary item called "F_SIZE".
> 
> 3 Dev (0)-> AE VOC F_SIZE
> Top of "F_SIZE" in "VOC", 6 lines, 95 characters.
> *--: P
> 001: I Return the file information on the defined size
> 002: SUBR ( "D.GETFILEINFO", @ID )
> 003:
> 004: FileInfo
> 005: 10R
> 006: S
> Bottom.
> 
> ...which returns the size of the file.  When I use this on a multi-level 
> file it fails to return the file size.  e.g.
> 
> 3 Dev (0)-> LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE
> LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE 14:50:50 Nov 03 2012 1
> VOC... Data Location FileInfo..
> 
> APOPEN APOPEN
> HISTORY
> HOLD
> APPO APPO11,1
> 2 records listed
> 
> It works fine on regular files.  I tracked the problem down to UniData 
> doesn't pass in the name of the file to the called subroutine, @ID 
> doesn't work.  What is passed is the last hashed dictionary item of the 
> APOPEN dictionary file.  When I put a "CRT" statement in the program 
> code just below where the "FileName" variable is assigned...
> 
> CRT FileName
> 
> ...the list output looks like this:
> 
> 3 Dev (0)-> LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE
> *BALANCE*
> LIST VOC 'APOPEN''APPO' F_DATAW F_SIZE 14:50:50 Nov 03 2012 1
> VOC... Data Location FileInfo..
> 
> APOPEN APOPEN
> HISTORY
> HOLD
> *APPO*
> APPO APPO11,1
> 2 records listed
> 
> I discovered this because I listed the dictionary of the APOPEN file; 
> which looks like:
> 
> 3 Dev (0)-> LIST DICT APOPEN NOPAGE
> LIST DICT APOPEN NOPAGE 14:51:11 Nov 03 2012 1
> Dict Name..
> 
> ACCT_F
> REP
> TEST2
> @UQ
> ACCT_L
> .
> CHECK_ID
> @HOLD
> @APOPEN
> VNAME20
> .
> APPROVED
> @ID
> AS_LKS
> .
> BNAME
> CBALANCE
> ACCTS_VCNT
> ACCT_CNT
> AMTS1
> APMY
> *BALANCE*
> 99 records listed
> 
> ...and "BALANCE", which UD passes into the subroutine, happens to be the 
> last dictionary item hashed into the APOPEN dictionary file.  Any idea 
> why this is the case, or is this some kind of feature.
> -- 
> Untitled Page
> 
> Bill Haskett
> 
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> 
This message contains information that may be privileged or confidential and is 
the property of GPM Development Ltd. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient ,you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

This e-mail was sent to you by GPM Development Ltd.  We are incorporated under 
the laws of England and Wales (company no. 2292156 and VAT registration no. 523 
5622 63).  Our registered office is 6th Floor, AMP House, Croydon, Surrey CR0 
2LX.
 

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

Re: [U2] [UD] Odd question re: 7.1 docs

[Robert]

I have talked to programmers at conferences and places like that, and 
some of them have utilized techniques like that to ensure that their 
bills are paid on time...(smile)...


Robert Norman

On 10/4/2012 7:18 PM, Kevin King wrote:

I just found this in the UDT.OPTIONS manual...

"If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the
target file."

Here's my question.  With that description in mind, why would anyone want
this to be off?
___
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] [UD] Odd question re: 7.1 docs

[Robert]

I have talked to programmers at conferences and places like that, and 
some of them have utilitized techniques like that to ensure that their 
bills are paid on time...(smile)...


Robert Norman

On 10/4/2012 7:18 PM, Kevin King wrote:

I just found this in the UDT.OPTIONS manual...

"If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the
target file."

Here's my question.  With that description in mind, why would anyone want
this to be off?
___
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] [UD] Odd question re: 7.1 docs (Unclassified)

[Kevin King]

Ah, makes sense. Thanks!

On Fri, Oct 5, 2012 at 6:20 AM, Wally Terhune
wrote:

> Most often we don't really know if customers rely on a particular behavior
> in the product.
> When UniData has behaved in a particular manner for many years, we
> hesitate to just change the behavior in some cases. We have been surprised
> more than once when we did change behavior without providing an option and
> found that customers had coded around the product behavior and had their
> application 'break' upon upgrading to a new UniData release.
>
> Wally Terhune
> Technical Support Engineer
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w:
> rocketsoftware.com/u2
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:
> u2-users-boun...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR
> Sent: Thursday, October 04, 2012 8:45 PM
> To: U2 Users List
> Subject: Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified)
>
> At a guess, an "important" customer relies on the behaviour that the
> option turns off and lost the argument about whether this was a
> feature-not-a-bug rather than a bug-not-a-feature
>
>
> Regards
>
>
> Mike
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
> Sent: Friday, 5 October 2012 3:19 p.m.
> To: U2 Users List
> Subject: [U2] [UD] Odd question re: 7.1 docs
>
> I just found this in the UDT.OPTIONS manual...
>
> "If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the
> target file."
>
> Here's my question.  With that description in mind, why would anyone want
> this to be off?
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> The information contained in this Internet Email message is intended for
> the addressee only and may contain privileged information, but not
> necessarily the official views or opinions of the New Zealand Defence Force.
> If you are not the intended recipient you must not use, disclose, copy or
> distribute this message or the information in it.
>
> If you have received this message in error, please Email or telephone the
> sender immediately.
> ___
> 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] [UD] Odd question re: 7.1 docs (Unclassified)

[Wally Terhune]

Most often we don't really know if customers rely on a particular behavior in 
the product.
When UniData has behaved in a particular manner for many years, we hesitate to 
just change the behavior in some cases. We have been surprised more than once 
when we did change behavior without providing an option and found that 
customers had coded around the product behavior and had their application 
'break' upon upgrading to a new UniData release.

Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: rocketsoftware.com/u2


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR
Sent: Thursday, October 04, 2012 8:45 PM
To: U2 Users List
Subject: Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified)

At a guess, an "important" customer relies on the behaviour that the option 
turns off and lost the argument about whether this was a feature-not-a-bug 
rather than a bug-not-a-feature


Regards


Mike

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Friday, 5 October 2012 3:19 p.m.
To: U2 Users List
Subject: [U2] [UD] Odd question re: 7.1 docs

I just found this in the UDT.OPTIONS manual...

"If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the 
target file."

Here's my question.  With that description in mind, why would anyone want this 
to be off?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
The information contained in this Internet Email message is intended for the 
addressee only and may contain privileged information, but not necessarily the 
official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or 
distribute this message or the information in it.

If you have received this message in error, please Email or telephone the 
sender immediately.
___
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] [UD] Odd question re: 7.1 docs (Unclassified)

[HENDERSON MIKE, MR]

At a guess, an "important" customer relies on the behaviour that the
option turns off and lost the argument about whether this was a
feature-not-a-bug rather than a bug-not-a-feature


Regards


Mike

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Friday, 5 October 2012 3:19 p.m.
To: U2 Users List
Subject: [U2] [UD] Odd question re: 7.1 docs

I just found this in the UDT.OPTIONS manual...

"If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from
the
target file."

Here's my question.  With that description in mind, why would anyone
want
this to be off?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or 
distribute this message or the information in it.

If you have received this message in error, please Email or telephone
the sender immediately.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] LISTUSER output: phantom vs. iphantm

[Wally Terhune]

There is no specific limit on phantom use.
However, if you use phantom processes in a home-grown connection pooling style 
application architecture, you may need to purchase connection pooling licenses 
to support that. You should validate your license needs with your U2 provider, 
though. 
Regards,

Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: rocketsoftware.com/u2



-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Taylor
Sent: Saturday, September 15, 2012 11:15 AM
To: U2 Users List
Subject: Re: [U2] [UD] LISTUSER output: phantom vs. iphantm

Wally,

This reference is very helpful.

Is it true, then, that the number of true Phantoms (not iPhantoms) allowed at 
any one time is unlimited, regardless of the number of licenses purchased, or 
is there still some limit to the number of Phantoms allowed?

Thanks,

Dave


> https://u2tc.rocketsoftware.com/documentation/PDF/1177927.pdf
>
> Wally Terhune
> Technical Support Engineer
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w:
> 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: Friday, September 14, 2012 8:37 AM
> To: U2 Users List
> Subject: Re: [U2] [UD] LISTUSER output: phantom vs. iphantm
>
> Is there a definitive list of operations that makes something an 
> iPhantom vs. a phantom?  I know about sockets, but presume there is more, 
> right?
>
> ___
> 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] [UD] LISTUSER output: phantom vs. iphantm

[David Taylor]

Wally,

This reference is very helpful.

Is it true, then, that the number of true Phantoms (not iPhantoms) allowed
at any one time is unlimited, regardless of the number of licenses
purchased, or is there still some limit to the number of Phantoms allowed?

Thanks,

Dave


> https://u2tc.rocketsoftware.com/documentation/PDF/1177927.pdf
>
> Wally Terhune
> Technical Support Engineer
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w:
> 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: Friday, September 14, 2012 8:37 AM
> To: U2 Users List
> Subject: Re: [U2] [UD] LISTUSER output: phantom vs. iphantm
>
> Is there a definitive list of operations that makes something an iPhantom
> vs. a phantom?  I know about sockets, but presume there is more, right?
>
> ___
> 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] [UD] LISTUSER output: phantom vs. iphantm

[Kevin King]

Excellent, thanks Wally!

On Fri, Sep 14, 2012 at 9:23 PM, Wally Terhune
wrote:

> https://u2tc.rocketsoftware.com/documentation/PDF/1177927.pdf
>
> Wally Terhune
> Technical Support Engineer
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w:
> 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: Friday, September 14, 2012 8:37 AM
> To: U2 Users List
> Subject: Re: [U2] [UD] LISTUSER output: phantom vs. iphantm
>
> Is there a definitive list of operations that makes something an iPhantom
> vs. a phantom?  I know about sockets, but presume there is more, right?
>
> ___
> 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] [UD] LISTUSER output: phantom vs. iphantm

[Wally Terhune]

https://u2tc.rocketsoftware.com/documentation/PDF/1177927.pdf

Wally Terhune
Technical Support Engineer
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: 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: Friday, September 14, 2012 8:37 AM
To: U2 Users List
Subject: Re: [U2] [UD] LISTUSER output: phantom vs. iphantm

Is there a definitive list of operations that makes something an iPhantom vs. a 
phantom?  I know about sockets, but presume there is more, right?

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

Re: [U2] [UD] LISTUSER output: phantom vs. iphantm

[Kevin King]

Is there a definitive list of operations that makes something an iPhantom
vs. a phantom?  I know about sockets, but presume there is more, right?

On Fri, Sep 14, 2012 at 1:26 AM, Brian Leach  wrote:

> iPhantoms are any background that perform interactive operations, such as
> opening a socket or device. They consume a licence.
>
> FWIH some time back a couple of naughty sites were buying small numbers of
> users and opening ttys directly with phantoms so IBM blocked that. Now it
> catches all of us who legitimately want to make a web service or similar
> call in the background.
>
> Brian
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
> dean.armbrus...@ferguson.com
> Sent: 13 September 2012 23:32
> To: u2-users@listserver.u2ug.org
> Subject: [U2] [UD] LISTUSER output: phantom vs. iphantm
>
> What is the difference between LISTUSER USRTYPEs "phantom" and "iphantm"?
>
> On our systems, we will have 100 to 200 phantom processes, i.e. background
> processes, running at any given moment.  When I look at them via LISTUSER,
> they will be split approximately 60/40 between phantom and iphantm.  All
> were started using the PHANTOM verb.
>
> I can't discern a difference, and I can't find anything about it in the 7.3
> UniData documents.  A search for "iphantm" has no hits.
>
> This comes into play because it seems that SYSTEM(514) includes iphantm
> sessions in the count, but not phantom sessions.  We have a monitoring
> program that warns us if the number of users approaches the configured
> license limit, and it uses SYSTEM(514).  We built in for it to allow for a
> configurable amount of phantom processes.  If phantom processes may or may
> not be included in SYSTEM(514), our monitor program isn't as accurate as it
> could be.
>
> It seems to me that neither phantom nor iphantm should be included in
> SYSTEM(514).  HELP for SYSTEM(514) states that it returns the number users
> currently logged in and does not include phantoms.  Presumably, this is the
> number of licenses in use.  Do iphantm sessions use a license?
>
>
> UniData 7.3.1
> HPUX 11.31
>
> Dean Armbruster
> Information Technology, System Analyst
> Ferguson Enterprises, Inc.
> 12500 Jefferson Avenue * Newport News * VA * 23602-4314
> T: +1 (757) 989 2839 * F: +1 (757) 989 2801
> www.ferguson.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-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users