RE: Re: API location on V4Rx?

midrange-l-request@xxxxxxxxxxxx wrote:

>   4. Re: API location on V4Rx? (rob)
>
>I'm only half following this, but I thought I'd throw a FUD into the mix.
>Nothing obscure like you need some option of SS1 that's not on the other 
>system, is there?  Now, normally if this was the case, the whole service 
>program would be gone, not parts of it.

Rob:

No, nothing unusual. It's a little difficult when Simon says "No way." No need 
to elaborate on how much respect there is for him and I can't dispute what he's 
said.

Yet, my memory still goes to getenv()/putenv(). I had a need to pass some 
parm-like info down into a procedure a couple levels down and couldn't mess 
with any intermediate parm lists. In order to bypass the procedures in between, 
I figured I could put the info into an environment variable. The lowest-level 
proc could then check to see if that EnvVar existed and grab any value it might 
have without needing any interface changes anywhere in between. That's what I 
recall as the situation that started this.

Development was on a V4Rx system and it tested great. But when restored to 
V5R1, the APIs were in a different IBM *SRVPGM. And there went that idea.

Now, I cannot be certain it was getenv()/putenv(). I agree with Simon that it 
seems highly implausible for the same reasons he's given. Hmmm... unless...

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

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

(Of course, if Simon says "No way", why look? I sure might not.)

Tom Liotta


>Simon Coulter
>Re: API location on V4Rx?
>
>On 20/01/2006, at 12:35 PM, qsrvbas@xxxxxxxxxxxx wrote:
>
>> That is why I asked. I had programming developed on I think V4R4 
>> (maybe 4.5) and restored the *PGM to a V5R1 system. The restore didn't 
>> succeed in giving me an executeable *PGM because the APIs (exports) 
>> couldn't be found in the referenced *SRVPGM. It was necessary to come 
>> up with a messy workaround.
>
>That doesn't make sense. We use putenv and getenv all though some of 
>our code and have run the same *PGM objects on 440 to 530 with no 
>problems.
>
>Restore doesn't check exports. They are only checked during compile and 
>run. Provide the exact error messages from the job log.
>
>> My memory says it was getenv()/putenv() but I wanted to see if anybody 
>> could help. If those don't show up as I remember, then I'm going to do 
>> more digging to see if I can track down exactly what APIs were 
>> involved. Quite a while ago now, but it happened at the V5R1 upgrade.
>
>I don't recall anything special about putenv/getenv on 510.