DCHAR30           S             30A
     DMOVER            PR            30A
     DCHAR30                         30A   VALUE
      *---------------------------------------------------------------
      * MAIN - Main Code
      *---------------------------------------------------------------
     C                   EVAL      CHAR30 = 'ABCD'
     C                   IF        MOVER(CHAR30) = '
A+
     C                             BCD'
      * whatever
     C                   ENDIF

     C                   SETON                                        LR

      *---------------------------------------------------------------
     PMOVER            B
     DMOVER            PI            30A
     DCHAR30B                        30A   VALUE
     DWRKFLD30A        S             30    INZ(*BLANKS)
     DLEN              S              2  0
     C                   EVAL      LEN = %LEN(%TRIM(CHAR30))
     C                   EVAL      %SUBST(WRKFLD30A:31-LEN:LEN) =
%TRIM(CHAR30)
     C                   CLEAR                   CHAR30B
     C                   EVAL      CHAR30B = WRKFLD30A
     C                   RETURN                  CHAR30B
     P                 E

I believe this is allowed (can't recall the exact location, but one of the manuals discusses the implication that allocated memory is NOT freed on program termination). My understanding is that RCLRSC will NOT recover it either - you have to end the job to get it back! On that basis, I would use ACTGRP(*CALLER) with caution when calling from the default activation group. I limit it to small utility routines and the like, not large programs with lots of files etc. I'd be interested in hearing what other people do with respect to this issue - how many ILE programs with ACTGRP(*CALLER) are called from OPM, and has anyone had any noticeable problems or degradation? For new stuff, I've taken to creating CLLE with ACTGRP(*NEW) and RPGLE with ACTGRP(*CALLER), which can call other stuff such as service programs also with ACTGRP(*CALLER) ... then when the CL ends, the automatically generated activation group disappears automatically! Not sure whether this is a Good Thing (tm), but I prefer the idea of isolation of the program in its own activation group, with implicit clean up. Perhaps from a performance point of view, it would be better to use a named activation group ... so far, I've taken the view that it isn't too serious a penalty in the context of "user selects function x from menu", where a new activation group is created, but I wouldn't want to see a small subroutine create a new activation group each time it's called, for instance! Opinions??

---

Thomas, you CAN do prototyping, but just for program calls; you can't make bound calls in the dftactgrp. This is a restriction imposed on the compilers by the system. Apparently terrible consequences can ensue if is done by a bound call in the default activation group, and since the compiler can't tell what a called procedure might do, it can't allow any bound calls. (Sorry, I don't know what the is, and even if I did, I wouldn't be allowed to say). Barbara Morris IBM Toronto Lab RPG Compiler Development

---

just try to compile your program with DFTACTGRP(*NO) and ACTGRP(*CALLER) and your program will run fine, then. I do not know why but prototyping seems to be not allowed with DFTACTGRP(*YES). Can anybody enlighten this for us? You may decide to change the command default of CRTBNDRPG to match the values above. In addition you may set DBGVIEW(*SOURCE) in order to allow source level debugging of your programs. Last but not least you may change the default of STRDBG OPMSRC(*NO) to STRDBG OPMSRC(*YES) in order to allow mixed debugging of OPM and EPM programs. Be sure to compile your opm programs with CRTRPGPGM OPTION(*SRCDBG). By the way on my opinion it is a good idea to change the compiler from RPG-III to RPG-IV. It is not necessary to use the whole bunch of features coming with RPG-IV at once, although they are great, but make use of the enhancements of the language first and have a look the ILE concept, then.

---

It IS very effective. The code is much clearer than a MOVE/EXSR/MOVE and if you take the procedures outside of your main programm (put the D/PR-prototype in a /COPY member and import it if needed) into a service program. And putting this service program into a linker directory doesn't "cost" much time, and your procedures will be reuseable the next time, when you have the same problem. Read about it in the IBM redbook about ILE.

---

Thanks a lot for your help ! Worked perfectly ! I can, however, see that it's going to take quite a while to get into this new method of programming but it can prove to be effective.

---

The F22/F10-topic is discussed in the answers before mine. But even if you have used F10 it should havee worked. Your program should have gone thru the then-part of you if statement. But the field CHAR30 is not changed in any way!!! You have used the value-keyword on your PR/PI-D-specs, and so the value and not a reference to the parameter is given to the procedure. You can change this parameter in your procedure, and the original field in the caller has it's old value. But the return statement at the end of the procedre should give you a proper result. So look at it is this was: With the return-statement, the complete procedure/function-call in your eval/if/or-what-soever-statement is "replaced" with the return-value. When you use a normal (not-value) parameter, the orginal field is changed, but when you do no return, you have no "replacement" value for your procedure call. This sounds silly, but having a little knowledge of C/Java/Pascal/or-what-soever is quite good, when you are new to the RPG/IV procedures. The are very similar to procedures/function/methods in other languages. You can even use them recursivly. So try a bit more around, and use the F22-step-into key in the ILE-debugger, so you can see what happends. If you want to see the result of your function-call (the return value) put a "Eval xxx = YourFunc(param)" in your code, and you can see the result in xxx.

---

Did you remember to use F22 to step into the subprocedure?

---

This will compile into a pgm object but if I step through it in debug, it doesn't take me to the 'C' specs in the procedure. What I'm trying to do here is invoke the procedure through the EVAL expression & right-adjust whatever contents may be in field CHAR30 but if I EVAL the field after it should have been through the procedure, it is still 'ABCD'.

---

Could you be more specific as to what doesn't work. Does the compilation fail, or does the program fail, or …

---