My RPG programs fields in the D specs that are set to initialize Example(D Fld1 S 1A INZ('Y') will work the first time the program is called but not on the second call of the same program.
Software/Hardware used:
AS/400
ASKED:
September 6, 2011 4:48 PM
UPDATED:
March 31, 2012 5:05 PM
I ended the program with an eval *inlr = *on and a ‘return’ after that. Maybe I need to drop the return op code.
I may be missing your point, is their another e=way of ‘CLOSING’ the program then the typical eval *inlr = *on and an ‘RETURN’ op code after that?
Are the fields in static storage or automatic storage? Use DSPPGM to view the ‘Program statistics’ section. What does the ‘Allow static storage reinitialization’ attribute say? Have you freed the program storage yet? I.e., has the program been deactivated or has the activation group been reclaimed?
Tom
is their another way of ‘CLOSING’ the program then the typical eval *inlr = *on and an ‘RETURN’ op code after that?
Yes, to keep a program memory resident the *INLR is not turned on..program ends when it encounters the RETURN or end of code. The *INLR may be in an If ..structure.
This isn’t a service program or a *NOMAIN module?
Pil
A HLL ILE program will remain “resident” until it is deactivated. For ILE RPG, *INLR doesn’t affect its “resident” status; *INLR affects closing of files and writing of data areas plus returning to the caller. For ILE, “returning to the caller” doesn’t get rid of the program from the job.
See the ‘Program Activation Creation’ topic and related topics in ILE concepts for some background. See the Deactivate Program (DEACTPG) MI builtin for related info about ILE programs in a default activation group (or perhaps the RPG/400 FREE op-code for OPM programs and note that RPG IV doesn’t include FREE). See the ‘Detailed RPG IV Program Cycle’ topic in the ILE RPG Reference and check note 2:
That is, the initialization routine is called on first call, not on second or later calls… that is, unless you have deactivated the program, usually by reclaiming the activation group (automatically done for a *NEW activation group and never done for a default activation group except by ending the job).
If you want reinitialization, then code for it with RESET. Or deactivate/reactivate the program.
Normally, there should be no problem if a field isn’t set to its INZ() on second call. An INZ() value really should have only a couple purposes. First, it should be a value that remains constant through the life of the program such as blanks or zeros in DS subfields that aren’t used for holding dynamic values. Second, it may indicate a kind of ‘first time’ condition; but a program really only needs a single boolean variable for that — it shouldn’t need to have to go through every variable.
In those cases, reinitialization shouldn’t be needed. If a variable isn’t being assigned dynamic values, its value will still be the same on the second call as it was initialized to on first call. If a ‘first time’ variable has been changed, then it’s not ‘first time’ on the second call.
For variables that do have dynamic value changes, the program should always set a valid value no matter what. Automatic initialization shouldn’t be involved.
In short, if reinitialization is desired, add a RESET at the top of the program as CharlieBrowne suggested. Better would probably be to code the program in a way that doesn’t need reinitialization and call it within an appropriate activation group structure.
Tom
I’m clearly missing something here. With the following program, both variables XChar and X are set to their INZ values on repititive calls to the program.
h dftactgrp(*no) d ds dXChar 1a inz('A') dX s 5s 0 inz(10) /free X += 1; dsply %char(X); dsply XChar; XChar = 'B'; *inlr = *on; return; /end-freeWhat am I doing/not doing that the original poster was/was not (and that everyone is evidently seeing)?
Thanks,
Bruce