Re: Managing libl for multiple 3rd party products

Paul,

I should have mentioned that another rule was never to hardcode libraries. The two exceptions were TAATOOL and QTEMP, which were always qualified.

In my last shop, former developers has modified at least one TAATOOL command & CPP and had it in the production library list. TAATOOL added significant additional functionality to the command, but it couldn't be used except by finding all the places it was used and figuring out what had been changed in the CPP. But by qualifying the library in new code we could use the new functionality that TAATOOL provided without any fear of side effects.

Added bonus also is that we didn't have to worry about CHKTAARD.

Agreed, it might be a hard sell, but I still think it is the right way to go. Maybe others will chip in with comments.

Sam

On 12/2/2014 8:18 PM, Steinmetz, Paul wrote:

Sam,

Great if that works for your environment. We have a policy of never hardcoding libraries.
TAATOOL might be an exception, could be a hard sell.

From the TAATOOL install guide

" You should not copy TAA commands to a separate library. Either add TAATOOL to the library list or library qualify the use of the command such as TAATOOL/ADDDAT"
I tested TAATOOL/***CMD, I see the TAATOOL as the PRD library.

Run this on your system, let me know how many dups.
Use the CHKTAAPRD command with LIB(*ALL) to check for duplicate TAA commands and objects in non-TAA libraries.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Sam_L
Sent: Tuesday, December 02, 2014 5:50 PM
To: Midrange Systems Technical Discussion
Subject: Re: Managing libl for multiple 3rd party products

FWIW: For TAATOOL I have always set the rule that any use in production programs must qualify the command, e.g. TAATOOL/taacmd. And I never put TAATOOL in any production library list, which happily, and quickly, enforces the rule (typically when the source control program compile for deployment to production or QA fails. If your developers can compile directly into production, all bets are off).

This works well for the TAATOOL because all its commands use a product library. It means that there is no conflict between any TAATOOL command and any other command, or program the command calls, on the system.

I would expect that most third party software products use a product library on their commands. IMHO, the product library is a neat and practical concept. Of course, its usage may be hard to retrofit if you have a boatload of existing code...

Sam

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com