Controlling Adopted Authority

By Rich Loeber

IBM i programs have a setting when compiled that controls the user profile that will be used for security reasons when that program runs.  You may think that your security configuration is all set and that you’ve made a final determination as to which users are allowed to have access to what objects on your system.  But, if a program on your system is compiled with the USRPRF attribute set to *OWNER, then all your preparation work may be out the window.

The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems.  This is the way it comes from the factory although it is easy for the default setting to be changed.  When programs are compiled with the *USER setting, then you can count on your object security setup to provide the proper control over access to objects on your system.  When this gets changed, however, then the access controls are based on the owner of the compiled *PGM object and not on the user profile of the person that is running the *PGM object.  (Note: This also applies to *SQLPKG and *SRVPGM objects, but for the purposes of this article, I’m just referring to all of these generically as “programs”.)

This situation is called adopted authority.  There are lots of good reasons why you would want to do this.  For example, you may have a CL program that creates backups of your system that is run by your night operator.  You may not want your night operator’s user profile to have all object authority, so you compile the CL program under a user profile that does have all object authority with the USRPRF parameter set to *OWNER.  Then, when the night operator runs the backup, it goes off without a hitch.  While the backup is running, it has access to the objects needed to complete the backup but the night operator profile is still restricted.  A lot of third party software developers use this technique to make sure that their programs can run without authority problems.

To make sure that your security is not being compromised by adopted authority issues, you should do a periodic review of programs that use this technique.

The first step is to identify the user profiles in your system that have all object authority.  This step alone might produce some interesting results that will surprise you.  One quick way you can do this is by running the following command:

DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/USRPRF)

This will create a temporary physical file named USRPRF in your QTEMP library.  Once created, you can scan this file for the value *ALLOBJ in the first 7 positions of the field designated as UPSPAU.  Any query tool that you like should give you a quick report on what you’re looking for.  Check each profile listed to make sure there are no surprises.

Then, to see if there are any programs that adopt any of the profiles on your list, use the DSPPGMADP command for each profile.  This command supports on-screen display, print and *OUTFILE output.  Use the form that best suits your needs.  At a minimum, you should check for programs that adopt the QSECOFR user profile.  The command to review this looks like:

DSPPGMADP USRPRF(QSECOFR)

Once you have identified programs that run under a user profile that has all object authority, you should then determine if the requirement for adopted authority is absolutely necessary.  In some shops where I’ve worked, I have identified programs adopting the QSECOFR profile because it corrected a problem during testing and was just left that way in production.  One obvious problem would be if the program in question has an option to present the user with an IBM i command line.  In this situation, the user then has full access to your system that goes right around your careful security setup plans.

For third party software, contact your software provider and ask about the adoption situation.  A good software provider should have a ready answer for this question.

When you’ve identified a program that needs to be changed, you don’t need to recompile to make the change.  A simple Change Program command will work in most instances.  Use the following command to change from adopted authority to user authority:

CHGPGM PGM(MYLIB/MYPGM) USRPRF(*USER)

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Checking System Integrity

By Rich Loeber

Much has been made over the years about the robust security features of the IBM i OS.  Those of us who have been working with the system since day one, along with all those who have jumped on the bandwagon since 1988, have experience with the depth of security features that are available to us.  IBM continues to proudly tout the IBM i as a highly secure environment and one that has been very resistant to virus and tampering.

So, it was with some surprise when I found the CHKOBJITG (Check Object Integrity) command on my system.  If the IBM i OS is so secure, what’s the deal with this command?

The stated purpose of the command it to check objects on your system for “integrity violations”.  Thinking that my system should be in pristine condition, I ran a quick analysis.  Running the analysis is simple; it creates an *OUTFILE with the results of the analysis that you can then either view or run a Query report against.  I was surprised to find several items on the report listed under my user profile name.  Looking closer, however, I found that they were listed simply because they had never been converted for RISC use (showing the age of objects on my system).  Whew, I’m off the hook!

The CHKOBJITG command scans your system for the following situations:

  • Commands that have been tampered with
  • Objects with invalid digital signatures
  • Objects with an incorrect domain setting for the object’s type
  • Programs and/or modules that have been tampered with
  • Library attributes that have been tampered with
  • Objects that failed a file system scan

If any of these situations are identified, a record is logged to the output file.  A violation code is posted in the record and you can use the HELP key on the command to get a list of these codes and their meanings.  Keep in mind that if no violations are found, the outfile is not created.  Also, your user profile must have *AUDIT special authority in order to be able to use the command.

