How to run CHGPRTF on QSYSPRT in V6R1M0

15 pts.
iseries v5r4
In V5R4M0, we are able run CHGPRTF on Qsysprt. In V6R1M0, this file is always unavailable, it is use by QSYS in SCPF. Any way to run CHGPRTF on Qsysprt?

Answer Wiki

Thanks. We'll let you know when a new response is added.

<i>Any way to run CHGPRTF on Qsysprt?</i>

Not if it’s always in use.

Perhaps during restricted state, QSYSPRT might be available.

There should be no reason to change QSYSPRT since it should only be used by IBM functions. It is, after all, an IBM object. (Personally, I would only use QSYSPRT as a source for creating my own copy. That’s learned from hard experience in years past with other items.)

Of course, it’s commonly used by many sites for in-house purposes. That gives some validity to any complaint to IBM that you are unable to apply customization as you’ve done in the past.


Instead of changing an IBM object in Qsys you should have a library higher in the library list where you can duplicate the IBM object you want to change and then change the duplicate object. This way your changes won’t get stepped on as you do release upgrades.

Start by creating this library, if you don’t already have one. Then do a CRTDUPOBJ of Qsysprt. Change the duplicated print file, then change the System Value Qsyslibl to include your library ahead of Qsys.

Hope this helps,

Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Gkcover
    Thanks for the solution to use CRTDUPOBJ of Qsysprt. By the way, i tried in restricted state and it is always in use.
    15 pointsBadges:
  • wpoulin
    Gkcover, Even though it is in use, you still should be able to do a CRTDUPOBJ on Qsysprt. Hope this helps, Bill
    2,480 pointsBadges:
  • TomLiotta
    This way your changes won't get stepped on as you do release upgrades. {re duplicates higher in the library list} Be aware that release upgrades should 'step on' the modifications even though they won't. That is, you shouldn't rely upon an IBM object from one release to behave the same in a later release. Duplicates of objects can also duplicate behavior. IBM objects can and sometimes do become incompatible after release upgrades. All such customizations should be done through a CL program that creates a new duplicate and applies customization again after an upgrade. Perform the upgrade, then call your customization program to regenerate the customization of the objects. Update the CL whenever any new object is customized in this way. Even then you should work at removing all such references from any programs. If you have a program that uses QSYSPRT, create a second duplicate of QSYSPRT and give it your own name. Then start changing programs to use the new name instead. This can be one reference at a time or all at once. The duplicates with new names won't affect anything until programs are recompiled. Sooner or later, it will save some headaches. And once the references are gone, you won't have to worry about a whole class of problems again. Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: