I just ran a test where a main program called an external subroutine
In the external subroutine I had it display system(9001)
 
The subroutine name was listed in that display as was the main routine which 
had called it
 
 
 
 
-----Original Message-----
From: David Wasylenko <d...@pickpro.com>
To: U2 Users List <u2-users@listserver.u2ug.org>
Sent: Mon, May 12, 2014 6:09 pm
Subject: Re: [U2] Read yourself


I think the point has been lost.
The person is requesting the name of the CURRENT ROUTINE....
If that is A SUBROUTINE - there is no @ that I know of that returns the name of 
the currently executing routine.
The fact the CALLING routine knows the name is #1, is of no value to this 
request and #2, lends nothing to any routine being "self-aware".

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 
On Behalf Of Adrian Overs
Sent: Monday, May 12, 2014 7:58 PM
To: U2 Users List
Subject: Re: [U2] Read yourself

I totally agree with and endorse your programming standards David.
However if the program is calling another subroutine it should know the name of 
that subroutine or be able to derive it if it is called with an @.

Sent from my iPad

On 13 May 2014, at 10:45 am, David Wasylenko <d...@pickpro.com> wrote:

IT'S JUST NOT TRUE EVER.  @sentence cannot work.

The stub program that launched an initial program will be in the @sentence...
You could be 3 calls deep into external subroutines - there is nothing in 
@sentence re: the call-stack.
Our shop writes *very* few stub programs - most are subroutines called by other 
subroutines.

Instead:
Add     
   PGID="programName"
Or even
   PGID="filename  ProgramName"
To the top of the program - quick and easy.
Use of system routines such as SYSTEM(9001) is usually overkill.

Your program should be "aware" of it's name - if no other reasons than:
*  display on the screen to help users identify "where" their problem came from
*  print on reports
*  add to log-file entries
+ and of course, to answer the original question:  "how can I read the current 
program source"

A well-designed system/program should hard-code as little as possible as well.
What better key to use for a configuration record than the program name itself.


-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 
On Behalf Of Adrian Overs
Sent: Monday, May 12, 2014 7:39 PM
To: U2 Users List
Subject: Re: [U2] Read yourself

That's true - if the subroutines are catalogued with a noxref clause you're 
screwed. 

Sent from my iPad

On 13 May 2014, at 10:19 am, David Wasylenko <d...@pickpro.com> wrote:

Wont work --- if you use any external subroutines.

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] 
On Behalf Of Adrian Overs
Sent: Monday, May 12, 2014 7:18 PM
To: U2 Users List
Subject: Re: [U2] Read yourself

You can get the Program name by parsing @SENTANCE You can then read the Verb 
from the VOC and act on that or if the item is globally catalogued then read 
the 
last line from your catdir item 
> From unix level use strings $catpath/$item | tail -1 and then process that.
HTH

Sent from my iPad

On 13 May 2014, at 9:33 am, Adrian Overs <ove...@citysoft.com.au> wrote:

What problem are you trying to solve by doing so?
After all it's not rocket science (pardon the pun) to OPEN "BP" TO BP.FV THEN 
READ R.PROG FROM BP.FV, PROG.ID ELSE ... Whatever END

Sent from my iPad

On 13 May 2014, at 6:54 am, Wjhonson <wjhon...@aol.com> wrote:


Does anyone have a BASIC program, that will open it's own code in a variable ?
So something like this

GOSUB RETURN.A.LOCAL.FILE.AND.KEY.FOR.ME

READ THIS.PROGRAM FROM F.LOCALFILENAME, K.PROGRAMKEY ....

the program reads itself.

Does anyone have a program like that?


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

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

Reply via email to