RE: Library attribute TEST or PROD -- MIDRANGE-L

Hi,

We still have the ongoing problem of everything being bound by copy. And, a rule that if a module gets changed, everything that that module was bound to must be recompiled.

Working on an LPAR dedicated to development, which is basically a copy of a production LPAR plus development libraries and test libraries.

Simulating installations on the development LPAR is becoming increasingly difficult because of more and more programs becoming <linked> by this <sharing> of modules. The size of QRPLOBJ is also a problem.

While awaiting the day for service programs to arrive, I thought I could at least help by not recompiling sources in development libraries during simulation of the installation process. I planned to therefore only compile the sources of libraries of type *PROD.

Has the value *PROD any other use than protection in mode debug?

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de rob@xxxxxxxxx
Envoyé : jeudi 30 avril 2009 14:46
À : Midrange Systems Technical Discussion
Objet : Re: Library attribute TEST or PROD

Illuminating on Martin's comments, I really see so fruitful
reason to make program libraries TEST vs PROD. That should
really only apply to data libraries.

While many people change STRDBG to UPDPROD(*YES) I wonder if
they would be better served if there was a common security
module used by most programs in the application (much like
BPCS SYS* family of programs) that would say "Oh, STRDBG is
active, let's retrieve information about a particular file
and if the library it's in is Production then tell it to
abort, if debug is not active and it's a Test library then abort."

What problem are you trying to solve? A standard way of
determining if a library is a "program" library versus a
"data" library? Now, let's take that a step further, what
are you going to do based on that information?

That's important information, but even if we do jump ahead,
if all of your data libraries have a standard file in them
you can always do something like this:
Select SYSTEM_TABLE_SCHEMA, SYSTEM_TABLE_NAME,
QCMDEXC('SAVLIB ' || SYSTEM_TABLE_SCHEMA || '
DEV(TAP01)') FROM SYSTABLES WHERE SYSTEM_TABLE_NAME='IIM'

Where you can build a UDF or User Defined Function, that will
call QCMDEXC passing it a command. We have, but not for this purpose.

Every system at V3R1 and above has SYSTABLES on it. It's in
QSYS2. And I forget what ancient release started putting
QSYS2 in QSYSLIBL library list.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
Martin Rowe <dbg400.net@xxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
04/30/2009 04:46 AM
Subject:
Re: Library attribute TEST or PROD
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

2009/4/30 David FOXWELL <David.FOXWELL@xxxxxxxxx>:

Hi,

I wanted to run some SQL on a table of libraries that I generated.

Basically, our libraries contain either data files or
compiled objects.

Eg for an application you might see a library calle APPLI containing

source files and program objects, etc and there'd be the
library APPLIF containing database files specific to that application.

I see that all libraries containing the programs have the attribute
TEST

and those containing the data PROD. Then there are temporary
developer's libraries that are PROD or TEST.

I'd like to be able to change all the program libraries to

PROD, and

the

development libraries to TEST.

Anyone know of a reason why I couldn't or shouldn't do that, and why

would the program libraries be of type TEST in the first place?

Hi David

The main difference that I'm aware of is when using debug: if
UPDPROD(*NO) is specified then files in PROD libraries can't
be opened for update. I find that handy when setting up
parallel environments to make sure I'm not picking up any
live files by mistake. I don't think it makes any difference
to programs - just the database files.

Regards, Martin
--
martin@xxxxxxxxxx http://www.dbg400.net AS/400 | iSeries |
System i Open Source/Free Software Debian GNU/Linux -
http://www.debian.org Foswiki - The Free Open Source Wiki,
http://foswiki.org/
--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.