Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Environment Variables...HELP!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Environment Variables...HELP!

    Anyone ever have any luck with 'putenv' / 'getenv' APIs? The putenv seems to work...I can check that the value was set with WRKENVVAR. The get ain't getting, though! The documentation says it returns a pointer to a string but no amount of contortions makes getenv work. Anyone ever use these? Have any ideas?

  • #2
    Environment Variables...HELP!

    The C header files map those APIs to some other functions. stdlib.h in QCLE has this code:
     #pragma map ( getenv, "Qp0zGetEnvNoCCSID") #pragma map ( putenv, "Qp0zPutEnvNoCCSID") 
    In RPG terms, this means
     D getenv PR extproc('Qp0zGetEnvNoCCSID') D putenv PR extproc('Qp0zPutEnvNoCCSID') 
    (I don't know why "getenv" doesn't work...) Barbara Morris

    Comment


    • #3
      Environment Variables...HELP!

      Just a guess, but are you remembering to null terminate the name argument? That is: eval Arg = %trimr(EnvVarName) + Null and then passing the Pointer to Arg. Note that trailing blanks (prior to the Null terminator anyway) can be a differentiator when searching for names.

      Comment


      • #4
        Environment Variables...HELP!

        That did the trick! I had tried Qp0zGetEnv but not Qp0zGetEnvNoCCSID. Funny how just plain getenv doesn't work. Thanks much. I had just about given up hope. Tom

        Comment


        • #5
          Environment Variables...HELP!

          Good point. I hadn't added *NULL to the end of the strings. For simplicity my envvars where "one=1" and "two=2" and I had sized the strings used for put/get exactly. The Qp0zGetEnvNoCCSID worked...I may go back and try plain putenv/getenv with null term. strings just for kicks.

          Comment


          • #6
            Environment Variables...HELP!

            To save handling the null terminators yourself, code the prototyped parameters and the calls like this:
             D getenv * extproc ('?') D parm * VALUE OPTIONS(*STRING) D env 32767a varying D p * C eval p = getenv ('PATH') C if p <> *NULL C eval env = %str (p) C endif 

            Comment


            • #7
              Environment Variables...HELP!

              Learn something new every day: C eval env = %str (p) I like that %str The real reason I'm checking into environment variables is I've been having trouble passing parms to a spawned program. I was advised to try using environment variables for this. The problem seems centered around the fact that spawn() passes parms C style int main(int argc, char *argv) which doesn't work out too well w/RPG. Then throw 'by reference/by value' into the mix. The spawn worked fine first time I tried it but now I want to get rid of the hard-coding and generalize it. Any ideas?

              Comment


              • #8
                Environment Variables...HELP!

                Huh, learn something new every day! I didn't know that SPAWN passed parameters using the C convention. I don't think there's a way to get RPG to handle those parameters since they're passed by value. You could also use a data area or data queue to handle your parms. Barbara Morris

                Comment


                • #9
                  Environment Variables...HELP!

                  Tom, were you able to pass environment variables on the spawn parameter list?

                  Comment


                  • #10
                    Environment Variables...HELP!

                    Tom or Barbara what service program do you have to bind to to use the APIs to get and set the ENVVAR. I looked in the docs and could not find an answer. This thread is a little old. Is it possible with V4R5 there is a QSYSINC member for the APIs?

                    Comment


                    • #11
                      Environment Variables...HELP!

                      I think the *srvpgm you want to bind to is QSYS/QP0ZCPA. As a general rule I use the QUSAPIBD binding directory that way I don't have to hunt down the srvpgm.

                      Comment


                      • #12
                        Environment Variables...HELP!

                        Tom, you shouldn't have to explicitly mention the QUSAPIBD binding directory. It's added for all modules automatically by the system. Paul, if you're getting binder errors, could you post them? Maybe you've spelled something wrong. If you're not getting binder errors, but just trying to prepare in advance, I think it's better to let the system find the service program if it can, and only explicitly mention a service program or binding directory if the defaults don't work. Regarding the header file, look in QSYSINC/H QP0* (that's a zero, not an oh). But as far as I can tell there's still no entry for Qp0zGetEnvNoCCSID and Qp0zPutEnvNoCCSID. Barbara

                        Comment


                        • #13
                          Environment Variables...HELP!

                          Thanks for the extra tip about the QUSAPIBD binding directory. I can see where it will save me a lot of time in the future. Not having to find the exact service program I would need each time is much simplier. Now if we could just get IBM to put members in QSYSINC/QRPGLESRC file for all the C APIs that would be great! ;-)) JJ(Just Joking) Don't be mad at me Barbara. Thanks again.

                          Comment


                          • #14
                            Environment Variables...HELP!

                            Since when do you not have to include the Binding Directory? Where is this documented so I can read up on it? Or if it is a quick note, what else is like this? (Automatically bound)

                            Comment


                            • #15
                              Environment Variables...HELP!

                              I thought you had to reference QUSAPIBD on the BNDDIR parm of CRTBNDRPG, too. Now if we could just get IBM to put members in QSYSINC/QRPGLESRC file for all the C APIs that would be great! Well that's a great idea...let's make it a joint project for everyone here in the forum.

                              Comment

                              Working...
                              X