Thank you guys.
I think now I have all the elements to solve my problem.
Marco
Il Sabato 18 Gennaio 2014 5:44, Peter Connell <Peter.Connell@xxxxxxxxxx> ha scritto:
I have avoided recursion by wrapping all the code in a mainline sub-procedure and specifying this procedure name in the MAIN H-spec keyword.
This causes the compiler to use a liner-main procedure (no RPG cycle) which allows the mainline procedure to call itself recursively.
Globally defined variables are shared between recursive calls.
Peter
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Saturday, 18 January 2014 4:19 p.m.
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: PSDS source informations availability
Perhaps reconsider correcting the issue with recursion and avoid entirely, the compiling of multiple programs from the same source code to implement some faux-recursion; i.e. modifying the code [and the means used to compile] to allow the recursive invocation(s) to function without errors.?
Pending transition to using message identifiers in a *MSGF, if that is an option, I would probably follow the previously alluded approach to "have my precompiler insert 3 constants while compiling the program".
Although it would seem two constants might be better; i.e. in keeping with the old design of program name and library name rather than changing the file.
Yet if it were me, and I was required to keep using a keyed data file design rather than transitioning to a message file implementation, I probably would use a simple scalar value and define an integer or a string constant in the source. Because obviously, the relationship is no longer with the program name and library, and without some other transitions in compile processing the relationship to the source member from which the object was created even may be somewhat tenuous. Why have a 20-byte or 30-byte key when the key values have a vitiated meaning, and the key might be as simple as a few bytes.?
Regards, Chuck
On 17-Jan-2014 12:48 -0800, Marco Benetti wrote:
I will try to explain better.
All my programs call a program to retrieve the translations of the
sentences used. I have a physical file where are stored the
translations of the sentences used by my program.
In the keys of the file there is the program name and library.
Until recently, I used the object name, but now problems have emerged
with the copies used to avoid recursion problems.
The copy of a program need to retrieve the same translation of the
original program.
So I decided to use the source member information.
I hope I explained myself more clearly.
Il Venerdì 17 Gennaio 2014 19:37, CRPence ha scritto:
On 17-Jan-2014 09:37 -0800, Marco Benetti wrote:
I try to explain my goal. All my programs have to call a generic
program that returns some information based on the name of the
source from which the program was compiled. So I need the source
information at runtime.
Seems an odd design. What does the correlation of source member to
run-time object achieve? What sort of effect comes from it?
<<SNIP>>
<<SNIP>>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
#####################################################################################
This correspondence is for the named person's use only. It may contain confidential
or legally privileged information, or both. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You must not disclose,
copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where
the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :-
Australia 1300-762-207 or New Zealand +64 9 367 6200
midrange.com