Additional items can also be logged to the output file, such as those found on my system.  These additional categories are not integrity violations per se, but can be taken as warnings.  These include:

  • Objects that do not have a digital signature, but could
  • Objects that could not be checked
  • Objects that cannot be run on this system without format changes

Those items on my system fall into this last category.  Objects that cannot be checked would include *PGM objects that are in debug mode, items that were saved with the storage freed option, compressed objects and damaged objects.

The current implementation of the command has the ability to scan objects in any directory or path, which may be helpful for locating problem objects in the IFS.  Earlier implementations only checked the QSYS file structure for problems.

I would love to hear from anyone who has used this command on their system and discovered any surprises.  Years ago, I knew of one IBM i programmer who was able to get user programs to run in system state so that he could “do things” at the system level, but I know he’s retired now.  It would be interesting to me to know if there are objects on user systems that get reported and the stories that lie behind those objects.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Limiting When A User Profile Can Be Used

By Rich Loeber

Each user profile on your system is a window, of sorts, into the computing environment for your business.  Some profiles have a very narrow and limited view while others have a panoramic scene before them.  Some profiles can only look while others are allowed to look, pick things up, move them around, make changes and even throw them away.  Some only have access to a single library while others, perhaps even you, have the keys to the Kingdom.

As a security officer, you’ve probably given this a lot of thought already and you already have your profiles set up with the exact permissions necessary.  Users are allowed enough access to fulfill their job descriptions but not so much that they can wreak havoc for your organization either accidentally or intentionally.  And, to a large extent, your trust of the person behind the profile plays a large roll in how much access you give them to your system.

Problems come up, however, when a profile is compromised and is used by someone other than the assigned person.  When this happens to a profile that has the panoramic view of your system, real trouble can ensue.

The IBM i OS on your IBM i system has a nice little feature that can give you improved control in the event of a compromised profile.  This feature, the Activation Schedule, lets you specifically tell the system what days and what hours in the day that a profile can be used.  If a user profile is compromised, the chances are very good that the incorrect use will be attempted during off hours.  If the profile in question has been posted to the system Activation Schedule, the profile will not be available for use during the off-hours time frame.  This extends not only to terminal session signon but to all server activity, such as FTP, the system file server, etc.

There are two commands that you use to maintain the system Activation Schedule.  The “Change activation schedule entry” command (CHGACTSCDE) is the main command for maintaining the schedule.  This lets you add a user profile to the list or change a profile that is already on the list.  Once a profile is on the list, a message will be sent to the user profile that established the entry each time the profile is activated and deactivated.  When you create the entry, you specify the time of day when you want the profile available for use.  The system will activate the profile at the given time and then automatically deactivate it at the closing time that you enter.  You can specify this time for all days of the week or for given days of the week.

The other command that can help you with this is the “Display activation schedule” command (DSPACTSCD).  This command lets you review how your Activation Schedule is set up.  You can look at it interactively or create a report of the schedule.

When you first set this up, nothing will happen right away, so be prepared for that.  The system will post jobs into the IBM i system job scheduler to do the actual activation and deactivation.  The next time one of the time of day thresholds is passed, the activity to activate and/or deactivate users will start and you will begin to receive status messages from the system.

Using this feature of the IBM i OS, you can close the window of opportunity when a compromised profile can be used and make it more difficult for mischief makers to do their thing on your system.  One thing to keep in mind, if you adopt this process, is that you may need to make special arrangements when your users work a different schedule than normal, such as overtime work.  During these times, you may have to update the Activation Schedule to accommodate different work hours.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Standardize Security Across Multiple Systems

By Rich Loeber

Nothing supports the popularity of the IBM i as much as the number of customers with multiple systems installed.  These can be either multiple partitions on a single box or separate boxes.  For security officers, this can easily mean a lot of extra work keeping each system setup and configured for company security policies.

While this can be a complex task, IBM has provided an little known capability in the IBM i OS for quite a while now that can help you to enforce standard security configuration setup rules across separate systems.  This is through the use of the CFGSYSSEC (Configure System Security) command.  This command, which has no parameters, calls a CL program named QSECCFGS in the QSYS library.  This program sets the security related system values to standard settings recommended by IBM.

