Re: API location on V4Rx? -- MIDRANGE-L


On 21/01/2006, at 1:06 PM, qsrvbas@xxxxxxxxxxxx wrote:

Maybe Simon did it correctly in the first place, usingQp0zGetEnv()/Qp0zPutEnv() rather than getenv()/putenv() in which casehe ~possibly~ wouldn't have seen the behavior I saw. I recall thatQp0zGetEnv()/Qp0zPutEnv() did ~not~ change as getenv()/putenv(),hence, probably no problem with them.

We were using the putenv/getenv calls because they were being done fromC. putenv/getenv are more natural from C than the actual IBMimplementation functions--hence being part of stdlib.h.

Note that I said these were mapped to Qp0zGetEnvNoCCSID() andQp0zPutEnvNoCCSID(). Both the Qp0zGetEnv() and Qp0zPutEnv() require aCCSID value and are an IBM extension to the standard interfaces. Thesewere introduced in 360 (according to the documentation) so wereprobably part of the original migration from the CPA toolkit to thebase OS.

Maybe my previous point wasn't clear enough. According to the Cincludes there never was a function named putenv() prior to 510. Therewas a getenv() in QC2UTIL2. The function prototypes exist on 440 butthey are mapped to the real functions as follows:


        #pragma map ( putenv, "Qp0zPutEnvNoCCSID" )
        #pragma map ( getenv, "Qp0zGetEnvNoCCSID" )

On 510 (and I presume 520) when TGTRLS is specified for earlier than510 this remapping also occurs. If no TGTRLS is specified or compilingoccurs on 520 or 530 the remapping no longer happens and IBM haveprovided direct implementations of getenv() and putenv(). I have noidea why they added these new direct implementations--the previous Qp0zvariants seem fine.

It comes down to the best protection for backwards/forwardscompatibility. If I can track down what APIs were involved, I'll haveone more solid data point. If someone with V4Rx can actually look forthem, it will help.

I do have 440 on one of my systems and I did check the serviceprograms. The Qp0z variants are exposed from the QP0ZCPA. There is noputenv or getenv exposed in this service program until 510. Further Iwrote some code to list the procedure exports from every serviceprogram in QSYS on 440 and none of them export putenv(). I did findthat QC2UTIL exported getenv() but given what I say above about theremapping this export would not have been called by anything compiledon 440. It appears that getenv() has been available since 230 butputenv was not provided until much later expect as part of the CPAtookit. The only other related exports I found are the Qp0z variants.

So what this means is that if you compiled C code on 440 theprecompiler would have remapped the putenv and getenv calls to thecorrect implementation function. This compiled object would havecontinued to run on all later releases with no changes. If you compiledC code on 510 or later (and did not specify a previous target releaseearlier than 510) the program object would invoke putenv() and getenv()functions directly. This object would continue to work on 520 and laterreleases.

If you tried this from RPG IV on 440 then you could not possibly havebeen calling putenv() directly because it did not exist--unless youwere binding to the old CPA service program and Bruce has alreadyexplained where that went. You may have been calling getenv() andbinding to QC2UTIL2 and this may have failed to compile at 510 becausegetenv() is no longer in QC2UTIL2. It would have had to be removed orrenamed to avoid duplicate procedure export errors caused by collisionwith the new getenv() exported from QP0ZCPA.


Perhaps it is this getenv() change you recall?

Now this is a perfect example of the backwards-compatibility IBM isjustly famous for: Instead of simply removing getenv() from QC2UTIL2they renamed it to getenv_a(). This means that any C code that wasoriginally bound to QC2UTIL2 will continue to work due to the fact thatprocedures are invoked by address (via their ordinal position in theexport list). They will actually invoke getenv_a() but will behaveexactly as expected.

Any RPG IV programs that were also bound to QC2UTIL2 should behave thesame way so again even if this is the change you recall it should nothave caused your program to fail to run. It may have caused failure tocompile but that is a different issue.


Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------