Re: separate DEV, TEST, & PROD environments survey

Most, not all, of my clients run their systems with QTEMP at the bottom for the very reason Mike suggested. For most of them, QTEMP offers a place to store temporary results/objects that don't conflict with other object names. Therefore it's location at the bottom is fine, but remember it really does not matter as long as the applications don't need it in a specific position.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 9/8/2013 8:02 PM, Mike Cunningham wrote:

One possibility - application security. Not letting someone write a new version of one of their apps that calculates pay by naming it the same and putting it in QTEMP

-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth Martin
Sent: Sunday, September 08, 2013 8:52 PM
To: Midrange Systems Technical Discussion
Subject: Re: separate DEV, TEST,& PROD environments survey

I am trying to conjure up a scenario where having QTEMP at the bottom of the list would be useful. So far, nothing. What problem would HarrisData be solving, and how are they solving it, by having QTEMP at the bottom?

I am not making a judgement here; I am only hoping to expand my designing scope.


On 9/8/2013 6:50 AM,paultherrien@xxxxxxxxxxxxxxxxxx wrote:

> I have always worked under this same philosophy (Qtemp at the top of the
> LIBL), until I worked at a shop with HarrisData Payroll and Human Resources
> modules. The HarrisData support people stated unequivocally that QTEMP must
> be at the end of the libl or the HarrisData applications would not work
> correctly. So when I work with HD applications I make sure the JOBDs and
> LIBLs put QTEMP at the end of the list. For all other work I put QTMEP at
> the top of the list. And in some cases now, I may make explicit overrides
> to QTEMP objects where the environment cannot be reliably predicted.
>
> Paul
>