I would think anyone who understands and uses CGI would be aware of QTEMP being unique across job instances and would avoid the potential pitfalls by not assuming they can re-use a saved QTEMP value across CGI calls because of not being guaranteed to hit the same job instance each time if there is heavy traffic.

The only reason I asked the question is I wanted to make sure I wasn't missing any obscure changes that have happened in regards to sharing QTEMP in the past few years.

To me QTEMP has always been an IBMi strength, but you're also advocating against it as a staunch IBMi proponent. Not dangerous if used properly just like any other tool.

In .Net and PHP and other web platforms I tend to use session tables for any related info, so I understand the argument for using data backed sessions but you're de-advocating one the IBMi job strengths.

Just sayin...

I'll report back in on this once we find the root of the issue. Personally I think it's a programming thing since I've looked at the code and there is some value swapping and restoration going on for some reason within a single active call to the program. There is probably a logic flaw in how that was coded. Not be me :-)

Thanks for all the interesting responses to this question.

Regards,

Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

-----Original Message-----
I would think that the biggest problem with using QTEMP is that it is unique to the job - but the job will be reused.

Not an issue if the code restricts usage to a single request/response pair - but to me it is just a problem waiting to happen when some programmer down the road decides to rely on the thing still being there from a previous request.

Personally in CGI jobs I avoid QTEMP like the plague - once bitten ....


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.