The good news for the security officer with multiple systems to control is that this CL program can be changed to meet your unique setup requirements.  The base program as shipped with IBM i can be retrieved and then modified for your unique needs (not unlike the way the system startup program QSTRUPPGM works).

To retrieve the CL program, just run the following command on your system:

RTVCLSRC PGM(QSYS/QSECCFGS) SRCFILE(mylib/QCLSRC)

This will place a source member in your QCLSRC source physical file named QSECCFGS.  To be on the safe side, you should probably rename this and, when you recompile it, place the new compiled program into QUSRSYS.  Once this is done, just change the IBM i CFGSYSSEC command to run the your modified program from QUSRSYS with the following command:

CHGCMD CMD(QSYS/CFGSYSSEC) PGM(QUSRSYS/myseccfgs)

When you review the CL program source that has been retrieved, there is some housekeeping that takes place early in the program.  You can review the settings imposed by the program after the housekeeping to see how IBM recommends your security setup and make changes that will implement standard security settings for your own requirements.

To implement the standard security setup across your multiple system environment, simply install your custom setup program on each system in your network and modify the CFGSYSSEC command on each system to call your modified program in place of the IBM default program.  To guard against possible changes being made to the setup, you can even add this to your automatic schedule to run on a weekly or even daily basis to keep these setting enforced.

The retrieve CL program is a little tough to read, but perseverance will prevail.  If you need help with it, let me know what you need specifically and I’ll see if I can help.  If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Using Authorization Lists

By Rich Loeber

When designing security for your IBM i system, there are lots of things you can do to simplify the task and keep maintenance of security settings to a minimum.  Some of these include implementing group profiles and supplemental group profiles.  Another important one is using Authorization Lists.

An Authorization List is a special system-level object that resides in the QSYS library with object type *AUTL.  Your system can contain multiple Authorization Lists and it is recommended that they be created along application boundaries.  So, one list could be used for Payroll while another list can be used for Inventory, and so on.

An Authorization List simply defines user authority for objects that belong to the list.  When an object is created, rather than creating individual private authorities to the object, just associate it with the appropriate Authorization List.  The List, in turn, will control individual and *PUBLIC authority to all of the objects in the list.

Using an Authorization List will simplify setting up new users and maintaining object authority on your system.  It also has some nice side benefits.  The individual size of user profiles is kept much lower using Authorization Lists.  Also, system performance is improved when running SAVSYS backups and when saving security information on your system with the SAVSECDTA command.  But, one of the most significant advantages is that security changes can be made to a list even when objects in the list are open and active on your system.  This means that you can make security adjustments on your system even when the applications are active and running.  Conversely, when using private object authorities, you can only make security changes when the file is not in use.  This alone can save you loads of headaches and late night sessions on your system.

To get started with an Authorization List, you first need to create the list using the Create Authorization List (CRTAUTL) command.  Be sure to set the *PUBLIC authority level using the AUT parameter.  Once it is created, you can work with it using the Edit Authorization List (EDTAUTL) command.   Using this command, you can add individual users who will need more authority than is allowed by the *PUBLIC authority setting.

Once you have the list configured, it is time to use the list on the objects you want it to control.  You can grant authority via the list using the Grant Object Authority (GRTOBJAUT) command.  Remember that only one authorization list can be used to secure a specific object.  If you are implementing Authorization Lists on a system where private authorities were previously used, you might want to also use the Edit Object Authority (EDTOBJAUT) command so that you can also remove any private authorities that are now taken care of by the Authorization List.   You can also add new users to the list by a simple Add Authorization List Entry (ADDAUTLE) command.  Each individual entry in the list will control the level of authority that user is given to the object.

Remember that a private authority to an object will override the authority provided by the Authorization List.  If you are converting your security setup over to use Authorization Lists, this will be an important consideration.  A private authority will also override a group profile setup, so this is something that will be important to review and check as well.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Search For The Guilty Party

By Rich Loeber

Part of computer security is prevention, and a good access prevention policy along with good controls will go a long way to protect your data from improper access and use.  But, people with proper authorization make incorrect data changes that can wreak havoc on a system.  At times like that, it is sometimes nice to be able to backtrack and see who did what and when they did it.

Here is an easy way to implement a tracking system on an IBM i database without any significant programming on your part.  This technique takes advantage of the IBM i database audit journal features.

First, you have to create a Journal Receiver and a Journal.  In this example, we’ll set up to track data changes to a file named CUSTMSTR in library MYLIB.  Use the following commands to create these objects:

