× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well to drag this out a little more, it looks from my results that
Qp0zGetEnvNoCCSID/getenv
returns the *job level system environment variable, but is there a way to
retrieve the
*sys level variable value?

-----Original Message-----
From: bvining@vnet.ibm.com [mailto:bvining@vnet.ibm.com]
Sent: Monday, August 27, 2001 12:47 PM
To: RPG400-L@midrange.com
Subject: ILE program problem


Your code (with the "ExtProc('getenv')" change) compiles and works OK
on my V5R1 system.

However, I then took your program to a V4R1 machine and easily recreated
your failure.  What was not so easy was figuring out why getenv was
failing.

First, you picked a very unfortunate API to use with your first ILE
program.  It turns out that the C language runtime has historically
provided a function named getenv that always returns NULL without
really looking to see if the environment variable exists or not.
Assuming you are on a release prior to V5R1, this is the function you
are binding to and which explains why EnvData@ is not being set.

Under the covers, in the STDLIB C header file, V4Rx C programs that used
getenv where mapped to actually use Qp0zGetEnvNoCCSID which would
properly access the environment variable.  So for releases prior to
V5R1 (and still for V5 if you don't want to change), you should use:

DGetEnv           PR              *   ExtProc('Qp0zGetEnvNoCCSID')

and you should be up and running.  With this change your program
did correctly return the value of GALFLIBR.  Unfortunately, unless one
were to read the C header file you would never guess that this
renaming activity is taking place...

In V5R1 this situation is corrected, and the system exports the getenv
API (along with Qp0zGetEnvNoCCSID) so it's all very much more straight
forward.

Bruce

>
>I changed it with the same results. Is my syntax and are
>my declartions of the string variables kosher?
>
>>Are you sure you want external procedure GetEnv rather then getenv?
>>If you change your prototype to:
>>
>>DGetEnv           PR              *   ExtProc('getenv')
>>
>>you should find your environment variable.  You're off into Java land
>>with your current API call.
>


_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.