Hi,

Our development environment typically contains object libraries like DEVLIB, TSTLIB, QASLIB and PRDLIB.

These libraries are cumulative in the way that DEVLIB only contains the changed objects, the same for the other libraries up until PRDLIB which contains everything.

This means that when promoting objects from one environment to the next, the objects get removed from the source environment (so that it becomes empty in case no other changes are pending).

I wonder if this concept is still used in modern development... or that each library contains the full set of objects ?

Looking for opinions on this.

Thanks,
Paul

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------

Hi Paul,

it depends upon your definition of "modern development".

Of course, "library list driven object retrieval" is still up-to-date in IBM i development. It has a more or less small security risk, that someone can fumble a malicious object somewhere into the *LIBL and compromise your system.

From the safety view, your construct depends upon the premise, that production, test and development are are located on the same machine - and that is a more or less big risk. One developer who runs a wrong program with the wrong library list, can ruin the day.

I've been there - and someone has done that - it wasn't funny at all. After that incident (and working for about 26h to restore everything to normal), it was quite easy to convince my boss, to pay for a separate development and test machine.

With SCM / CMS systems in place, you often switch to at least full copies for test and production - and partial copies for the development environment(s). But if you separate your prod, test and dev environments on different partitions/machines you need full copies anyway.

Because our dev box wasn't that big, I used a trick - I created empty versions of all historical and large transaction tables. And then I restored backups from production with the option to skip existing objects. This way we had everything we needed - but not at the full size. But this will not work with referential integrity (foreign keys) - at least it will cause some problems.

So finally - for me, I would say, it's OK to have partial object libs in the *LIBL - but from a security and safety POV, I would always try to separate production and test/development as far as I can - probably even rent an extra machine from the cloud.

HTH and kind regards,
Daniel

@Daniel Gross

Even with separate machines (which we do) there is still a risk.  Like testing a process to find out it emails all your customers.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------

Original Message:
Sent: Tue March 31, 2026 11:44 AM
From: Daniel Gross
Subject: Library structure/contents with modern development

Hi Paul,

it depends upon your definition of "modern development".

Of course, "library list driven object retrieval" is still up-to-date in IBM i development. It has a more or less small security risk, that someone can fumble a malicious object somewhere into the *LIBL and compromise your system.

From the safety view, your construct depends upon the premise, that production, test and development are are located on the same machine - and that is a more or less big risk. One developer who runs a wrong program with the wrong library list, can ruin the day.

I've been there - and someone has done that - it wasn't funny at all. After that incident (and working for about 26h to restore everything to normal), it was quite easy to convince my boss, to pay for a separate development and test machine.

With SCM / CMS systems in place, you often switch to at least full copies for test and production - and partial copies for the development environment(s). But if you separate your prod, test and dev environments on different partitions/machines you need full copies anyway.

Because our dev box wasn't that big, I used a trick - I created empty versions of all historical and large transaction tables. And then I restored backups from production with the option to skip existing objects. This way we had everything we needed - but not at the full size. But this will not work with referential integrity (foreign keys) - at least it will cause some problems.

So finally - for me, I would say, it's OK to have partial object libs in the *LIBL - but from a security and safety POV, I would always try to separate production and test/development as far as I can - probably even rent an extra machine from the cloud.

HTH and kind regards,
Daniel

Yes - that can be a problem. We used a sendmail-re-write on or mail server back then, which re-wrote every external recipient to an internal address. So the badest that could happen was, that a lot of internal users received a mail - no outgoing mails from the test-box.

Regards,
Daniel


Original Message:
Sent: 3/31/2026 1:11:00 PM
From: Robert Berendt
Subject: RE: Library structure/contents with modern development

@Daniel Gross

Even with separate machines (which we do) there is still a risk.  Like testing a process to find out it emails all your customers.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------

I'm not talking about database objects (it seems only logical to me that each environment has its own dedicated database).

I'm only referring to program objects... does each environment has its full set or do you cumulate by having multiple libraries in your library list.

Example, a test user has TSTLIB, QASLIB, PRDLIB, a QAS user has QASLIB, PRDLIB and the production only PRDLIB.

PS1. The PRDLIB in my example is also not the real production environment but a "digital twin" of the real production environment.
PS2. Not all companies have the luxery to have separate boxes for DEV, TST and QAS

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------

Original Message:
Sent: Tue March 31, 2026 01:10 PM
From: Robert Berendt
Subject: Library structure/contents with modern development

@Daniel Gross

Even with separate machines (which we do) there is still a risk.  Like testing a process to find out it emails all your customers.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------


Original Message:
Sent: Tue March 31, 2026 11:44 AM
From: Daniel Gross
Subject: Library structure/contents with modern development

Hi Paul,