CRTJRNRCV JRNRCV(MYLIB/CUSTMSTR)

CRTJRN JRN(MYLIB/CUSTMSTR) JRNRCV(MYLIB/CUSTMSTR)

Now, you can activate tracing on your physical file by processing the following Start Journal Physical File command:

STRJRNPF FILE(MYLIB/CUSTMSTR) JRN(MYLIB/CUSTMSTR) IMAGES(*BOTH)

At this point, the database journal is active for your file and all activity against that file will be tracked and captured in the Journal Receiver.  Now, use your application program to work with your database file.  Make some file inquiries and also perform some record changes.  When you’re done, use the following command to take a look at the file tracking information:

DSPJRN JRN(MYLIB/CUSTMSTR)

You will see several different forms of tracking information displayed.  Each time the file is opened, closed, read and updated, an entry will be inserted.  The first few entries just track the fact that journaling has been started for the file.  After those, you will see the results of the testing transactions that you performed.

To review file changes, look for the audit records with type codes “UB” and “UP”.  The UB record shows you a record image BEFORE an update was posted and the UP record shows the record image AFTER an update was posted.

In your search for the guilty party, the DSPJRN command leaves a lot to be desired.  To give you a better way to look at before/after data changes, you can transfer the DSPJRN information into a database file and then use your favorite database tool to create more usable information.

To create the database for your query tool, run the following form of the DSPJRN command:

DSPJRN JRN(MYLIB/CUSTMSTR) OUTPUT(*OUTFILE) +
OUTFILFMT(*TYPE4) OUTFILE(MYLIB/CUSTMSTRJ)

In this sample, the database version of the Journal now resides in the database file named CUSTMSTRJ.  Use your query tool to select records with type codes UB and UP (the field name to select on is JOENTT).  If your database file record length is exceptionally long, you may have to parse the record data information to get at what you are looking for, but the report generated should point you to all of the record changes posted to the file and you should be able to sort out who did what and when they did it.

If you prefer an easier way to handle all this, take a look at iFileAudit from Kisco Information Systems.  iFileAudit will automate this entire process and show you file updates on a field by field basis telling you all of the who, how, when and where information as you search for the guilty party.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

 

“i Spy” – Checking up on a specific user

By Rich Loeber

For some reason, my career in Information Technology frequently included responsibility for the company telephone system.  Oftentimes, I would end up with a department head closeting himself in my office to obtain a report of telephone activity for an employee that they suspected of some malfeasance.   Most of the time when this came up, I had the luxury of having the data already collected in a call accounting software package and could just run a report and send the department head on their way.

In this day of heightened security consciousness, I can fully expect to see this scenario played out with data access as the expressed concern of this same department head.  Unfortunately, software for full implementation of security reporting can be very pricey.  But, if you just want to check up on someone, the IBM i has very good auditing capabilities that you can use down to the individual user level.  And, you can do this without a major headache.  You can target a specific user and leave the others out of it.

Setting Up Security Journaling

The IBM i OS lets you track a lot of different system security events and you can explore all of these in the OS Security Reference manual.  For our purposes, however, all we’re looking at it how to set up security auditing for an individual user.

If you have already used audit journaling, you can skip to the next heading in this tip.

To start security audit journaling, you can use the IBM i CHGSECAUD.  For our purposes, you can use the following command:

CHGSECAUD QAUDCTL(*OBJAUD *NOQTEMP *AUDLVL)

If your audit journal does not exist, this command will set up the journal receiver and create the system audit journal.  Two system values will also be updated.

Journaling Your User

Now to start tracking your suspicious user.  First, you’ll want to start auditing for the specific user.  You can do this with the following command:

CHGUSRAUD USRPRF(USERNAME) OBJAUD(*ALL)

You should key in this command and prompt it to see if there are additional events that you want to track in the AUDLVL parameter.   You should probably include *CREATE and *DELETE options at a minimum.

The final step in your setup is to specify user audit tracking for the set of objects that you want to track for this user.  You can do this with the CHGOBJAUD command.  For user profile audit journaling to work, the objects must be set to OBJAUD(*USRPRF).

Viewing the Audit Information

Once you have the audit journal active, you can view the tracking information on-line using the following command:

DSPJRN JRN(QAUDJRN)

If you have an active audit journal with a lot of activity for many users, you can limit the information displayed by using the USRPRF parameter.

