Re: [U2] [UV] GOSUB variable-name?
You just have a different parameter for locked read:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK) - for normal reads
CALL IO.PROGRAM('READ_LOCK',TABLE.NAME,KEY,RECORD,OK) - for locked reads
- Original Message -
From: George Gallen [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, February 16, 2006 2:25 PM
Subject: RE: [U2] [UV] GOSUB variable-name?
Just curious, how would you handle a locked read?
One nice thing about using intrinsic READs is the OS knows
who is still logged in and who is not, and eliminates locks
when someone logs out that had locks in place.
George
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Serguei
Sent: Thursday, February 16, 2006 4:53 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
There is much better OOP-style solution to the file variable problem.
Create a named COMMON that is defined in one program only -
the program
responsible for reading/writing a record of the data. It will
open file when
it first needed if it is not opened yet and do the writing.
And never again
anywhere in your programs you will have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
---
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] GOSUB variable-name?
Yes, as I said before because of the limitation of U2 Basic sometimes one
has to use functions for different reasons but only if this allows to avoid
passing parameters in COMMONs.
In my example having program that does several things means that COMMON will
be used only in one program to store data between different calls to the
program. This is not ideal but it is much better then to have the same
COMMON in many different programs.
- Original Message -
From: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, February 16, 2006 3:35 PM
Subject: Re: [U2] [UV] GOSUB variable-name?
On 14 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
Why not instead of CALL SomeProg('GetCustomerBalance',...)
and CALL SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
On 16 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
... never again anywhere in your programs you will
have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
Okay - which is it? Should one write a single routine to handle multiple
functions or not?
You have promoted both viewpoints as absolutes.
--Tom Pellitieri
Century Equipment
---
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] GOSUB variable-name?
I would combine different functions into one program only when I have to
preserve a state between calls to different program (in my example - to
preserve variables with file handles) and avoid using COMMON to pass data
between programs.
- Original Message -
From: George Gallen [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, February 16, 2006 3:50 PM
Subject: RE: [U2] [UV] GOSUB variable-name?
I initially thought that same thing :)
However, since READ and WRITE are both I/O functions
and the name of the routine is IO.PROGRAM which fit
the description
Whereas, GetCustomerBalance and PaintScreen are two
unrelated (supposedly) subroutines.
I'm guessing the answer is it's ok to combine like subroutines
into one subroutine with a passed function variable but not
ok to combine unlike subroutines with a passwd subroutine
variable??
George
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 10:35 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
On 14 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
Why not instead of CALL SomeProg('GetCustomerBalance',...)
and CALL SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
On 16 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
... never again anywhere in your programs you will
have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
Okay - which is it? Should one write a single routine to
handle multiple
functions or not?
You have promoted both viewpoints as absolutes.
--Tom Pellitieri
Century Equipment
---
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] GOSUB variable-name?
There are two benefit:
1. You can have a COMMON with opened files in one program only
2. If in the future you need to modify the way system reads or writes data
into database (e.g. adding additional checks, logging data update, reporting
on errors) you don't have to look for and modify all programs where you read
or write - you have to change only one program.
- Original Message -
From: Bob Woodward [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, February 16, 2006 4:43 PM
Subject: RE: [U2] [UV] GOSUB variable-name?
I'm a bit confused, too, as to the benefit one would receive by calling
a program to do the reads and writes vs. an internal command to read and
write. I mean, after all, you still have to test OK for a status value.
Maybe I'm being too literal on the use of the READ command used as an
example...
BobW
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 7:35 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
On 14 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
Why not instead of CALL SomeProg('GetCustomerBalance',...)
and CALL SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
On 16 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
... never again anywhere in your programs you will
have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
Okay - which is it? Should one write a single routine to handle
multiple
functions or not?
You have promoted both viewpoints as absolutes.
--Tom Pellitieri
Century Equipment
---
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] GOSUB variable-name?
That's the way I handle the reads from .Net also. It works well and
allows you to put read and readu logic in one pick subroutine.
george
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Serguei
Sent: Friday, February 17, 2006 11:35 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
You just have a different parameter for locked read:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK) - for normal reads
CALL IO.PROGRAM('READ_LOCK',TABLE.NAME,KEY,RECORD,OK) - for locked reads
- Original Message -
From: George Gallen [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, February 16, 2006 2:25 PM
Subject: RE: [U2] [UV] GOSUB variable-name?
Just curious, how would you handle a locked read?
One nice thing about using intrinsic READs is the OS knows
who is still logged in and who is not, and eliminates locks
when someone logs out that had locks in place.
George
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Serguei
Sent: Thursday, February 16, 2006 4:53 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
There is much better OOP-style solution to the file variable
problem.
Create a named COMMON that is defined in one program only -
the program
responsible for reading/writing a record of the data. It will
open file when
it first needed if it is not opened yet and do the writing.
And never again
anywhere in your programs you will have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
---
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] GOSUB variable-name?
There is much better OOP-style solution to the file variable problem.
Create a named COMMON that is defined in one program only - the program
responsible for reading/writing a record of the data. It will open file when
it first needed if it is not opened yet and do the writing. And never again
anywhere in your programs you will have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
As COMMON appears only in one program - IO.PROGRAM (or whatever name you
give to it), it is not used to pass parameters around. You might call this
encapsulation (obviously it is not full-blown OOP but it is better then
nothing).
The side-effect of this is that because of all read-write is via one program
it is very easy to add additional functionality later (e.g. to start logging
all writes into a log file later during the life of the system - you don't
have to change all programs where you write data for that).
The rule is - if you thinking to pass parameters using COMMON there is
always a better solution if you think about it.
- Original Message -
From: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Wednesday, February 15, 2006 1:48 PM
Subject: Re: [U2] [UV] GOSUB variable-name?
cut
Additionally, there are many valid uses for COMMON blocks that have
nothing
to do with OOP. There have been numerous discussions on this list
regarding the overhead of opening files, and having a common block of file
variables available in each routine makes more sense than having each
routine open the files it needs.
cut
--Tom Pellitieri
Toledo, Ohio
---
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] GOSUB variable-name?
OOP is a difficult concept to grasp for somebody from procedural programming background. My first use of OOP was a real pain. Once somebody through that stage one cannot understand how one could live without it. Unfortunately you have not get through that stage so you just don't understand what the advantages are. For me it is always much easier to develop a complicated functionality in a flexible way in a language that supports OOP then in U2. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, February 15, 2006 4:01 PM Subject: Re: [U2] [UV] GOSUB variable-name? True, I am not an OOP. However I have studied it and I did use it when taking courses during the 80's one of which was Pascal. The Windows reference is just an example and not, by any means, the only use of OOP. I just don't think that U2 is missing anything by not having it built in. - Original Message - From: Serguei [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, February 15, 2006 4:03 AM Subject: Re: [U2] [UV] GOSUB variable-name? You not an OOP expect, are you? I have been using OOP since it appeared in Turbo Pascal long before and windows tools appeared and our current Java code calling Universe programs has nothing to do with windows tools (our application has an HTML browser interface). Only those who do not know anything about OOP think that it has anything to do with Windows. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, February 14, 2006 5:45 PM Subject: Re: [U2] [UV] GOSUB variable-name? Not a limitation, you build your own objects. Objects after all are nothing more than subroutines that perform a specific task. You may even say that it is an advantage because you are not tied into doing what someone else has decided how something should work. You create your own. Almost every company I have worked for has had a different way of display and storing information. It's only when using windows tools that they will settle for what they get because they have no choice. - Original Message - From: Serguei [EMAIL PROTECTED] One of those limitation - no OOP. --- 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] [UV] GOSUB variable-name?
I have always thought of OOP as a complicated way of producing very simlpe procedual code. Les Sherlock Hewkin Senior Developer Core Systems - 9951 01604 592289 -Original Message- From: Serguei [mailto:[EMAIL PROTECTED] Sent: 16 February 2006 09:58 To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] GOSUB variable-name? OOP is a difficult concept to grasp for somebody from procedural programming background. My first use of OOP was a real pain. Once somebody through that stage one cannot understand how one could live without it. Unfortunately you have not get through that stage so you just don't understand what the advantages are. For me it is always much easier to develop a complicated functionality in a flexible way in a language that supports OOP then in U2. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, February 15, 2006 4:01 PM Subject: Re: [U2] [UV] GOSUB variable-name? True, I am not an OOP. However I have studied it and I did use it when taking courses during the 80's one of which was Pascal. The Windows reference is just an example and not, by any means, the only use of OOP. I just don't think that U2 is missing anything by not having it built in. - Original Message - From: Serguei [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, February 15, 2006 4:03 AM Subject: Re: [U2] [UV] GOSUB variable-name? You not an OOP expect, are you? I have been using OOP since it appeared in Turbo Pascal long before and windows tools appeared and our current Java code calling Universe programs has nothing to do with windows tools (our application has an HTML browser interface). Only those who do not know anything about OOP think that it has anything to do with Windows. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, February 14, 2006 5:45 PM Subject: Re: [U2] [UV] GOSUB variable-name? Not a limitation, you build your own objects. Objects after all are nothing more than subroutines that perform a specific task. You may even say that it is an advantage because you are not tied into doing what someone else has decided how something should work. You create your own. Almost every company I have worked for has had a different way of display and storing information. It's only when using windows tools that they will settle for what they get because they have no choice. - Original Message - From: Serguei [EMAIL PROTECTED] One of those limitation - no OOP. --- 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/ This message has been comprehensively scanned for viruses, please visit http://www.avg.power.net.uk/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
Just curious, how would you handle a locked read?
One nice thing about using intrinsic READs is the OS knows
who is still logged in and who is not, and eliminates locks
when someone logs out that had locks in place.
George
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Serguei
Sent: Thursday, February 16, 2006 4:53 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
There is much better OOP-style solution to the file variable problem.
Create a named COMMON that is defined in one program only -
the program
responsible for reading/writing a record of the data. It will
open file when
it first needed if it is not opened yet and do the writing.
And never again
anywhere in your programs you will have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
On 14 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
Why not instead of CALL SomeProg('GetCustomerBalance',...)
and CALL SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
On 16 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
... never again anywhere in your programs you will
have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
Okay - which is it? Should one write a single routine to handle multiple
functions or not?
You have promoted both viewpoints as absolutes.
--Tom Pellitieri
Century Equipment
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
I initially thought that same thing :)
However, since READ and WRITE are both I/O functions
and the name of the routine is IO.PROGRAM which fit
the description
Whereas, GetCustomerBalance and PaintScreen are two
unrelated (supposedly) subroutines.
I'm guessing the answer is it's ok to combine like subroutines
into one subroutine with a passed function variable but not
ok to combine unlike subroutines with a passwd subroutine
variable??
George
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 10:35 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
On 14 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
Why not instead of CALL SomeProg('GetCustomerBalance',...)
and CALL SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
On 16 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
... never again anywhere in your programs you will
have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
Okay - which is it? Should one write a single routine to
handle multiple
functions or not?
You have promoted both viewpoints as absolutes.
--Tom Pellitieri
Century Equipment
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
Serguei,
I really don't understand your position. The illustration below is what I
would consider to be a classic example of having a single program perform
multiple functions according to data passed to it (whether the branch is
performed by an IF...ELSE, an ON ... GOSUB or a CASE statement is
irrelevant). Yet you've spent the last week or so telling us all that such
programs are an abomination.
I'd agree that contriving to jump into a program designed to do something
else and somehow navigate to a particular subroutine just because it happens
to be there and can do what you want is very wrong. Equally you are wrong to
assert unequivocally that there is NEVER a good reason to have a single
program that can perform more than one function depending on data passed to
it.
At the risk of repeating somebody else's post, I hope your foot heals soon.
Regards
Piers
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Serguei
Sent: 16 February 2006 09:53
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
There is much better OOP-style solution to the file variable problem.
Create a named COMMON that is defined in one program only - the program
responsible for reading/writing a record of the data. It will open file when
it first needed if it is not opened yet and do the writing. And never again
anywhere in your programs you will have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
For me it is always much easier to develop a complicated functionality in a flexible way in a language that supports OOP then in U2. I'm sure that after you gain more experience with U2, you will find it contains the flexibility to create very complex applications easily. It took me a long time to appreciate U2's capabilities, so I'm sure a beginner would overlook it's beauty. Barry Brevik --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
I'm a bit confused, too, as to the benefit one would receive by calling
a program to do the reads and writes vs. an internal command to read and
write. I mean, after all, you still have to test OK for a status value.
Maybe I'm being too literal on the use of the READ command used as an
example...
BobW
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 7:35 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UV] GOSUB variable-name?
On 14 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
Why not instead of CALL SomeProg('GetCustomerBalance',...)
and CALL SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
On 16 Feb 2006, Serguei [EMAIL PROTECTED] wrote:
... never again anywhere in your programs you will
have to write
READ RECORD FROM FILE,KEY THEN
or
READ RECORD TO FILE,KEY THEN
Just do:
CALL IO.PROGRAM('READ',TABLE.NAME,KEY,RECORD,OK)
or
CALL IO.PROGRAM('WRITE',TABLE.NAME,KEY,RECORD,OK)
Okay - which is it? Should one write a single routine to handle
multiple
functions or not?
You have promoted both viewpoints as absolutes.
--Tom Pellitieri
Century Equipment
---
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] GOSUB variable-name?
You not an OOP expect, are you? I have been using OOP since it appeared in Turbo Pascal long before and windows tools appeared and our current Java code calling Universe programs has nothing to do with windows tools (our application has an HTML browser interface). Only those who do not know anything about OOP think that it has anything to do with Windows. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, February 14, 2006 5:45 PM Subject: Re: [U2] [UV] GOSUB variable-name? Not a limitation, you build your own objects. Objects after all are nothing more than subroutines that perform a specific task. You may even say that it is an advantage because you are not tied into doing what someone else has decided how something should work. You create your own. Almost every company I have worked for has had a different way of display and storing information. It's only when using windows tools that they will settle for what they get because they have no choice. - Original Message - From: Serguei [EMAIL PROTECTED] One of those limitation - no OOP. --- 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] GOSUB variable-name?
Yes that's what was so fascinating 'bout simula when I got aquainted with it back in '70 but it wasn't called OO by then ... -- mats Serguei wrote: You not an OOP expect, are you? I have been using OOP since it appeared in Turbo Pascal long before and windows tools appeared and our current Java code calling Universe programs has nothing to do with windows tools (our application has an HTML browser interface). Only those who do not know anything about OOP think that it has anything to do with Windows. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, February 14, 2006 5:45 PM Subject: Re: [U2] [UV] GOSUB variable-name? Not a limitation, you build your own objects. Objects after all are nothing more than subroutines that perform a specific task. You may even say that it is an advantage because you are not tied into doing what someone else has decided how something should work. You create your own. Almost every company I have worked for has had a different way of display and storing information. It's only when using windows tools that they will settle for what they get because they have no choice. - Original Message - From: Serguei [EMAIL PROTECTED] One of those limitation - no OOP. --- 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] GOSUB variable-name?
True, I am not an OOP. However I have studied it and I did use it when taking courses during the 80's one of which was Pascal. The Windows reference is just an example and not, by any means, the only use of OOP. I just don't think that U2 is missing anything by not having it built in. - Original Message - From: Serguei [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, February 15, 2006 4:03 AM Subject: Re: [U2] [UV] GOSUB variable-name? You not an OOP expect, are you? I have been using OOP since it appeared in Turbo Pascal long before and windows tools appeared and our current Java code calling Universe programs has nothing to do with windows tools (our application has an HTML browser interface). Only those who do not know anything about OOP think that it has anything to do with Windows. - Original Message - From: Jerry Banker [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, February 14, 2006 5:45 PM Subject: Re: [U2] [UV] GOSUB variable-name? Not a limitation, you build your own objects. Objects after all are nothing more than subroutines that perform a specific task. You may even say that it is an advantage because you are not tied into doing what someone else has decided how something should work. You create your own. Almost every company I have worked for has had a different way of display and storing information. It's only when using windows tools that they will settle for what they get because they have no choice. - Original Message - From: Serguei [EMAIL PROTECTED] One of those limitation - no OOP. --- 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] GOSUB variable-name?
Why not instead of CALL SomeProg('GetCustomerBalance',...) and CALL
SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreen
Another rule of structural programming - every program can have only one
purpose :).
Unfortunately in case of U2 sometimes we have to live with the programming
language limitations.
One of those limitation - no OOP.
This is the only reason one should choose to do something of the kind you
have described - the reason to mimic some of the elements of OOP (this is
also why one might to use COMMONs as well - this is the only reason for
COMMON, emulating elements of OOP, not passing parameters around). But in
that case it is wrong to make the first parameter a name of the subroutine
to jump to. If should be just a meaningful value. Inside the program the
value is checked (probably in a CASE statement) and a decision is made on
what exactly should happen. The calling program should have no knowledge of
or directly reference anything what is inside the program.
- Original Message -
From: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Tuesday, February 14, 2006 12:18 AM
Subject: RE: [U2] [UV] GOSUB variable-name?
The purpose of this type of indirection is (or should be) both business
and
application related. It's a methodology which helps cohesion
(understanding
the problem). I don't see why you should have separate methods for the
business logic from the programming mumbo jumbo.
For example if you pass into a program a description of something you want
it to do, CALL SomeProg('GetCustomerBalance',...) that is business
related.
Now if by CALL SomeProg('PaintScreen',...), that is programming mumbo
jumbo, either way, whatever happens within the scope of that call 'is' a
black box.
By using descriptive method arguments it creates cohesion, where you can
pretty much understand 'what' a component does but don't have to know
'how'
it does it (as long as it's working) without having to take the lid off
it.
The conversation here has just been a debate on whether a program
could/should branch to a label with the same name by compiler or by
construction. Then if by construction, how do you do it. I don't think
there's any real disagreement in the wider computing world about the
soundness of the methodology, viz object methods. Generally this type of
interface is called dynamic dispatch and it's a widely used and
respected
method.
Stuart
It is always wrong to specify directly in a calling program which branch
the
execution should take in a program that is called. It does not matter
whether it is using GOSUB @variable or CASE statement. It is also wrong
to
pass into the called program the information from where it is been
called. \
Each parameter passed inside a program should have a business-related
meaning, not programming jumbo-mumbo.
**
This email message and any files transmitted with it are confidential and
intended solely for the use of addressed recipient(s). If you have received
this email in error please notify the Spotless IS Support Centre (+61 3 9269
7555) immediately, who will advise further action. This footnote also
confirms that this email message has been scanned for the presence of
computer related viruses.
**
---
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] GOSUB variable-name?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Serguei Sent: Tuesday, February 14, 2006 4:09 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] GOSUB variable-name? Another rule of structural programming - every program can have only one purpose :). In a perfect world, true, in Reality (and I'm not talking Microdata here) however, the every program can needs to read every program should Just as in a perfect world, there would be no cookies for me to not eat! George --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
George Gallen wrote: In a perfect world, true, in Reality (and I'm not talking Microdata here) however, the every program can needs to read every program should I agree. But I also believe that just because our predecessors may have created some heinousness doesn't mean that we're obligated to continue the tradition. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
All, In defense of this technique, I offer the following: Putting all the like routines in a single portfolio (single BASIC program) is akin to storing all the methods for an object in the code which describes the object. Infact modes had a similar approach, storing the Proc and BASIC versions of an infact technique in the same mode, with a difference in entry point to establish which method you were calling. Putting all the like routines in a single portfolio (single BASIC program) allows for easier version management. Also easier to print and document. Putting all the like routines in a single portfolio (single BASIC program) encourages consistent variable naming across routines, because they all share the same common block and the same EQUates. - Charles A Place For Everything Barouch --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
How much purpose should a programmer program if a programmer could program purposes? From: George Gallen From: Serguei Another rule of structural programming - every program can have only one purpose :). In a perfect world, true, in Reality (and I'm not talking Microdata here) however, the every program can needs to read every program should True, but it could also be reworded to say Programmers CAN create programs that have only one purpose. Even in MV-Basic. Chas. Stevenson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
Not a limitation, you build your own objects. Objects after all are nothing more than subroutines that perform a specific task. You may even say that it is an advantage because you are not tied into doing what someone else has decided how something should work. You create your own. Almost every company I have worked for has had a different way of display and storing information. It's only when using windows tools that they will settle for what they get because they have no choice. - Original Message - From: Serguei [EMAIL PROTECTED] One of those limitation - no OOP. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
It is always wrong to specify directly in a calling program which branch the... . . It is also wrong to pass into the called program the information from where it is been called. It's only wrong if it doesn't work, is difficult to maintain or runs slow. Both of these techniques are completely valid and have been used by programmers to develop reusable code before the advent of object orientation (if your language even supports OOP). For example, I have a fairly intense screen and data entry handler that does a lot of different things. It is inefficient for every program to call 20 different subroutines instead of calling one and telling it to give me a field right here and this long, in this color with these function keys enabled that do such and so. So this is wrong? It has saved me huge programming hours over the years. Heck, back when I coded machine language we'd put a bunch of things we got to work right into a module and give it different entry points. I think we called them device drivers back then and it was considered a normal thing to do. Barry Brevik --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
The problem here is that in case of passing the GUSUB name as a parameter the calling program should know the structure of the program been called (e.g. that there is a GOSUB inside). This contradicts the structural programming idea of a program been a black box. - Original Message - From: George Gallen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, February 10, 2006 3:26 PM Subject: RE: [U2] [UV] GOSUB variable-name? but the question was referring to a gosub not a call, so the control should (big should) be contained within one program. The only time I used the call @varible was when I had different subroutines based on the flavor of the system This way it I had one base program that could be modified that when recompiled would again work with Prime or D3. This was before UV. George --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
It is always wrong to specify directly in a calling program which branch the execution should take in a program that is called. It does not matter whether it is using GOSUB @variable or CASE statement. It is also wrong to pass into the called program the information from where it is been called. Each parameter passed inside a program should have a business-related meaning, not programming jumbo-mumbo. - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Saturday, February 11, 2006 4:11 PM Subject: Re: [U2] [UV] GOSUB variable-name? The solution here is almost too easy. Build a CASE construct to GOSUB based on the value of SUBNAME. As to the wisdom of this approach, I see no problems whatsoever. Many called subroutines are told what to do by the caller. What's the problem with that? Regards, Charlie Noah Inland Truck Parts In a message dated 2/10/2006 3:29:38 A.M. Central Standard Time, [EMAIL PROTECTED] writes: This approach is absolutely awful from software design point of view. I personally would hate to have to support software when it is the calling program that decides the flow of the program that is been called. Do you really need this? - Original Message - From: Barry Brevik [EMAIL PROTECTED] To: U2-users (E-mail) u2-users@listserver.u2ug.org Sent: Wednesday, February 08, 2006 7:03 PM Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- 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] [UV] GOSUB variable-name?
The purpose of this type of indirection is (or should be) both business and
application related. It's a methodology which helps cohesion (understanding
the problem). I don't see why you should have separate methods for the
business logic from the programming mumbo jumbo.
For example if you pass into a program a description of something you want
it to do, CALL SomeProg('GetCustomerBalance',...) that is business related.
Now if by CALL SomeProg('PaintScreen',...), that is programming mumbo
jumbo, either way, whatever happens within the scope of that call 'is' a
black box.
By using descriptive method arguments it creates cohesion, where you can
pretty much understand 'what' a component does but don't have to know 'how'
it does it (as long as it's working) without having to take the lid off it.
The conversation here has just been a debate on whether a program
could/should branch to a label with the same name by compiler or by
construction. Then if by construction, how do you do it. I don't think
there's any real disagreement in the wider computing world about the
soundness of the methodology, viz object methods. Generally this type of
interface is called dynamic dispatch and it's a widely used and respected
method.
Stuart
It is always wrong to specify directly in a calling program which branch
the
execution should take in a program that is called. It does not matter
whether it is using GOSUB @variable or CASE statement. It is also wrong
to
pass into the called program the information from where it is been
called. \
Each parameter passed inside a program should have a business-related
meaning, not programming jumbo-mumbo.
**
This email message and any files transmitted with it are confidential and
intended solely for the use of addressed recipient(s). If you have received
this email in error please notify the Spotless IS Support Centre (+61 3 9269
7555) immediately, who will advise further action. This footnote also confirms
that this email message has been scanned for the presence of computer related
viruses.
**
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
The solution here is almost too easy. Build a CASE construct to GOSUB based on the value of SUBNAME. As to the wisdom of this approach, I see no problems whatsoever. Many called subroutines are told what to do by the caller. What's the problem with that? Regards, Charlie Noah Inland Truck Parts In a message dated 2/10/2006 3:29:38 A.M. Central Standard Time, [EMAIL PROTECTED] writes: This approach is absolutely awful from software design point of view. I personally would hate to have to support software when it is the calling program that decides the flow of the program that is been called. Do you really need this? - Original Message - From: Barry Brevik [EMAIL PROTECTED] To: U2-users (E-mail) u2-users@listserver.u2ug.org Sent: Wednesday, February 08, 2006 7:03 PM Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- 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] GOSUB variable-name?
[EMAIL PROTECTED] asked: Many called subroutines are told what to do by the caller. What's the problem with that? While I agree that passing a parameter into a subroutine to tell it what to do is a common practice, it has the side-effect of obfuscating the functionality of the subroutine. For best readability, a subroutine should perform one basic function that is obvious either from reading the code or the embedded comments. When a single subroutine performs several dozen different tasks based on an incoming parameter, that's all the more code to have to decipher when trying to figure out what that subroutine does six months after the fact. Now this is not to say that the technique doesn't have a time and place. I've used this technique to create a generalized tax calculation routine where the country code is a passed parameter, and then the subroutine has a big CASE statement to determine which tax routine is to be used for each country. This subroutine then calls other external subroutines for the calculations per country; embedding all that logic for all countries into one subroutine would have made for a readability disaster. I firmly believe that one of the most significant productivity drains on any software project occurs when someone takes on a piece of code they've never seen before (or can't remember) and the objective of that code is not obvious from the context, code, or commenting. When this occurs, there's a period of what the [EMAIL PROTECTED] does this thing do, which is much easier to determine when the code is small and focused on one task vs. large and multi-purpose. While I know of no metrics to prove such a claim, I believe this issue is one of the leading causes of excessively long development times and incremental maintenance instability resulting in projects that are much more expensive, inflexible, and buggy than necessary. The old party line about keeping everything inside of one subroutine to avoid the overhead of calling other subroutines may have been applicable a decade ago, but with the speed of todays machines and the sophisticated caching in these environments such overhead is largely (though admittedly not completely) mitigated. So as long as we're dedicated to these decades-old methods, in the end we're doing little more than producing less results that are more difficult and more costly to maintain. My apologies if this comes across a little strong. I'm just very tired of seeing our jobs go overseas because corporate America thinks that domestic software development is so expensive and this day-to-day repeat of outmoded implementation tactics is doing nothing to prove them wrong. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
There is a place for this type of construct. In very large systems you'll sometimes find numerous places where 'the location' logic is performed (as an example). Then you have a user co-funded development to make a big change to the location logic. Now you have to *find* and change those 360+ programs. Been there, done that. Had a little more imagination been used prior to creating those 360+ programs, the project could have been done by changing one common subroutine. In the same system, the billing is all done by the same common subroutine, and it does do a lot of different stuff depending on who's calling it. But when you change billing, it's all done in one program (well, actually a chain of programs, but each one does it's own piece and nothing is duplicated). Saving big big dev time. Sure it's harder to change and do it right. But you know it took me almost 6 months to find and change all the location programs, and then 6 months later I had to do it again for another co-funded project and discovered some that I missed the first time because the person had been unusually creative in using non-standard file and variable names. *(a big DOH moment for me)* So about a year of my life was spent on the most boring, tedious and unrewarding search, modify, test, and move to the next one mundane programming that I have ever done. Trust me, the changes I did to billing were wonderful and swift and sweet in comparison. More difficult in brain power yes, but they were some fairly big changes and only took a couple of weeks instead of 6 months. If I had changed all those programs to call a central subroutine the first time, it would have probably taken another month, but then the second time would have been a couple of weeks instead of another horribly painful 6 months. T'was like a bad dream that I couldn't wake up from !! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kevin King Sent: Saturday, February 11, 2006 09:09 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] GOSUB variable-name? [EMAIL PROTECTED] asked: Many called subroutines are told what to do by the caller. What's the problem with that? While I agree that passing a parameter into a subroutine to tell it what to do is a common practice, it has the side-effect of obfuscating the functionality of the subroutine. For best readability, a subroutine should perform one basic function that is obvious either from reading the code or the embedded comments. When a single subroutine performs several dozen different tasks based on an incoming parameter, that's all the more code to have to decipher when trying to figure out what that subroutine does six months after the fact. Now this is not to say that the technique doesn't have a time and place. I've used this technique to create a generalized tax calculation routine where the country code is a passed parameter, and then the subroutine has a big CASE statement to determine which tax routine is to be used for each country. This subroutine then calls other external subroutines for the calculations per country; embedding all that logic for all countries into one subroutine would have made for a readability disaster. I firmly believe that one of the most significant productivity drains on any software project occurs when someone takes on a piece of code they've never seen before (or can't remember) and the objective of that code is not obvious from the context, code, or commenting. When this occurs, there's a period of what the [EMAIL PROTECTED] does this thing do, which is much easier to determine when the code is small and focused on one task vs. large and multi-purpose. While I know of no metrics to prove such a claim, I believe this issue is one of the leading causes of excessively long development times and incremental maintenance instability resulting in projects that are much more expensive, inflexible, and buggy than necessary. The old party line about keeping everything inside of one subroutine to avoid the overhead of calling other subroutines may have been applicable a decade ago, but with the speed of todays machines and the sophisticated caching in these environments such overhead is largely (though admittedly not completely) mitigated. So as long as we're dedicated to these decades-old methods, in the end we're doing little more than producing less results that are more difficult and more costly to maintain. My apologies if this comes across a little strong. I'm just very tired of seeing our jobs go overseas because corporate America thinks that domestic software development is so expensive and this day-to-day repeat of outmoded implementation tactics is doing nothing to prove them wrong. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.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
Re: [U2] [UV] GOSUB variable-name?
This approach is absolutely awful from software design point of view. I personally would hate to have to support software when it is the calling program that decides the flow of the program that is been called. Do you really need this? - Original Message - From: Barry Brevik [EMAIL PROTECTED] To: U2-users (E-mail) u2-users@listserver.u2ug.org Sent: Wednesday, February 08, 2006 7:03 PM Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- 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] GOSUB variable-name?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Serguei Sent: Friday, February 10, 2006 4:18 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] GOSUB variable-name? This approach is absolutely awful from software design point of view. I personally would hate to have to support software when it is the calling program that decides the flow of the program that is been called. Do you really need this? I agree, have we not learned anything from the past? Look what happened when gave machines the power to decide their own course of actions2001..Battlestar GallacticaKitt (and Kar) Giving programs the ability to control their own flow will eventually be the downfall of the human race! On a more serious note...If this is done correctly, I don't think it would be very difficult at all to support. George --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
On a more serious note...If this is done correctly, I don't think it would be very difficult at all to support. If someone who didn't design the system has to maintain it, it is difficult to find out which programs are impacted by a change into one of the subroutines. In normal calls, one can search for CALL ROUTINE.NAME but when CALL @VARIABLE is used, it is difficult to find out, short of creating a trace in the subroutine that records SYSTEM(9001) over a period of time (even then, its no garantee that the period of time will be sufficient to identify all of the calling programs). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
Hi Barry, When I create subroutines that are highly generic, I like to make them as black box as possible. This one, as part of it's processing, needs to GOSUB to another routine, the name of which would be passed by the original caller. In that case you need to use external subroutines with indirect calls. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
I guess you could use: SUBNAME= GOSUB SUBLIST . . . SUBLIST: BEGIN CASE CASE SUBNAME=SUB1 . . CASE SUBNAME=SUB2 . . END CASE RETURN . . George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry Brevik Sent: Wednesday, February 08, 2006 2:04 PM To: U2-users (E-mail) Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- 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] GOSUB variable-name?
Barry, Almost. This will work: SUBROUTINE CALLME(INNERLABEL) * LABELLIST = THISLABEL:@AM:THATLABEL,:@AM:THEOTHERLABEL * LOCATE(INNERLABEL,LABELLIST;POS) THEN ON POS GOSUB THISLABEL, THATLABEL, THEOTHERLABEL END RETURN * * START OF SUBROUTINES * THISLABEL: RETURN * THATLABEL: ... RETURN * THEOTHERLABEL: ... RETURN I typed this from memory, please forgive any typos. -- Charles Barouch [EMAIL PROTECTED] - Consulting [EMAIL PROTECTED] - ETL/Migration/Integration (718) 762-3884x1 Barry Brevik wrote: | I would like to pass a variable (let's call it SUBNAME) to a subroutine, | and this variable would contain the name of an existing label which I will | call TEST. | | The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. | | Aside from CALL @VARIABLENAME, is there any way to branch indirectly in | universe? This would be really useful for me. | | Barry Brevik | --- | 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] GOSUB variable-name?
On Behalf Of Barry Brevik Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. ON-GOSUB might work for you. Though it isn't a particularly popular technique. (Almost as bad as a ON-GOTO.) (I assume UV has this, I know UDT does. - jmh --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
or possibly SUBNAME= GOSUB SUBLIST SUBLIST: SUBNAMES=ROUTINE1,ROUTINE2,ROUTINE3,ROUTINE4,ROUTINE5.. CONVERT , TO CHAR(254) IN SUBNAMES NFND=0 LOCATE SUBNAME IN SUBNAMES1 SETTING SUBLOC ELSE RETURN ON SUBLOC GOSUB ROUTINE1,ROUTINE2,ROUTINE3,ROUTINE4 RETURN ROUTINE1: . . RETURN ROUTINE2: . . RETURN George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry Brevik Sent: Wednesday, February 08, 2006 2:04 PM To: U2-users (E-mail) Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
Barry, I'm afraid that you will have to setup a set of CASE statements to test what was passed in then GOSUB to the correct subroutine. BEGIN CASE CASE SUBNAME = 'TEST' GOSUB TEST CASE SUBNAME = 'TEST2' GOSUB TEST2 ... END CASE Not as elegant but then this is U2. ;o) Gordon Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 02/08/2006 02:03:39 PM: I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
Hi Barry, Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. An easy one No. Out of interest, why do you need it? Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
The answer is no, and as was mentioned before you could use a CASE to check for input values and gosub accordingly. Still, seems like an awefully perilous way to code, especially six months later when you're trying to figure out what the thing is intended to be doing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barry Brevik Sent: Wednesday, February 08, 2006 12:04 PM To: U2-users (E-mail) Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.2/253 - Release Date: 2/7/2006 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
Clever, Chuck - very clever. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
The reason why one cannot specify a variable realtime GOTO target is because the uv compiler actually replaces those with direct jump instructions into the pseudo-code stream. In the first pass, it notes the offsets of LABELs, then on the second pass updates the GOTO references to those labels. If a GOTO references a non-existing LABEL, your compilation dies. Since the object code doesn't retain LABELs, this type of functionality isn't available. The closest you may get might be to use: ON SUBINDEX GOSUB SUB1,SUB2,...SUBxx, which uses SUBINDEX to determine which SUBx is executed. This allows the compiler to validate labels but gives you some flexibility at runtime to determine which to actually use. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= I reject your reality and substitute my own - Adam Savage Glenn M. Herbert - Connectivity Development Engineer Information Integration Solutions, IBM Software Group 50 Washington Street Westboro, MA 01581 508-599-7281 direct [EMAIL PROTECTED] wrote on 02/08/2006 02:31:39 PM: I guess you could use: SUBNAME= GOSUB SUBLIST . . . SUBLIST: BEGIN CASE CASE SUBNAME=SUB1 . . CASE SUBNAME=SUB2 . . END CASE RETURN . . George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry Brevik Sent: Wednesday, February 08, 2006 2:04 PM To: U2-users (E-mail) Subject: [U2] [UV] GOSUB variable-name? I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- 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] GOSUB variable-name?
From: Barry Brevik [EMAIL PROTECTED] I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Not that I'm aware of. You've probably already considered the following, but if not... (Caveat - written off the top of my head, in a non-U2 environment). CRT Starting Main LABEL.NAME = 100 CALL @XYZ(LABEL.NAME) LABEL.NAME = 200 CALL @XYZ(LABEL.NAME) LABEL.NAME = BLAH.BLAH.BLAH CALL @XYZ(LABEL.NAME) CRT Finished Main STOP END ;* COMPILER SUBROUTINE XYZ (LABEL.NAME) CRT Entering XYZ, value of LABEL.NAME ': LABEL.NAME: '. BEGIN CASE CASE LABEL.NAME EQ 100 GOSUB 100: CASE LABEL.NAME EQ 200 GOSUB 200: CASE LABEL.NAME EQ BLAH.BLAH.BLAH GOSUB BLAH.BLAH.BLAH: CASE 1 CRT ERROR, BAD/UNKNOWN LABEL.NAME VALUE END CASE * RETURN ;* To calling routine 100: code RETURN ;* To GOSUB 200: code RETURN ;* To GOSUB BLAH.BLAH.BLAH: code RETURN ;* To GOSUB END;* COMPILER -- Allen Egerton --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
I've seen this type of approach used where you have programs that generate programs. For screen building, etc. -Original Message- From: [EMAIL PROTECTED] Hi Barry, Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. An easy one No. Out of interest, why do you need it? Martin Phillips --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] GOSUB variable-name?
An easy one No. Out of interest, why do you need it? When I create subroutines that are highly generic, I like to make them as black box as possible. This one, as part of it's processing, needs to GOSUB to another routine, the name of which would be passed by the original caller. So when I have boilerplate code (this one does some screen handling that could be used by many, many of my apps), if I can keep from ever changing it after it works, I find I am happier. Barry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] GOSUB variable-name?
When a program is compiled, a GOSUB statement needs to know the specific line number to jump to. In your example, the compiler has no idea what the value of SUBNAME is, so it cannot determine the line number. The reason for this, I think, is to maximize the execution speed. The program jumps to a specific line (very fast), as opposed to having the program search for the line number and then jump. On the plus side, you can do what you are looking for with a CASE statement or ON GOSUB, both of which are probably mentioned in those unread emails that I see in my Inbox. [EMAIL PROTECTED] wrote on 02/08/2006 02:03:39 PM: I would like to pass a variable (let's call it SUBNAME) to a subroutine, and this variable would contain the name of an existing label which I will call TEST. The subroutine can then do GOSUB TEST, but GOSUB SUBNAME will not compile. Aside from CALL @VARIABLENAME, is there any way to branch indirectly in universe? This would be really useful for me. Barry Brevik --- 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/