it depends upon your definition of "modern development".

Of course, "library list driven object retrieval" is still up-to-date in IBM i development. It has a more or less small security risk, that someone can fumble a malicious object somewhere into the *LIBL and compromise your system.

From the safety view, your construct depends upon the premise, that production, test and development are are located on the same machine - and that is a more or less big risk. One developer who runs a wrong program with the wrong library list, can ruin the day.

I've been there - and someone has done that - it wasn't funny at all. After that incident (and working for about 26h to restore everything to normal), it was quite easy to convince my boss, to pay for a separate development and test machine.

With SCM / CMS systems in place, you often switch to at least full copies for test and production - and partial copies for the development environment(s). But if you separate your prod, test and dev environments on different partitions/machines you need full copies anyway.

Because our dev box wasn't that big, I used a trick - I created empty versions of all historical and large transaction tables. And then I restored backups from production with the option to skip existing objects. This way we had everything we needed - but not at the full size. But this will not work with referential integrity (foreign keys) - at least it will cause some problems.

So finally - for me, I would say, it's OK to have partial object libs in the *LIBL - but from a security and safety POV, I would always try to separate production and test/development as far as I can - probably even rent an extra machine from the cloud.

HTH and kind regards,
Daniel

OK - lets break it down step by step.

As long as you are working with your sources in QSYS, the *LIBL strategy will not make any problems.

With the switch to IFS sources - or even local sources and GiT - you have to think of

a) deployment libraries for the objects - depending on directories

b) source lookup paths for /COPY or debug - depending on the environment (prod/qas/test/dev)

If you have all your sources for one environment in one place - and also one deployment library for each directory - it's quite easy.

So, if you want to switch to such a "modern" environment with sources in IFS / Git repository and maybe checkout to the developers machine/notebook, you need to think differently.

We are also struggling with this right now. Our SCM does full copies for dev/test/prod environments - but we still try to figure out, how this will match with our strategy to move to VS code / IBM Bob this year and the idea, to also switch to Git.

HTH and kind regards,
Daniel


Original Message:
Sent: 4/1/2026 3:58:00 AM
From: Paul Nicolay
Subject: RE: Library structure/contents with modern development

I'm not talking about database objects (it seems only logical to me that each environment has its own dedicated database).

I'm only referring to program objects... does each environment has its full set or do you cumulate by having multiple libraries in your library list.

Example, a test user has TSTLIB, QASLIB, PRDLIB, a QAS user has QASLIB, PRDLIB and the production only PRDLIB.

PS1. The PRDLIB in my example is also not the real production environment but a "digital twin" of the real production environment.
PS2. Not all companies have the luxery to have separate boxes for DEV, TST and QAS

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------


Original Message:
Sent: Tue March 31, 2026 01:10 PM
From: Robert Berendt
Subject: Library structure/contents with modern development

@Daniel Gross

Even with separate machines (which we do) there is still a risk.  Like testing a process to find out it emails all your customers.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------

Whether the sources are in QSYS.LIB or the IFS is not relevant... finally they both compile to a library.

The main question is how travel the objects from DEV to PRD by using CI/CD (without a commercial SCM).

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------

Original Message:
Sent: Wed April 01, 2026 08:44 AM
From: Daniel Gross
Subject: Library structure/contents with modern development

OK - lets break it down step by step.

As long as you are working with your sources in QSYS, the *LIBL strategy will not make any problems.

With the switch to IFS sources - or even local sources and GiT - you have to think of

a) deployment libraries for the objects - depending on directories

b) source lookup paths for /COPY or debug - depending on the environment (prod/qas/test/dev)

If you have all your sources for one environment in one place - and also one deployment library for each directory - it's quite easy.

So, if you want to switch to such a "modern" environment with sources in IFS / Git repository and maybe checkout to the developers machine/notebook, you need to think differently.

We are also struggling with this right now. Our SCM does full copies for dev/test/prod environments - but we still try to figure out, how this will match with our strategy to move to VS code / IBM Bob this year and the idea, to also switch to Git.

HTH and kind regards,
Daniel



Original Message:
Sent: 4/1/2026 3:58:00 AM
From: Paul Nicolay
Subject: RE: Library structure/contents with modern development

I'm not talking about database objects (it seems only logical to me that each environment has its own dedicated database).

I'm only referring to program objects... does each environment has its full set or do you cumulate by having multiple libraries in your library list.

Example, a test user has TSTLIB, QASLIB, PRDLIB, a QAS user has QASLIB, PRDLIB and the production only PRDLIB.

PS1. The PRDLIB in my example is also not the real production environment but a "digital twin" of the real production environment.
PS2. Not all companies have the luxery to have separate boxes for DEV, TST and QAS

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------