As with all security matters within the IBM i OS, this is tip just scratches the surface.  You can see more information in the IBM i Security Reference manual.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Drive The Boat!

By Rich Loeber

Sometimes, we get so wrapped up in what we’re doing down in the security trenches, that we loose sight of the overall objectives.  When that happens, bad things can occur.

I have mentioned before that we live in a remote community deep in the Adirondack Park in upstate New York.  Our house is on one of the larger lakes and that lake is interconnected with a huge system of creeks, streams, smaller lakes and ponds.  It is a canoeist’s dreamworld.  On a recent weekend, my wife and I packed off for an 8 mile paddle with a break for lunch in the middle.  It was a beautiful day and the trip was great, until the end.  On our return, when we left the protected creek that we’d been traveling on, we saw every canoeist’s nightmare; a powerboat pulling a water skier headed straight for us.  The boat had the required two people in it, but they were both looking backwards at the skier.  It was the skier who finally saw us (as I was waving my paddle furiously in the air) and motioned to the driver to look around.

What was wrong is that the driver forgot his primary objective.  He should have been driving the boat, not watching the skier.

After I settled down from this, and survived the wake from this close call, it occurred to me that when we get down in the trenches in our job as security officer, that we too can easily forget to “drive the boat”.

What do I mean by this?  I mean your overall corporate objectives.  Why are you in business?  What’s your end product?  How is it getting delivered?  What is your place in the process?  Is what you’re doing helping to meet the objectives?  Or, if you’ve forgotten to “drive the boat”, is what you’re doing making it harder for everyone else to keep on track?

Often, in our zeal to keep things safe, we make it hard for everyone else to just do their job.  If that’s happening in your shop, I’d take a second look at what you’re doing.  Security should be done in such a way that legitimate users (your customers) should be able to do their job without having to jump through any hoops, not even little ones.  At the same time, you need to be able to identify risk areas and set up an environment where unauthorized users cannot easily get to automated company assets.

So, how do you know how you doing?  I’d start with checking on your phone calls and end user email.  What’s the most common complaint in the last few weeks?  If you get a lot for the same reason, then this might be an area where you need some attention. For example, do you have situations where you require multiple logons to gain access to your system.  Each additional logon takes time and is not very productive.  If your risk assessment is fairly low, look at ways to implement a single signon.  Do you often get calls from users who can’t access some bit of data that they need?  If so, it might be time to reassess your data access policies to bring them up to date.  Every time someone has to call to get a security change implemented, they aren’t “driving the boat” and the results could be very bad.

I’d love to hear your war story along these lines.  If you have a good one, send it in and I’ll collect and publish them at some point down the road.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

The Enemy Within

By Rich Loeber

For many, this has been a hard year.  In many IBM i shops, we have been forced to find new ways to save on expense while still being asked to provide the same level of computing support as in past years.  This is not always easy, and I have seen evidence that some shops are sacrificing security to conserve on their budgets.

One significant area where I’ve seen this is on data asset protection.  More than one shop that I’ve been in touch with this year has decided to put their complete trust for data asset protection into their firewall at the expense of all other ways of protecting their data.

With your system attached to a network on a full time basis, and with the network interconnected to the Internet on an around the clock basis, trusting your data protection to a single piece of technology is just a bad idea.  Imagine yourself living in a neighborhood with a high crime rate.  Would you have a single lock on your door?  Like most people in this situation, wouldn’t you use two or three (or even more) methods to keep your doors and windows secured?

When your system is connected to the Internet, you are in a high crime neighborhood and you need to use the same approach to protecting your data.  When someone breaches your single point of protection, that could leave your entire system open to malicious abuse.

Also, trusting your data protection to just a firewall completely ignores the issues of intrusion from sources within the “protected” network.  In a small shop, where you can see who is in and who is doing what, maybe this is not much of a concern, but in today’s large shops with widespread deployment of networks, you cannot keep an eye on what everyone is doing.  Anyone who is within the “secure” network can find access to your system using a variety of tools available to today’s savvy computer users.

If you have deployed your firewall as your primary defense against intrusion, you are completely ignoring the enemy from within your organization.  Most security experts will tell you that at least half of all intrusions today (some say more) come from within your organization.  With the ease of downloading data and storing it in a convenient portable form, anyone in your organization could easily take home critical data assets from your organization on a laptop or even on a USB drive that looks like a key fob.

