[U2] RE: U2] UV-piopen TRANS function

2005-01-22 Thread Stevenson, Charles
> Lastly, if you use the REMOVE function within your code,
> instead of resetting the pointer, just use a temporary 
> variable so that the position of the pointer in the passed
> in argument is both irrelevant and unchanged. That way
> you don't inadvertantly affect a piece of code that's
> working with the array.


So instead of:
   FUNCTION  ATRANS( F,K,P,X )
   SAVED.RP = GETREM(K);* preserve however calling pgms had it.
   SETREM 0 ON K   ;* reset to beginning of array.
   REMOVE DUM FROM K SETTING MORE ;* check for any delimiter
   SETREM SAVED.RP ON K   ;* reset rmv ptr in case calling pgm cares.
   T = TRANS(F,K,P,X)
   RETURN (IF MORE THEN T ELSE RAISE(T) ) 

do:
   FUNCTION  ATRANS( F,K,P,X )
   KTEMP=K
   REMOVE DUM FROM KTEMP SETTING MORE ;* check for any delimiter
   T = TRANS(F,K,P,X)
   RETURN (IF MORE THEN T ELSE RAISE(T) ) 


That is something I sometimes do, too, but in this particular case (the
TRANS() workaround) it would be inappropriate for 2 reasons:

1.  K could sometimes be very large, so copying the array to a
temporary variable could be expensive.
Example: The ap I work on has outgrown its pre-native-indexing ...XREF
files.  Some XREF records contain mv-lists of hundreds, yea, verily I
say unto thee, thousands of keys to their corresponding primary data
files.  Suppose  an I-descriptor in the XREF's dict that  TRANS()'s back
to the primary file.Execution  of KTEMP = K becomes oppressive,
whereas manipulating K's remove pointer is trivial.

2.  This is a utility subroutine that will be called by RetrieVe how
many times per day?   Beyond normal use, suppose a few selects each day
on a few million-record files with a few TRANS's per record.
Generally, I liker to err on the side of Maintainability (including
Readability) over Efficiency, but my exception is code that gets
executed repeatedly.  Then Efficiency wins.  Just comment the thing to
the hilt for the poor schmuck who reads it a few years hence.

If this were a less used routine and I knew K was generally small,  I
might go for copying the contents of K to KTEMP and forgetting about the
remove pointers. 


(  A tangential comment for newbies:

UV-Basic (UD, too?) passes arguments by address, not value.   That is,
the calling routine tells the subroutine where the data resides in
memory, rather than passing the data itself to/from the subroutine.  So
the subroutine  references and manipulates the very same data in memory
as the calling routine does.  In the case of large dynamic arrays that
is quite efficient, compared with the alternative of first making a
separate memory copy of the string for the subroutine, then, upon
return, copying that data back to the calling routine's variable.  )

For whatever it is worth,

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


RE: [U2] UV-piopen TRANS function

2005-01-21 Thread Andrea Charles
I like the idea of a replacement function, unfortunately, the filename is
not quoted in the i-desc so using my replacement function for TRANS will not
compile. I may be stuck with adding the RAISE.


> 
> 
> If you're going to programmatically change a bunch of 
> dictionaries, you
> might want to add your own function instead of adding the 
> RAISE statement to
> the dictionaries.  For the cost of the overhead of calling an 
> additional
> function you'll get two benefits.  First, is that if your 
> code has to be
> tweaked, you'll only have to do it in one place, and second 
> is that you can
> find/identify all of the dictionary items that you've changed 
> by searching
> for your unique function name.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] UV-piopen TRANS function

2005-01-21 Thread Tim Franklin
Do you have sub values in your data? if not it maybe useful to write a
program to select each file and execute all I-Descriptors that use the TRANS
function on each record looking for @SVM in the result. This may take some
time to run but will ensure all TRANS have been converted.



-Original Message-
From: Andrea Charles [mailto:[EMAIL PROTECTED] 
Sent: 21 January 2005 14:32
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] UV-piopen TRANS function

Thanks for all the suggestions. I think I am going to bite the bullet and
add the RAISE to all i-descriptors. Think I can come up with a BASIC program
to accomplish this. And learned about K=K in the process.

IBM's response is that this is a documented difference between UniVerse and
PIopen and there are no workarounds other than using the RAISE function to
raise the results from the TRANS.

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


Re: [U2] UV-piopen TRANS function