Original Message:
Sent: Tue March 31, 2026 01:10 PM
From: Robert Berendt
Subject: Library structure/contents with modern development

@Daniel Gross

Even with separate machines (which we do) there is still a risk.  Like testing a process to find out it emails all your customers.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne


Original Message:
Sent: Tue March 31, 2026 11:44 AM
From: Daniel Gross
Subject: Library structure/contents with modern development

Hi Paul,

it depends upon your definition of "modern development".

Of course, "library list driven object retrieval" is still up-to-date in IBM i development. It has a more or less small security risk, that someone can fumble a malicious object somewhere into the *LIBL and compromise your system.

From the safety view, your construct depends upon the premise, that production, test and development are are located on the same machine - and that is a more or less big risk. One developer who runs a wrong program with the wrong library list, can ruin the day.

I've been there - and someone has done that - it wasn't funny at all. After that incident (and working for about 26h to restore everything to normal), it was quite easy to convince my boss, to pay for a separate development and test machine.

With SCM / CMS systems in place, you often switch to at least full copies for test and production - and partial copies for the development environment(s). But if you separate your prod, test and dev environments on different partitions/machines you need full copies anyway.

Because our dev box wasn't that big, I used a trick - I created empty versions of all historical and large transaction tables. And then I restored backups from production with the option to skip existing objects. This way we had everything we needed - but not at the full size. But this will not work with referential integrity (foreign keys) - at least it will cause some problems.

So finally - for me, I would say, it's OK to have partial object libs in the *LIBL - but from a security and safety POV, I would always try to separate production and test/development as far as I can - probably even rent an extra machine from the cloud.

HTH and kind regards,
Daniel

We cumulate too (I posted a previous message but is somehow missing). This usually allows devs to get a very high confidence and fidelity for the change when put live in production.

We use also a specific library (that you can call "the configuration layer" ) where all configuration for external dependencies are stored. i.e. email servers, ftp server, endpoints.

This solves the problem of the usual "I'm emailing all the customers from the test or qa, or send the edi message in test...". That you can also solve by decoupling producer and consumers (i.e. messages are posted to a queue, not consumed in the dev envs).

Also object like outq, dtaq are duplicated in the test lib and put on top (without a physical writer attached, back to what said above), this allows for easy testing also on an accurate print and routing workflow.

This allows for a super flexible layering system and really easy to think about compared to other Rube Goldberg style solutions.

We have dedicated programs to manage the library lists in what we call a list of "environment id". A user or dev can switch to a named environment (basically a LIBL, plus attributes, and that can change also depending on language parameter, i.e. to place or force different DSPF ) in less than a second.

Source management and versioning is irrelevant in the topic here, it is totally an orthogonal (one can use git etc.etc.).

------------------------------
--ft
------------------------------

Original Message:
Sent: Wed April 01, 2026 03:57 AM
From: Paul Nicolay
Subject: Library structure/contents with modern development

I'm not talking about database objects (it seems only logical to me that each environment has its own dedicated database).

I'm only referring to program objects... does each environment has its full set or do you cumulate by having multiple libraries in your library list.

Example, a test user has TSTLIB, QASLIB, PRDLIB, a QAS user has QASLIB, PRDLIB and the production only PRDLIB.

PS1. The PRDLIB in my example is also not the real production environment but a "digital twin" of the real production environment.
PS2. Not all companies have the luxery to have separate boxes for DEV, TST and QAS

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------


Original Message:
Sent: Tue March 31, 2026 01:10 PM
From: Robert Berendt
Subject: Library structure/contents with modern development

@Daniel Gross

Even with separate machines (which we do) there is still a risk.  Like testing a process to find out it emails all your customers.

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne


Original Message:
Sent: Tue March 31, 2026 11:44 AM
From: Daniel Gross
Subject: Library structure/contents with modern development

Hi Paul,

it depends upon your definition of "modern development".

Of course, "library list driven object retrieval" is still up-to-date in IBM i development. It has a more or less small security risk, that someone can fumble a malicious object somewhere into the *LIBL and compromise your system.

From the safety view, your construct depends upon the premise, that production, test and development are are located on the same machine - and that is a more or less big risk. One developer who runs a wrong program with the wrong library list, can ruin the day.

I've been there - and someone has done that - it wasn't funny at all. After that incident (and working for about 26h to restore everything to normal), it was quite easy to convince my boss, to pay for a separate development and test machine.

With SCM / CMS systems in place, you often switch to at least full copies for test and production - and partial copies for the development environment(s). But if you separate your prod, test and dev environments on different partitions/machines you need full copies anyway.