The question you need to ask yourself is, am I saving money wisely or am I thinking short term just to look good.  In today’s environment, you simply cannot put all of your eggs in one basket.  To adequately protect your system, you need to present multiple hurdles for your enemies to overcome.  If they get past one, there is a good chance that the next one they encounter will defeat them.

The good news is that your IBM i comes with a lot of tools available to you so you can build these additional lockouts.  To protect yourself from the enemy within, you will need to build strong object level access controls.  You will need to rigorously enforce a policy of no user profiles with *ALLOBJ authority.  You will need to also enforce a policy of password rotation on a frequent basis with password controls that prevent the reuse of passwords and the use of passwords that are easy to guess.  Lastly, the strong lock of exit point controls will also help keep your data safe.

All of these options, and more, are open to you.  Some may cost you some money, but the alternative of seeing your organization on the front page of the paper for data theft would be much more expensive in the long run.

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

Are Your Backups Complete?

By Rich Loeber

No security plan is complete without addressing the issue of safe and complete backups.  When the AS/400 was first announced, the process was fairly simple and straight forward.  All you needed to do was save all the libraries on your system, save OS/400 in a way it could be reloaded and then make arrangements to backup your security and configuration settings.

As the AS/400 has morphed into the IBM i, things have gotten more complex.  Additional items needed to be saved and new command structures needed to be learned.  With today’s systems, it is not as simple as the original plan, but the tools are all there.  If you haven’t reviewed your backup plan recently, it would be a good idea to dust it off to make sure that everything you need is being saved on your system.

A backup plan generally has two objectives.  First, to be able to recover the entire machine in the event of a catastrophic loss of your processor.  This recovery can be either on your own machine, following repair, or at an off-site location.  The second objective is to be able to recover an individual object in the event of accidental or purposeful object loss.  Your backup plan needs to support both of these objectives.

To get a complete backup of your system today, your backup plan has to provide for the following components of your system:

1. The IBM i operating system
2. Your machine configuration
3. Your systems security settings
4. All native IBM i libraries
5. All shared folder files
6. All files in your Integrated File System (IFS)

The more recent additions to this list are these last two and this is where I want to concentrate efforts for this article.  If you’ve been around the IBM i for a while, you’re probably already quite familiar with items 1 through 4.  If not, feel free to shoot me an Email and I can help you out off-line.

It could be argued that numbers 5 and 6 on this list are both part of the IFS, but the IBM i provides some commands specifically designed for the shared folder system, so you can consider it separately if you want to.

You can save just the Shared Folder files (also known as the QDLS file system in the IFS) using the IBM i command SAVDLO.  To save all files in the Shared Folder system, you can use the following command:

SAVDLO DLO(*ALL) DEV(TAP01) OUTPUT(*PRINT) SAVACT(*YES)

Note, this command will produce an audit report of what was saved which you can print and keep with the backup or just hold in an output queue.  This report tends to be quite lengthy on most systems.  When you run this command, all document library objects on your system will be saved along with all folders and files in the entire Shared Folder system.  The SAVACT(*YES) parameter helps to make sure that the backup is complete by saving objects that may be in use.  If you run your backup in a restricted state, this parameter will not be necessary.

To save the files in your Integrated File System, you will need to use the IBM i SAV command.  This command can actually be used to save your entire system, but its use for native IBM i objects can be confusing so most shops limit its use to the IFS objects.  To save all files in your IFS, use the following command:

SAV DEV(‘/QSYS.LIB/TAP01.DEVD’)
OBJ((‘/*’) (‘/QSYS.LIB’ *OMIT) (‘/QDLS’ *OMIT))
SAVACT(*YES) OUTPUT(*PRINT)

Note that the output device naming method is quite different from standard IBM i command formats.  Also, if you are using the plan outlined above, you want to make sure that you don’t save objects again that have already been saved at points 1, 4 and 5.  The OBJ parameter controls this function.  In this SAV command, the OBJ parm contains three elements.  The first element specifies that everything is to be saved.  The next two sub parameters modify this by specifying that the QSYS file system and the QDLS file system be omitted from the backup.  By leaving these out, you will end up saving just the IFS objects you need.

If some of this appears strange to you, then it means you need to dust off your backup plan and bring it up to date.  Today would probably be a good day to do that.

If you have any questions about this topic, you can reach me at rich at kisco.com.  I’ll give it my best shot.  All email messages will be answered.