2005-01-21 Thread Allen Egerton
From: "Andrea Charles" <[EMAIL PROTECTED]>
To: 
Sent: Friday, January 21, 2005 8:31 AM
Subject: [U2] UV-piopen TRANS function


> Thanks for all the suggestions. I think I am going to bite the bullet and
> add the RAISE to all i-descriptors. Think I can come up with a BASIC
program
> to accomplish this. And learned about K=K in the process.



If you're going to programmatically change a bunch of dictionaries, you
might want to add your own function instead of adding the RAISE statement to
the dictionaries.  For the cost of the overhead of calling an additional
function you'll get two benefits.  First, is that if your code has to be
tweaked, you'll only have to do it in one place, and second is that you can
find/identify all of the dictionary items that you've changed by searching
for your unique function name.

Lastly, if you use the REMOVE function within your code, instead of
resetting the pointer, just use a temporary variable so that the position of
the pointer in the passed in argument is both irrelevant and unchanged.
That way you don't inadvertantly affect a piece of code that's working with
the array.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] UV-piopen TRANS function

2005-01-19 Thread Mats Carlid
Note that you also want to raise when the
position is -1 ( retreiving the entire record lowered ).
And when we're at it we can remove the restriction
that TRANS only handles positions not attribute names:
FUNCTION  ATRANS( F,K,P,X )
  L = ( IF NOT(NUM(P) THEN L = TRANS("DICT ":F,P,2,"X") ELSE P)
  K = K ; * What me paranoid ? Reset rmv ptr.
  REMOVE DUM FROM K SETTING MORE ; check for any delimiters
  K = K ; * reset rmv ptr in case calling pgm cares.
  T = TRANS(F,K,L,X)
  RETURN (IF (DUM AND L # -1) THEN T ELSE RAISE(T) )
  END
But don't use this with names in the call inside deep loops!
-- mats
Andrea Charles wrote:
We are doing a conversion from PI/Open v3.5.r3 on a Prime EXL (mips) to
universe 10.1.4 on AIX 5.3, All the occurrences of the TRANS function return
the "wrong" answer, and appear to be lowered. Simple testing indicates that
using the RAISE function in front of the TRANS expression returns the
correct result. However, we have thousands of occurrences of such in
dictionary I-descriptors. Do you know of any "global" way to tell uv to not
require the use of RAISE to produce the correct answer in this
case. Or, do you know of a replacement function that will work the way
needed? I have searched the archives and found one homegrown subroutine but
I can't seem to get it work reliably.
Thanks for any help.
Andrea Charles
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] UV-piopen TRANS function

2005-01-19 Thread Richard Taylor
I don't know of any configuration setting for this. This is actually a
'feature' of the TRANS function in UV.  You could pass in a multi-valued
list of keys to translate and get a multi-value list of the entire record
back, hence the need to lower the record.

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

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

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

- Montgomery Scott NCC-1701



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, January 19, 2005 10:05 AM
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] UV-piopen TRANS function

We are doing a conversion from PI/Open v3.5.r3 on a Prime EXL (mips) to
universe 10.1.4 on AIX 5.3, All the occurrences of the TRANS function
return
the "wrong" answer, and appear to be lowered. Simple testing indicates
that
using the RAISE function in front of the TRANS expression returns the
correct result. However, we have thousands of occurrences of such in
dictionary I-descriptors. Do you know of any "global" way to tell uv to
not
require the use of RAISE to produce the correct answer in this
case. Or, do you know of a replacement function that will work the way
needed? I have searched the archives and found one homegrown subroutine
but
I can't seem to get it work reliably.

Thanks for any help.

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


RE: [U2] UV-piopen TRANS function

2005-01-19 Thread Stevenson, Charles
From:  Mats Carlid

What's wrong with

FUNCTION  ATRANS( F,K,P,X )
 RETURN (RAISE(TRANS(F,K,P,X))
END
?
--

looks good, except how about something like:

 FUNCTION  ATRANS( F,K,P,X )
 REMOVE DUM FROM K SETTING MORE ; check for any delimiters
 K = K ; * reset rmv ptr in case calling pgm cares.
 T = TRANS(F,K,P,X)
 RETURN (IF MORE THEN T ELSE RAISE(T) )

or did I get the then-else backwards . . .

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


RE: [U2] UV-piopen TRANS function

2005-01-19 Thread Andrea Charles
 That will work as long as the fields are multi-valued. Charles noted that
in his response and through further testing, I believe that is accurate. I
am investigating whether this application uses TRANS in any single-valued
expressions.

-Original Message-
From: Mats Carlid
To: u2-users@listserver.u2ug.org
Sent: 1/19/05 12:47 PM
Subject: Re: [U2] UV-piopen TRANS function

What's wrong with

FUNCTION  ATRANS( F,K,P,X )
 RETURN (RAISE(TRANS(F,K,P,X))
END
?

Must be as reliable as trans itself !
!

Call it as   SUBR("*ATRANS", F,K,P,X)
 in I-descriptors  and as
y = ATRANS( FILE,KEY,POS,X)
in  a program
(once You've inserted a deffun in the program :

DEFFUN  ATRANS(F,K,P,X)  CALLING "*ATRANS"

all assuming you use global cataloging.

-- mats


Andrea Charles wrote:

>We are doing a conversion from PI/Open v3.5.r3 on a Prime EXL (mips) to
>universe 10.1.4 on AIX 5.3, All the occurrences of the TRANS function
return
>the "wrong" answer, and appear to be lowered. Simple testing indicates
that
>using the RAISE function in front of the TRANS expression returns the
>correct result. However, we have thousands of occurrences of such in
>dictionary I-descriptors. Do you know of any "global" way to tell uv to
not
>require the use of RAISE to produce the correct answer in this
>case. Or, do you know of a replacement function that will work the way
>needed? I have searched the archives and found one homegrown subroutine
but
>I can't seem to get it work reliably.
>
>Thanks for any help.
>
>Andrea Charles
>---
>u2-users mailing list
>u2-users@listserver.u2ug.org
>To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] UV-piopen TRANS function

2005-01-19 Thread Mats Carlid
What's wrong with
FUNCTION  ATRANS( F,K,P,X )
RETURN (RAISE(TRANS(F,K,P,X))
END
?
Must be as reliable as trans itself !
!
Call it as   SUBR("*ATRANS", F,K,P,X)
in I-descriptors  and as
   y = ATRANS( FILE,KEY,POS,X)
in  a program
(once You've inserted a deffun in the program :
DEFFUN  ATRANS(F,K,P,X)  CALLING "*ATRANS"
all assuming you use global cataloging.
-- mats
Andrea Charles wrote:
We are doing a conversion from PI/Open v3.5.r3 on a Prime EXL (mips) to
universe 10.1.4 on AIX 5.3, All the occurrences of the TRANS function return
the "wrong" answer, and appear to be lowered. Simple testing indicates that
using the RAISE function in front of the TRANS expression returns the
correct result. However, we have thousands of occurrences of such in
dictionary I-descriptors. Do you know of any "global" way to tell uv to not
require the use of RAISE to produce the correct answer in this
case. Or, do you know of a replacement function that will work the way
needed? I have searched the archives and found one homegrown subroutine but
I can't seem to get it work reliably.
Thanks for any help.
Andrea Charles
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] UV-piopen TRANS function

2005-01-19 Thread Stevenson, Charles
Andrea,

This is a known conversion issue.

I don't think there is a workaround other than to write your own TRANS
function replacement.  (If you do, be sure to mimic some of the
efficient caching of already-read records that TRANS does.)  If IBM
wanted to, a new UVCONFIG option could be a way could address it.  I
don't think that will happen.  Go to U2UG's enhancement forum and
suggest it.  Maybe others will join your fight, but I don't know how
many PI conversions are still pending.

It's been a decade or so since I've used PI & PIOpen but as I recall,
PI[Open] will lower the results if and only if the TRANS function is fed
a multi-valued list of ids (2nd arg).
UV always lowers.

So I would qualify the 'all' in your assertion, 'All the occurrences of
the TRANS function return the "wrong" answer'.   Maybe that is true for
you, but PI _sometimes_ lowers the answer just like UV (i.e., if 2nd arg
is mv'd).   Maybe you just never have that situation in your ap.

I remember sometimes liking, sometimes frustrated by PI's
behind-the-scenes choice.  I guess Vmark had the same frustration and
decided to go with consistency.

Once past the conversion hassle, I think you'll find UV's solution
better, although I must admit to occasionally wishing it behaved like
PI.

Oh, well.  The king is dead; long live the king.

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