Because our dev box wasn't that big, I used a trick - I created empty versions of all historical and large transaction tables. And then I restored backups from production with the option to skip existing objects. This way we had everything we needed - but not at the full size. But this will not work with referential integrity (foreign keys) - at least it will cause some problems.

So finally - for me, I would say, it's OK to have partial object libs in the *LIBL - but from a security and safety POV, I would always try to separate production and test/development as far as I can - probably even rent an extra machine from the cloud.

HTH and kind regards,
Daniel

Good question... with the use of VSCode and the use of Git I do see a shift were people are using/promoting this as an alternative to a SCM.

In that context the way you handle different environments is also completely different (and I must admit still unclear to me) as with an SCM, hence the question.

If Git in combination with advanced build pipelines is an alternative for a SCM is yet another discussion (for me version control and change management are two distinct things, but should go hand in hand).

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------

Original Message:
Sent: Tue March 31, 2026 11:44 AM
From: Daniel Gross
Subject: Library structure/contents with modern development

Hi Paul,

it depends upon your definition of "modern development".

Of course, "library list driven object retrieval" is still up-to-date in IBM i development. It has a more or less small security risk, that someone can fumble a malicious object somewhere into the *LIBL and compromise your system.

From the safety view, your construct depends upon the premise, that production, test and development are are located on the same machine - and that is a more or less big risk. One developer who runs a wrong program with the wrong library list, can ruin the day.

I've been there - and someone has done that - it wasn't funny at all. After that incident (and working for about 26h to restore everything to normal), it was quite easy to convince my boss, to pay for a separate development and test machine.

With SCM / CMS systems in place, you often switch to at least full copies for test and production - and partial copies for the development environment(s). But if you separate your prod, test and dev environments on different partitions/machines you need full copies anyway.

Because our dev box wasn't that big, I used a trick - I created empty versions of all historical and large transaction tables. And then I restored backups from production with the option to skip existing objects. This way we had everything we needed - but not at the full size. But this will not work with referential integrity (foreign keys) - at least it will cause some problems.

So finally - for me, I would say, it's OK to have partial object libs in the *LIBL - but from a security and safety POV, I would always try to separate production and test/development as far as I can - probably even rent an extra machine from the cloud.

HTH and kind regards,
Daniel

Hello Paul!

IMO, the concept is not incompatible with modern methodologies.  We use an ISV supplied DevOps toolchain, with GitHub as our SCM.  Our DEV LPAR uses QA, Integration, and Reference (Production) environments. Feature branches in GitHub are processed into feature 'versions'  on the IBM i with component checkout resulting in source being transferred from GitHub to a version library native source file.  Once changes are ready for deployment to the QA environment, they are exported to the feature branch in GitHub, and merged into a release branch.  This fires a webhook to Jenkins that builds the release version on the IBM i,  imports that release into the deployment tool, and deploys to the QA environment. Subsequent deployments to the INT and REF environments do not leave the program objects in the lower environments.  After deployment to REF and over to our PROD LPAR, the Release branch in GitHub can then be merged into master.  As Heartland continues it's gradual move to more DevOps methodologies, this scheme will continue to work very well as we introduce CI/CD, test automation, etc.    

------------------------------
Todd Stewart
Application Architect
Heartland Co-op
Clive IA
------------------------------

I fully understand, the question is only how do you accomplish this ?

The main question, while normal SCM tools cover this for you, I'm now a bit lost on how to fill in this gap myself (and build complete CI/CD pipelines that handle this).

I wonder how many people can get this accomplished and based on what documentation because that's still very poor (except for some 30 second YT videos that don't explain anything).

------------------------------
Paul Nicolay
Architect
Cegeka
------------------------------

Original Message:
Sent: Wed April 01, 2026 08:25 AM
From: Todd Stewart
Subject: Library structure/contents with modern development

Hello Paul!

IMO, the concept is not incompatible with modern methodologies.  We use an ISV supplied DevOps toolchain, with GitHub as our SCM.  Our DEV LPAR uses QA, Integration, and Reference (Production) environments. Feature branches in GitHub are processed into feature 'versions'  on the IBM i with component checkout resulting in source being transferred from GitHub to a version library native source file.  Once changes are ready for deployment to the QA environment, they are exported to the feature branch in GitHub, and merged into a release branch.  This fires a webhook to Jenkins that builds the release version on the IBM i,  imports that release into the deployment tool, and deploys to the QA environment. Subsequent deployments to the INT and REF environments do not leave the program objects in the lower environments.  After deployment to REF and over to our PROD LPAR, the Release branch in GitHub can then be merged into master.  As Heartland continues it's gradual move to more DevOps methodologies, this scheme will continue to work very well as we introduce CI/CD, test automation, etc.    

------------------------------
Todd Stewart
Application Architect
Heartland Co-op
Clive IA
------------------------------