RE: [U2] Custom Functions
When I said 'hack' I meant the ugly code that I had to create to make the trick work--the idea of having to put a dummy parameter into the function call in the basic program in order to make it compatable with the subr call in the i-type. Sorry for the confusion there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Wallis Sent: Friday, June 24, 2005 9:04 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Custom Functions > [EMAIL PROTECTED] wrote > So you can mix and match between treating it as a subroutine and as a > function, but the function version always has one less argument - the > first one is missing as it is an "implied" result. > > Someone said "don't risk this because it may change in future". As far > as I'm aware, it WON'T change, because the SUBR call relies on this > behaviour. Look up SUBR in the docu, and you'll see that anything it > calls MUST be this sort of function, after all, when you call a > subroutine using SUBR, you can't pass in the first argument ... Wol, it was me that said "don't assume this will always be how it works". I think you missed my point. I wasn't saying that the SUBR() interface from I-types might change - why should it? What I was saying is that you shouldn't assume that the only way to implement FUNCTION was as a SUBROUTINE with an extra hidden argument, and you shouldn't assume that the only way to implement RETURN X was to set that hidden argument to the value of X. It appears to me from Wendy and Ed's investigations that UniData has indeed made a change somewhere since 4.1 when I last looked at this in detail such that there is no hidden extra argument on a FUNCTION and that RETURN X actually puts X on the stack somewhere. I stand by my comment: the way FUNCTION is currently implemented on both UniVerse and UniData is undocumented and should not be relied upon. If you want a FUNCTION which can also be called as a SUBR then code for it - write a wrapper for one or the other. Separately, Ed seems to have decided that UniData not following this undocumented mode of operation is a deficiency in UniData. I don't see it that way, but he's entitled to his opinion. On further inspection, I'm not even sure that what he identifies as a hack really is. The only undocumented feature in his program is that he successfully does a DEFFUN for a SUBROUTINE and then invokes the FUNCTION. The UniData documentation for DEFFUN *never* mentions the possibility that a SUBROUTINE can be referenced. All it mentions is FUNCTION. The doco on FUNCTION never suggests that FUNCTIONs map to SUBROUTINEs with an extra hidden argument. Anyway, I really don't want to go near the 'why buy UD instead of UV' discussion. There used to be a heap of reasons, but a lot have been flattened out in the various mergers and acquisitions. Discussions on this list do very occasionally throw up something UV has which I think would have been nice in UD - SEEK and REVREMOVE are examples, but UD still has some nice things that UV doesn't - GETENV, DIR and PCPERFORM come to mind. The only thing I will say before moving quickly along is 'indexes'. Cheers, Ken --- 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] Custom Functions
> [EMAIL PROTECTED] wrote > So you can mix and match between treating it as a subroutine > and as a function, but the function version always has one > less argument - the first one is missing as it is an "implied" result. > > Someone said "don't risk this because it may change in > future". As far as I'm aware, it WON'T change, because the > SUBR call relies on this behaviour. Look up SUBR in the docu, > and you'll see that anything it calls MUST be this sort of > function, after all, when you call a subroutine using SUBR, > you can't pass in the first argument ... Wol, it was me that said "don't assume this will always be how it works". I think you missed my point. I wasn't saying that the SUBR() interface from I-types might change - why should it? What I was saying is that you shouldn't assume that the only way to implement FUNCTION was as a SUBROUTINE with an extra hidden argument, and you shouldn't assume that the only way to implement RETURN X was to set that hidden argument to the value of X. It appears to me from Wendy and Ed's investigations that UniData has indeed made a change somewhere since 4.1 when I last looked at this in detail such that there is no hidden extra argument on a FUNCTION and that RETURN X actually puts X on the stack somewhere. I stand by my comment: the way FUNCTION is currently implemented on both UniVerse and UniData is undocumented and should not be relied upon. If you want a FUNCTION which can also be called as a SUBR then code for it - write a wrapper for one or the other. Separately, Ed seems to have decided that UniData not following this undocumented mode of operation is a deficiency in UniData. I don't see it that way, but he's entitled to his opinion. On further inspection, I'm not even sure that what he identifies as a hack really is. The only undocumented feature in his program is that he successfully does a DEFFUN for a SUBROUTINE and then invokes the FUNCTION. The UniData documentation for DEFFUN *never* mentions the possibility that a SUBROUTINE can be referenced. All it mentions is FUNCTION. The doco on FUNCTION never suggests that FUNCTIONs map to SUBROUTINEs with an extra hidden argument. Anyway, I really don't want to go near the 'why buy UD instead of UV' discussion. There used to be a heap of reasons, but a lot have been flattened out in the various mergers and acquisitions. Discussions on this list do very occasionally throw up something UV has which I think would have been nice in UD - SEEK and REVREMOVE are examples, but UD still has some nice things that UV doesn't - GETENV, DIR and PCPERFORM come to mind. The only thing I will say before moving quickly along is 'indexes'. Cheers, Ken --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] E_FAIL from SQL/OLEDB query
Just a guess ... When we use ODBC we often see this type of error, when the record we are trying to access is locked. There does not seem to be anyway to force a "READ ONLY" connection via ODBC. I'm not sure about OleDB. Noah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Friday, June 24, 2005 12:40 PM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] E_FAIL from SQL/OLEDB query I'm hoping someone has a solution to an issue plaguing one of our clients. The system is Universe 10 over AIX, using OleDB from .NET client and it is running normally for telnet users. Many SQL "select" statements are being issued to the server successfully, but once in a while an E_FAIL error is returned. When the error is returned, it seems like the query is successful, but the connection dies before a result can be returned. When the connection fails, the Universe license is left hanging, requiring a brutal termination for release. All the selects execute in the same order: Connect, Select, Close. The error is random, the same statement will sometimes work or not. This does not seem to be related to the number of users active on the system. Different files are being accessed, it's highly improbable there is a syntax issue, and syntax shouldn't cause this level of corruption of the connection anyway. IBM Support does not presently have a solution but they are checking to see if this is related to a similar issue which was patched in Unidata. Is anyone aware of other instances of this issue on Universe - with a firm resolution? Switching to ODBC is not an option, the site switched to OleDB after experiencing even worse issues with ODBC. Barring any OleDB-related solution we may migrate the data access code to mv.NET with support for ADO.NET, starting in just a few days. Forum or direct response welcome. Thanks, Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD.com --- 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] Custom Functions -> UV or UD
That's a useful feature. Anyone else know of any? I've noticed that unidata is accomodating about letting you run subroutines as though they were programs, and calling programs as though they were subroutines. Is that an advantage or something scary? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of phil walker > Sent: Friday, June 24, 2005 4:21 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Custom Functions -> UV or UD > > > One I can thing of, and I normally work on UV and prefer, is > that you can debug programs which interact with file which > have triggers on them. In UV this is not possible and is seen > as an enhancement! > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, 25 June 2005 1:46 a.m. > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Custom Functions > > Well, the idea was to produce something that could be called > as a function from basic, because the function calling syntax > is cool and convenient in a lot of cases, but that could also > be used in a I-type. For things to work in SUBR in an i-type, > you need that extra parameter. Of course you could maintain > two versions--a simple function, and then a subroutine > wrapper around the function to use in the i-type. I was > trying to avoid that. And, if you're using universe, you can > just use the function in the i-type anyway. > > The more I see of it, the more unidata feels like universe's > really poor relative. Which begs the question--given a > choice, why would one pick unidata over universe? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] E_FAIL from SQL/OLEDB query
I'm hoping someone has a solution to an issue plaguing one of our clients. The system is Universe 10 over AIX, using OleDB from .NET client and it is running normally for telnet users. Many SQL "select" statements are being issued to the server successfully, but once in a while an E_FAIL error is returned. When the error is returned, it seems like the query is successful, but the connection dies before a result can be returned. When the connection fails, the Universe license is left hanging, requiring a brutal termination for release. All the selects execute in the same order: Connect, Select, Close. The error is random, the same statement will sometimes work or not. This does not seem to be related to the number of users active on the system. Different files are being accessed, it's highly improbable there is a syntax issue, and syntax shouldn't cause this level of corruption of the connection anyway. IBM Support does not presently have a solution but they are checking to see if this is related to a similar issue which was patched in Unidata. Is anyone aware of other instances of this issue on Universe - with a firm resolution? Switching to ODBC is not an option, the site switched to OleDB after experiencing even worse issues with ODBC. Barring any OleDB-related solution we may migrate the data access code to mv.NET with support for ADO.NET, starting in just a few days. Forum or direct response welcome. Thanks, Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Custom Functions -> UV or UD
One I can thing of, and I normally work on UV and prefer, is that you
can debug programs which interact with file which have triggers on them.
In UV this is not possible and is seen as an enhancement!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Saturday, 25 June 2005 1:46 a.m.
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Custom Functions
Well, the idea was to produce something that could be called as a
function from basic, because the function calling syntax is cool and
convenient in a lot of cases, but that could also be used in a I-type.
For things to work in SUBR in an i-type, you need that extra parameter.
Of course you could maintain two versions--a simple function, and then a
subroutine wrapper around the function to use in the i-type. I was
trying to avoid that.
And, if you're using universe, you can just use the function in the
i-type anyway.
The more I see of it, the more unidata feels like universe's really poor
relative.
Which begs the question--given a choice, why would one pick unidata over
universe?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Burwell,
> Edward
> Sent: Thursday, June 23, 2005 6:04 PM
> To: 'u2-users@listserver.u2ug.org'
> Subject: RE: [U2] Custom Functions
>
>
> Interesting. But you NEED that extra parameter? I tried DEFFUNing a
> SUBROUTINE that has only 1 parameters and could not get it to work.
>
> If your FUNCTION sets any of the parameters, you can CALL It from
> UniBasic
> -- and you don't have to DEFFUN it.
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 23, 2005 5:52 PM
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] Custom Functions
>
>
> I think it's a universe/unidata difference. I get the segmentation
> fault running unidata in ecl type U as well.
> Here's some interesting info and an ugly hack--in unidata.
> Apparently, the keywords SUBROUTINE and FUNCTION are interchangable as
> far as BASIC is concerned, so create a subroutine
> SUBROUTINE MYHACK(A,B)
> A=B*2 ;* note that we both assign the result
> to a parameter AND return the result
> RETURN A
> Then you can call it as a function with
> PROGRAM HACKTEST
> DEFFUN MYHACK(A,B)
> CRT MYHACK('',2);* <--- there's the hack. You need that
> placeholder parameter
> Or use it as a subroutine:
> PROGRAM HACK2
> CALL MYHACK(A,2)
> CRT A
> Or from a virtual attribute:
> I
> SUBR('MYHACK',EXTRACT(@RECORD,1,0,0))
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Burwell,
> > Edward
> > Sent: Thursday, June 23, 2005 4:09 PM
> > To: 'u2-users@listserver.u2ug.org'
> > Subject: RE: [U2] Custom Functions
> >
> >
> > I've never seen this asterisk thing on the front of a cataloged
> > program. I've never had to do that in UniData. I can call a
> > SUBROUTINE fine from a Virtual attribute no problem - and not
> > asterisk. Could it have something to do with the fact that we run
> > BASICTYPE 'p' and ECLTYPE 'p'?
> >
> > -Original Message-
> > From: gerry-u2ug [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 23, 2005 1:41 PM
> > To: u2-users@listserver.u2ug.org
> > Subject: RE: [U2] Custom Functions
> >
> >
> > globally catalogued as in CATALOG SUB.BP *MYFUNC ?
> > so you should be using : SUBR("*MYFUNC","Y")
> >
> > we do this all the time in universe since at least v7
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Burwell,
> > Edward
> > Sent: Thursday, June 23, 2005 10:46 AM
> > To: u2-users@listserver.u2ug.org
> > Subject: RE: [U2] Custom Functions
> >
> >
> > Here is a sample:
> >
> > MYFUNC looks like:
> >
> > 001 FUNCTION MYFUNC(ARG)
> > 002 RETURN (ARG="Y")
> > 003 END
> >
> > MYFUNC is globally cataloged
> >
> > DICT FILE TEST looks like:
> >
> > 001 V
> > 002 SUBR("MYFUNC","Y")
> > 003
> > 004
> > 005 1R
> > 006 S
> >
> > when I LIST FILE TEST, I get a Segmentation fault(coredump) and it
> > dumps me into Unix.
> >
> > -Original Message-
> > From: Ray Wurlod [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 23, 2005 1:22 AM
> > To: u2-users@listserver.u2ug.org
> > Subject: RE: [U2] Custom Functions
> >
> >
> > Try using the SUBR() function, as I mentioned in another post.
> >
> > - Original Message -
> > From: "Burwell, Edward" <[EMAIL PROTECTED]>
> > To: "'u2-users@listserver.u2ug.org'"
> > Subject: RE: [U2] Custom Functions
> > Date: Wed, 22 Jun 2005 19:49:44 -0400
> >
> > >
> > > I've tried "calling" functions from UniData Virtual
> > Attribute and they
> > blow
> > > up. Bummer.
> > ---
> > u2-users mailing list
> > u2-users@listserver.u2ug.org
> > To unsubscribe please visit http://listserver.u2ug.org/
> >
> >
>
RE: [U2] IBM & Ascential
FYI, from IBM's "Today" Newsletter... Ascential and IBM - Hear the complete story. Attend the live webcast, Wednesday, June 29 at 11:00 am eastern. Hear the complete story of Ascential and IBM. http://www.ibm.com/isource/cgi-bin/goto?on=IMNL605K11 This webcast will cover the IBM Information Integration strategy and provide an overview of the complete portfolio of products. Listen to John M. Evans Director, Enterprise Application Markets and Holly Hayes, Program Director with IBM Information Integration Solutions. Find out how your users and applications can work with accurate, consistent, timely, and coherent business information, regardless of how, when, or where the information is stored or managed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of phil walker Sent: Thursday, June 16, 2005 2:48 PM To: u2-users@listserver.u2ug.org Subject: [U2] IBM & Ascential Ray, you should change the heading;-) Yes, who would ever have thought that the company which originally developed UV would be worth 2,100,000,000 USD. Vmark merged (tookover Unidata) to become Ardent. Ardent bought Prism (I think). Informix tookover Ardent (At least that is what they thought) Informix split DW products off into Ascential and sold DB for 1,000,000,000 USD IIAC Ascential sells to IBM for 1,100,000,000 USD. I wish I had of kept my Vmark shares. Ray D, do you still have yours. Cheers, Phil --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Custom Functions
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Anthony >Dzikiewicz >Sent: Friday, June 24, 2005 9:40 AM >To: u2-users@listserver.u2ug.org >Subject: RE: [U2] Custom Functions > > >Something I did in some subroutines which makes them more of a multi >tasker (I-descriptors) and flexible, is to pass file variables as >parameters - when you can. So, the subroutine would look something >like; > > >SUBROUTINE GET.NEXT.IJKEY(FILE.CN, ERR, F.STAT, IJKEY) > >$INCLUDE HEADERS STD.EQUATES >$INCLUDE HEADERS ERRCODES.EQUATES >$INCLUDE HEADERS IM.CTRL.EQUATES >$INCLUDE SYSCOM FILEINFO.INS.IBAS >* >*THE FILE(S) MAY OR MAY NOT BE OPENED >* >* > OPENED.CN = FALSE > NEED.TO.OPEN = FILEINFO(FILE.CN,0) > IF NEED.TO.OPEN = 0 THEN > OPEN '','CN' TO FILE.CN ELSE >ERR = ERR$CODE.OPENERR >F.STAT = STATUS() >GO STOP.RUN > END > OPENED.CN = TRUE > END > > >We are using Universe. You never know what need you might have in the >future and this can make things much easier. Actually, I thought 2 >dynamic array params (passed and returned) and a headers file as >pointers is probably more ideal. Then you can do any of this sort of >thing on the fly and you wouldn't have too much code to If you pass 3 dimensioned arrays would be ideal. 1 array for incoming variables (you can store an entire dynamic array inside one cell of a dimensioned array), 1 array for outgoing varibles, and 1 array for file headers since you store multiple fileheaders in a dimensioned array, but not in a dynamic array. George >change/recompile >when needs arise. > >Anthony --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Parsippany
Yes, I'm sure we all would... :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Thursday, June 23, 2005 5:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Parsippany Wow, wouldn't we all love to get a list like that. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Varney > Sent: Thursday, June 23, 2005 4:41 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Parsippany > > > I'm just interested to know who uses multi-value in the > north-eastern US > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Roger > Glenfield > Sent: Thursday, June 23, 2005 4:06 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Parsippany > > > The epicor job listing? > > -Rog > > John Varney wrote: > > >So would I > > > >There seems to be a [water?] company in Parsippany NJ using U2. > > > >I would like to know who they are. > > > >--Bill > --- > 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Custom Functions
Something I did in some subroutines which makes them more of a multi tasker (I-descriptors) and flexible, is to pass file variables as parameters - when you can. So, the subroutine would look something like; SUBROUTINE GET.NEXT.IJKEY(FILE.CN, ERR, F.STAT, IJKEY) $INCLUDE HEADERS STD.EQUATES $INCLUDE HEADERS ERRCODES.EQUATES $INCLUDE HEADERS IM.CTRL.EQUATES $INCLUDE SYSCOM FILEINFO.INS.IBAS * *THE FILE(S) MAY OR MAY NOT BE OPENED * * OPENED.CN = FALSE NEED.TO.OPEN = FILEINFO(FILE.CN,0) IF NEED.TO.OPEN = 0 THEN OPEN '','CN' TO FILE.CN ELSE ERR = ERR$CODE.OPENERR F.STAT = STATUS() GO STOP.RUN END OPENED.CN = TRUE END We are using Universe. You never know what need you might have in the future and this can make things much easier. Actually, I thought 2 dynamic array params (passed and returned) and a headers file as pointers is probably more ideal. Then you can do any of this sort of thing on the fly and you wouldn't have too much code to change/recompile when needs arise. Anthony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wendy Smoak Sent: Thursday, June 23, 2005 12:18 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Custom Functions From: "Ray Wurlod" <[EMAIL PROTECTED]> > > Try using the SUBR() function, as I mentioned in another post. > Ouch. Granted my function opens a file and [currently, for debug] prints to the screen, but attempting to call it with SUBR from an I-Descriptor caused... '25945 Bus error' and left the session unresponsive. Leaving aside the I-Descriptor issue for a moment... Is there a way for it a function to "assume" that the last file opened is the one I want to use? I thought there might be an @FILE or something, the way there is @ID and you can have a 'default' file for READ. http://www.pickwiki.com/cgi-bin/wiki.pl?TreeTraversal I thought of opening the file in the calling program, and passing a file handle instead of the filename. But I need this to work when called [indirectly] from UOJ also, and historically I've seen 'Error 30102' if I attempt to pass file handles around in any code called from UOJ. Advice on how to improve this would be gratefully accepted [see code in Wiki link above]. While the first one isn't TOO bad... there's a companion function that finds all of the children of a particular node, and it calls the first function to look back up the tree for any child that has multiple parents. In that case I open the same file over, and over and over. Thanks, Wendy Smoak --- 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] Custom Functions
Well, the idea was to produce something that could be called as a
function from basic, because the function calling syntax is cool and
convenient in a lot of cases, but that could also be used in a I-type.
For things to work in SUBR in an i-type, you need that extra parameter.
Of course you could maintain two versions--a simple function, and then a
subroutine wrapper around the function to use in the i-type. I was
trying to avoid that.
And, if you're using universe, you can just use the function in the
i-type anyway.
The more I see of it, the more unidata feels like universe's really poor
relative.
Which begs the question--given a choice, why would one pick unidata over
universe?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Burwell, Edward
> Sent: Thursday, June 23, 2005 6:04 PM
> To: 'u2-users@listserver.u2ug.org'
> Subject: RE: [U2] Custom Functions
>
>
> Interesting. But you NEED that extra parameter? I tried
> DEFFUNing a SUBROUTINE that has only 1 parameters and could
> not get it to work.
>
> If your FUNCTION sets any of the parameters, you can CALL It
> from UniBasic
> -- and you don't have to DEFFUN it.
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 23, 2005 5:52 PM
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] Custom Functions
>
>
> I think it's a universe/unidata difference. I get the
> segmentation fault running unidata in ecl type U as well.
> Here's some interesting info and an ugly hack--in unidata.
> Apparently, the keywords SUBROUTINE and FUNCTION are
> interchangable as far as BASIC is concerned, so create a subroutine
> SUBROUTINE MYHACK(A,B)
> A=B*2 ;* note that we both assign the result
> to a parameter AND return the result
> RETURN A
> Then you can call it as a function with
> PROGRAM HACKTEST
> DEFFUN MYHACK(A,B)
> CRT MYHACK('',2);* <--- there's the hack. You need that
> placeholder parameter
> Or use it as a subroutine:
> PROGRAM HACK2
> CALL MYHACK(A,2)
> CRT A
> Or from a virtual attribute:
> I
> SUBR('MYHACK',EXTRACT(@RECORD,1,0,0))
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Burwell, Edward
> > Sent: Thursday, June 23, 2005 4:09 PM
> > To: 'u2-users@listserver.u2ug.org'
> > Subject: RE: [U2] Custom Functions
> >
> >
> > I've never seen this asterisk thing on the front of a
> > cataloged program. I've never had to do that in UniData. I
> > can call a SUBROUTINE fine from a Virtual attribute no
> > problem - and not asterisk. Could it have something to do
> > with the fact that we run BASICTYPE 'p' and ECLTYPE 'p'?
> >
> > -Original Message-
> > From: gerry-u2ug [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 23, 2005 1:41 PM
> > To: u2-users@listserver.u2ug.org
> > Subject: RE: [U2] Custom Functions
> >
> >
> > globally catalogued as in CATALOG SUB.BP *MYFUNC ?
> > so you should be using : SUBR("*MYFUNC","Y")
> >
> > we do this all the time in universe since at least v7
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Burwell, Edward
> > Sent: Thursday, June 23, 2005 10:46 AM
> > To: u2-users@listserver.u2ug.org
> > Subject: RE: [U2] Custom Functions
> >
> >
> > Here is a sample:
> >
> > MYFUNC looks like:
> >
> > 001 FUNCTION MYFUNC(ARG)
> > 002 RETURN (ARG="Y")
> > 003 END
> >
> > MYFUNC is globally cataloged
> >
> > DICT FILE TEST looks like:
> >
> > 001 V
> > 002 SUBR("MYFUNC","Y")
> > 003
> > 004
> > 005 1R
> > 006 S
> >
> > when I LIST FILE TEST, I get a Segmentation fault(coredump)
> > and it dumps me into Unix.
> >
> > -Original Message-
> > From: Ray Wurlod [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 23, 2005 1:22 AM
> > To: u2-users@listserver.u2ug.org
> > Subject: RE: [U2] Custom Functions
> >
> >
> > Try using the SUBR() function, as I mentioned in another post.
> >
> > - Original Message -
> > From: "Burwell, Edward" <[EMAIL PROTECTED]>
> > To: "'u2-users@listserver.u2ug.org'"
> > Subject: RE: [U2] Custom Functions
> > Date: Wed, 22 Jun 2005 19:49:44 -0400
> >
> > >
> > > I've tried "calling" functions from UniData Virtual
> > Attribute and they
> > blow
> > > up. Bummer.
> > ---
> > u2-users mailing list
> > u2-users@listserver.u2ug.org
> > To unsubscribe please visit http://listserver.u2ug.org/
> >
> >
> __
> > This e-mail has been scanned by MCI Managed Email Content
> > Service, using
> > Skeptic(tm) technology powered by MessageLabs. For more
> > information on MCI's Managed Email Content Service, visit
> > http://www.mci.com.
> >
> __
> > ---
> > u2-users mailing list
> > u2-users@listse
RE: [U2] Parsippany
Then I would suspect that the local based U2 Headhunters would have the best clues to that Joe Chelston, Matt Hart et al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Thursday, June 23, 2005 5:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Parsippany Wow, wouldn't we all love to get a list like that. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Varney > Sent: Thursday, June 23, 2005 4:41 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Parsippany > > > I'm just interested to know who uses multi-value in the > north-eastern US > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Roger > Glenfield > Sent: Thursday, June 23, 2005 4:06 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Parsippany > > > The epicor job listing? > > -Rog > > John Varney wrote: > > >So would I > > > >There seems to be a [water?] company in Parsippany NJ using U2. > > > >I would like to know who they are. > > > >--Bill > --- > 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Custom Functions
> I think it's a universe/unidata difference. I get the segmentation fault
> running unidata in ecl type U as well.
> Here's some interesting info and an ugly hack--in unidata.
It seems completely wrong to me (UV in Prime flavour)
> Apparently, the keywords SUBROUTINE and FUNCTION are interchangable as
> far as BASIC is concerned, so create a subroutine
> SUBROUTINE MYHACK(A,B)
Actually, I don't think they are ... at least npt the way you imply.
> A=B*2 ;* note that we both assign the result
> to a parameter AND return the result
> RETURN A
This is weird ...
>Then you can call it as a function with
> PROGRAM HACKTEST
> DEFFUN MYHACK(A,B)
> CRT MYHACK('',2);* <--- there's the hack. You need that
> placeholder parameter
This is why it blows up ...
> Or use it as a subroutine:
> PROGRAM HACK2
> CALL MYHACK(A,2)
> CRT A
> Or from a virtual attribute:
> I
> SUBR('MYHACK',EXTRACT(@RECORD,1,0,0))
Let's say we want a function called MYHACK. The following two declarations are
identical...
SUBROUTINE MYHACK( RESULT, A, B)
...
RESULT = whatever
RETURN
or
FUNCTION MYHACK( A, B)
...
RETURN (whatever)
If you want to access the first version from a calling program by doing
DEFFUN MYHACK( A, B)
ANSWER = MYHACK( 1, 2)
that'll work. As will calling the latter version with
CALL MYHACK( ANSWER, 1, 2)
So you can mix and match between treating it as a subroutine and as a function,
but the function version always has one less argument - the first one is
missing as it is an "implied" result.
Someone said "don't risk this because it may change in future". As far as I'm
aware, it WON'T change, because the SUBR call relies on this behaviour. Look up
SUBR in the docu, and you'll see that anything it calls MUST be this sort of
function, after all, when you call a subroutine using SUBR, you can't pass in
the first argument ...
Cheers,
Wol
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
