Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Change default target release for compiles

Status
Not open for further replies.

SuzieW

Programmer
Dec 17, 2002
41
GB
Hi all

Our development box always used to be at the lowest OS release level of all our boxes (v4r5), however, when it died (!) we went onto a new (new to us) box which was on v5r1.

So now this means that when we compile, we have to change the target release level.

However, I was wondering if there was a way to set the default for all compiles to be at the previous release level.

I know that implementation tools (like Synon/CM and Thenon) can be set up to always compile at a given release level, but we do not use an implementation tool (I know, I know, it's not me who makes these decisions!).

So, is there a setting we can change in the compilers, so that we don't have to change TGTRLS every time?

I have googled and come up with nothing, so I'm guessing not :(
 
There is a couple of ways to do this:

1. use CHGCMDDFT to change the default on the compile commands.

2. (preferred) is to clone the command in a user library that precedes QSYS. Have your version insert the preferred default value, then call the QSYS version passing the TGTRLS with the desired parm.
 
I'm sorry,, but I am confused,, why does the OS release level make a different on a compile?? Maybe I have never run up against this problem, what are you doing that you need to compile a program at a lower OS release level?
 
arrow483 - those sound like good ideas, thanks

jmd0252 - we are deploying programs to production boxes which are on lower release levels. This is quite normal, I think. My old shop used to test out new releases on the dev box first so they would need to compile at a lower level for the production boxes, but this was all set up within the implementation tool.
 
Changing system defaults(TGTRLS)do have it's own pros and cons. Take our case as your example on why we don't change
our system defaults. We have several AS400. 2 as development box with slightly different release levels. 3 as production which are all on the same level. We have over 20 programmers who works on different applications and these apps only can
run on certain releases. Imagine what will be the reaction of these 20+ programmers when you changed the system defaults.

here's what we usually do when dealing with compiles:
1. It won't hurt changing TGTRLS if the compiles are few
1 or 2.

2. For bulk compiles, we use a cl to submit the compile or
if the program is from outside source then we use an ftp
command to send these pgms and included in the ftp are
as400 commands.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top