Save/Restore: PART 1

IBM i (OS/400, i5/OS)
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Q: When does the typical person think seriously about saving data?

A: Unfortunately, when a disaster happens and data is lost.

The save/restore articles I offer this month and next are meant to joggle the minds of systems administrators to explore these questions:

"Do I have a sufficient backup in the event of loss of data?"

"Can I perform my backup in a more efficient way?"

I'll explore the commands and strategies to backing up an AS/400. First, I'll examine the things that you should back up most frequently: configurations, security data, and the user data.

Configuration objects allow different ways of connecting to an AS/400. If you connect via twinax to a display station, for example, that twinax display station has a name-a device name. That device name (the system calls it a device description) contains not only the name, but the model of the device, which controller and port number it uses, a default printer, and many other things that the system requires for it to identify that display station to the AS/400. If you connect via an ASCII Work Station Controller, that device has the same information about it. No matter how you connect (SDLC, display station pass-through [DSPT], Ethernet, etc.), each device description has similar characteristics.

Examples of other configuration objects are controllers (such as twinax, ASCII, and Ethernet), line descriptions (used with modem connections), virtual devices (those devices that are created via Client Access or Pass-Through), and APPN controllers.

If your disk were to crash or your configuration data were somehow destroyed, could you rebuild from memory? Chances are that the answer to this question is "no." Other questions to think about are "How often are configuration devices changed?" and "How often should I back up these devices?" In most shops, there is no definite time that you would add or change a device. In

my opinion, the answer to the second question is, "At every opportunity."

To save these configuration objects, you would have to use the Save Configuration (SAVCFG) command. At a command line (or in a CL program), type the following:

This is assuming that TAP01 is your tape device. However, you may save it on any tape device you have.
One restriction of the SAVCFG command is that the user must have *SAVSYS authority in his user profile,
as is the case with most Save and Restore commands. (If there is any question, see your system security
officer or the person who issues new user profiles.) Another restriction that you must consider is
diskette devices cannot be used for a configuration save.

To restore configuration objects, use the Restore Configuration (RSTCFG) command:

This will restore all objects saved to the tape mounted on device TAP01. If individual objects need to
be restored, list those objects in the place of *ALL.

A secondary way to save your configuration objects is by using the Retrieve Configuration Source (RTVCFGSRC) command. This command creates a CL source member that can be compiled, and the devices are
created by running that CL program. RTVCFGSRC has four important parameters. First is the configuration
description (CFGD), which can be either a single device or *ALL devices. For save and restore
operations, *ALL is the only choice. Second is the configuration type (CFGTYPE). You can create a
source member for any of the AS/400 device types, but I suggest using a value of *ALL. Third is the
source member you want to create (SRCFILE), and fourth is the source member name (SRCMBR). You can take
the default value *CFGD, which creates a source member named CFGSRC, or you can supply a member name.
Another top priority item that you should regularly protect via magnetic media is the security data,
which consists of all authorization lists, authority holders, and user profiles. The user profiles are
objects that allow a user to sign on to the AS/400 and give the user a password, special authorities
(such as *SAVSYS), the initial program to call upon sign-on, and a default menu upon sign-on.

Again, rebuilding this information would be an unachievable task. These objects change frequently. So
the value of the object if lost is great. By using the Save Security Data (SAVSECDTA) command, you can
easily ensure that profiles and authorization lists are not lost. At a command line or in a CL program,
type in the following:

Just as in saving configuration objects, you must have *SAVSYS authority in your user profile to
perform this command.

Restoring user profiles is done through the Restore User Profile (RSTUSRPRF) command:

Again, to restore individual profiles, list them in place of *ALL.
Restoring authorization lists requires another command, Restore Authority (RSTAUT). This command has no
required parameters. However, you can restore only the authorities to individual user profiles by
specifying USRPRF() on the command. Restore user profiles and authorization lists in this order:
RSTUSRPRF first and then RSTAUT.

Virtually any AS/400 object can be saved to magnetic media by using the Save Object (SAVOBJ) command.

Suppose you need to save program MYPROGRAM in library MYLIB. You could save that object using code like

Or maybe you need to make changes to a database file and want to ensure that you have a clean copy
before you make those changes. If that file is in the same library but named MYFILE, you can save it

You can even save an individual file member. As an example, suppose that you have a CL source file
(QCLSRC) and want to save one member, MYSRC.

Theoretically, you could save all objects in a library, but that is best handled with another command,
which we will explore later in this article. To restore objects saved with the SAVOBJ command, use the
Restore Object (RSTOBJ) command.

The best use of SAVOBJ is just that, objects, not an entire library.
Several types of objects are restored empty: output queues, job queues, data queues, and message
queues. When these objects are restored, only the description is restored. The contents of these queues
are not restored.

The Save Library (SAVLIB) command is tailored for saving entire libraries, as opposed to certain
objects within that library. If you were to keep all of your data files in a library, such as MYFILES,
you could save that library, using the SAVLIB command.

Note that, in this example, all objects in that library are saved to magnetic tape. There are some
exceptions to this rule. The following system libraries cannot be saved via the SAVLIB command: QSYS,

The SAVLIB command has some unique features. It can save either all objects in a library or certain
"set" of libraries. These sets are *IBM, *ALLUSR, and *NONSYS.

o The *IBM "set" of libraries contains all IBM-created libraries with the exception of the following

There is an old saying, "All rules are made to be broken," and the SAVLIB command holds true to that
old saying. The *IBM "set" of libraries also includes the following libraries if they exist on your

o The *ALLUSR library "set" contains all user-created libraries on the system. With each library
created, there's an attribute for that library object that tells the system whether the library is
created by *IBM or a user (when displaying the object, look for the Created By User field). In
addition, libraries that begin with the letter Q, which can contain user-specific data, are saved:

Note that this list includes some libraries that were excluded from the *IBM set of libraries.
o The last unique set of IBM libraries is the *NONSYS set. This set consists of both the *IBM and the
*ALLUSR sets of libraries, but this save must be done on a dedicated system.

When deciding on your save-and-restore strategy, you need to consider a couple more items. First,
remember that when you restore, you must use the same command structure you used when you saved. If you
save libraries with a *NONSYS option, they must be restored with a *NONSYS option. Likewise with *IBM
and *ALLUSR. You cannot save with one method and restore with another. Individual libraries and objects
can be individually restored. Second, if you are running the QSNADS subsystem, you must end that
subsystem during the *ALLUSR option. If you don't, the QAO* files in the QUSRSYS library will not be

Objects saved with the Save Library (SAVLIB) command can be restored via the Restore Library (RSTLIB)
command (which restores the entire library) or the Restore Object (RSTOBJ) command (which restores
individual objects).

The Save Changed Object (SAVCHGOBJ) command is another command in the arsenal of magnetic media
options. This command is similar to SAVOBJ but with one major difference: SAVCHGOBJ saves only the
objects that have changed since the last SAVLIB command.

Each object in the library has several attributes. One of them is the date and time of the last save;
another is the date and time of last change. Many other attributes for each object exist, but, for the
purpose of save and restore, these are the most important.

Suppose you saved a library called MYLIB using SAVLIB. As time progresses, objects in that library
change. If they are files, data is added, modified, or changed. If it is a source file, the same types
of changes have been made to the members of that source file. If the library contains program objects,
those objects are new once they're recompiled. What if you could save only those things that have
changed? With SAVCHGOBJ, you can do just that. The command looks for objects that have been changed
since the last complete library save.

Saving only those objects that have changed decreases the save time but increases the restore time. The
save time is cut because only changed objects will be saved. However, in the event of data corruption
or a disk crash, two restore operations must take place to bring the library up to its current
condition. First, use RSTLIB to restore the last full library save. Then, use RSTOBJ to restore the
changed objects. The timing of the restores is crucial and must be performed in this order.

One nice feature of SAVCHGOBJ is that you can save changed objects for a single library, a series of
libraries, or all of the user libraries. To save the changed objects in all of the user set of
libraries (see the Saving Libraries section of this article for the discussion on *ALLUSR), use the
following code:

To save changed objects in an individual library, substitute that library name for *ALLUSR. And to save
the changed objects in a series of libraries, substitute those library names for *ALLUSR.

You might expect that there would be a Restore Changed Objects command, but there's not. Use RSTOBJ
when restoring changed objects.

The Integrated File System (IFS), folders, and OfficeVision require a separate save operation-the Save
Document Library Objects (SAVDLO) command. Also, Client Access users should frequently use this
command. To save all folders and all documents in those folders, use the following SAVDLO command:

This will safeguard all folders and any documents within those folders and place a copy of them on
tape. If you have particular documents or folders that need to be copied on magnetic tape, replace *ALL
and *ANY with the names of the documents and folders.

SAVDLO has some unique options. You may *SEARCH the objects for combinations of owners, change date and
time, and create date and time.

Restoring objects saved with SAVDLO requires using the Restore Document Library Object (RSTDLO)

If you are blessed with disk space but do not have the luxury of being able to take down a system to do
a backup, you can save data to a save file (this save file resides on the disk as opposed to residing
on tape). You can place the save file on magnetic tape later. Saving objects to save files saves time
(operations to disk are faster than operations to tape), but please be sure you have sufficient disk
space to do save operations to save files.

Just as you must initialize a blank tape-via the Initialize Tape (INZTAP) command-you must create a
save file before you can save data to that save file. To do that, you must use the Create Save File
(CRTSAVF) command. Save files can reside in any library, but for this example, I will use the general-
purpose library QGPL.

Once you have a save file, you can save data in it. Suppose you want to save library MYLIB in a save
file. You would use the Save File option (which resides in the same place as the Device parameter on
Save commands) instead of a tape device. We also have to specify where the save file resides.

After this operation is complete, the save file must eventually be copied to a save medium. You do this
with the Save Save File Data (SAVSAVFDTA) command.

One common mistake users make is forgetting to save the save file to tape after the save-to-save-file

operation. If a user forgets this step, the data contained in the save file is as volatile as other
data when it comes to data corruption or disk crashes. If your system crashes between the save-to-save-
file operation and the save-file-to-tape operation, you still have only the last save operation on tape
to go back to. An option that some shops use is to separate their disk into separate auxiliary storage
pools (ASPs), dedicating one or more to save file operations. This is a good strategy-if you have the
disk to spare for a separate ASP.

The save file is another object, and it will be saved with the SAVLIB command, which is not the
preferred option. A better option is to use a good CL program that can save everything except database
files (this option is used by those 24/7 IS shops that cannot afford down time for saves). Then, when
it's time to save database files, you can get the users off the system, save the database files to a
save file, resume normal operations, and then process the save file to tape.

Here's a simplified example: Assume you have only three libraries on your AS/400. They are MYSOURCE
(your programming source files), MYPGMS (program objects), and MYFILES (your database files). First,
you would save the source and program objects (which are not usually in use in a 24/7 operation) with
the SAVLIB command.

You'll need exclusive access to the data, so make sure none of your users are using the database files.
If your users are unwilling to sign off voluntarily, you may have to end their jobs and vary the
devices off. Alternatively, if they work in a separate subsystem, you can end that subsystem. Then, you
can save as follows:

At this point, you can allow your users access to the system. Finally, save the save file data to tape:

Most Save commands offer many useful options. An end-of-tape option (denoted by the ENDOPT parameter)
is often useful. With most new tape drives, all of these options work as specified. There are three
basic flavors: leave (*LEAVE), rewind (*REWIND), and force the tape to eject (*UNLOAD).

By choosing to leave the tape at the point of the last save, you can save time in multiple save
operations. Suppose that in the save library and save file example above, I entered this code:

The tape device will simply stop when the save operation is complete on the library MYSOURCE. Likewise,
on the MYPGMS library, it will start at the place where MYSOURCE left off. For library MYFILES, it will
pick up where the save of MYPGMS left off and eject the tape after the save.

The Eject option is very valuable, especially on the last Save command. One morning I found my system
off, with an SRC code on the front panel. My first thought was, "Did the save operation complete?"
Fortunately, I had used the Eject option on the last save operation, so I was assured that even in the
event of a disk crash, the data was safely on tape. I could see that my 8mm tape had ejected. Luckily,
the SRC code had nothing to do with the disk, and no restore was needed. However, if I hadn't used the
Eject option, I would not have been sure without looking at the tape if it had completed or not.

In my shop, I do periodic saves of physical file data before making wholesale changes to that physical
file. The Eject option on the last operation here is valuable also; I know that I can proceed.
Finally, the Rewind option is the default option. Make sure that if you need a different option, you
specify it. Otherwise, after each save operation, the tape will rewind to the beginning. This excessive
amount of tape positioning could add time to your save process.

When saving objects, you can put an expiration date on them. This can be especially helpful if you
rotate a series of tapes.

You can either save them with a permanent expiration date EXPDATE(*PERM) or specify the date of
expiration. By making the objects permanent, the tape will have to be reinitialized in order to reuse

By using a date, you can overwrite the objects in a cyclic fashion. Suppose you rotate one week (seven
days) worth of tapes, and today is March 1, 1998. If your save operation specifies the expiration date
as March 8, 1998, then as of March 8, 1998, you can overwrite those objects without reinitializing the

Remember, when specifying the expiration date, it must be in accordance with your system date format
system value. If you are using a date format of *MDY, you would specify EXPDATE(030898) in the above

If you need an auditing tool to ensure that a tape operation completed and to ensure what was on that
tape, you could print to either a database file or a spooled file. The OUTPUT keyword allows for three
flavors: no output (*NONE is the default), print, and place the data in an output file.

To create a spooled entry, be sure to specify OUTPUT(*PRINT) on the Save commands. If you prefer output
to a database file, choose OUTPUT(*OUTFILE) OUTFILE(QGPL/SAVEDATA) to create data in a database file.
As I stated in the SAVCHGOBJ discussion, the system keeps a date of the last save operation to that
object. Updating that date of last save is up to you.

There are only two options to the UPDHST keyword: *NO and *YES. In my opinion, you should always update
the date of last save if you intend to keep permanent tapes of that data. This could include most
SAVLIB commands.

If you choose to use SAVCHGOBJ, update the history on the complete library saves, not the history on
the changed object save. This will allow you to restore with only two operations. If the date of last
save is changed on each changed object save, all tapes between the library save and the current changed
object save will be required for a restore.

Another reason to not update the history is that you may want to make a copy on tape of database files
before major changes to the file. Most times, these are kept for a short time, and they're not kept in
a series of save and restore tapes.

One of the more recent enhancements of OS/400 (as of V2R3) is the ability to save while an object is

active. An analogy to running a yellow light is appropriate here: It is all right if you know the risks
involved, but it can be disastrous if you do not.

The default parameter for save-while-active SAVACT is *NO. This does not allow any other user access to
that object except the save operation. Ideally, if your shop can handle this scenario, I strongly
suggest you use it. With this, there can be little or no confusion about the state of the data when put
on tape. However, if this is not a possibility, then save-while-active becomes a necessity.

The SAVLIB command has three keywords that concern save-while-active: save-while-active (SAVACT), save-
while-active wait time (SAVACTWAIT), and save-while-active message queue (SAVACTMSGQ). If the save-
while-active keyword has any value other than *NO, then both of the other keywords should have values.
The save-while-active message queue simply records the checkpoints in a message queue. This queue
should be a workstation message queue as opposed to a user message queue. If your shop does an IPL
between the time your backup programs finish and time the first user comes in, an IPL will clean out
user message queues, such as QSYSOPR. Workstation message queues are not emptied until a user specifies
it. This way, all error messages will be detected, unless ignored in that workstation message queue.
The save-while-active wait time keyword has values that "depend" on situations. If there is a user
monitoring a save operation while that operation is going on, using a number of seconds (such as 120,
the default) should work just fine. If no user monitors the save operation, use *NOMAX. This value
forces the system to wait until a point is reached in which a segment of that object can be saved to

Save-while-active comes in three types. The least preferable value is *LIB. This value causes all
objects in that library to come to a point between nonsave usage and save usage, and the objects being
used in the whole library are "frozen" while the save occurs. This option is not slated to be used with
more than 1,000 objects. The problem with this is that, while the save operation is happening, the jobs
using those objects are suspended until that library is saved. If you have a job that needs one object
in a library, you could be in trouble; all objects in that library are frozen to the save operation
while the library save is running. For active jobs, this defeats the purpose of saving while the object
is active. However, for a good, clean save, it is ideal.
*LIB is at the bottom of the totem pole of save-while-active options, and *SYNCLIB is barely above
that. *SYNCLIB works similarly to *LIB, but it is able to handle larger numbers of objects in a
library. At the top of the totem pole is *SYSDFN. This allows objects in use to reach a frozen point at
differing points during the save. If for example, you were saving MYFILE in MYLIB, the object MYLIB
would be periodically frozen during the save of that object, alone. Once the save operation has
completed that item, it is freed up from the overhead of that save operation.

This article is intended for those of you who run saves frequently, such as daily or biweekly. A sound
plan is to save all IBM and user libraries on weekends and save changed objects during the week. Saving
all IBM and user libraries every night is a sounder plan, but it may not be a possibility.

At any rate, make sure the first two saves you do-even before the IBM and user libraries-are the
security data and configuration saves. In the event of a complete disk crash, they are the two most
important. Likewise, make sure the first things that are restored are the user profiles, authorization
lists, and configuration objects. The user profiles and authorities are integral when recovering from a
disk crash. As an example, if the configurations are restored before the security data, the user
profile QDFTOWN owns all the configuration objects. Without all of the profiles, the system does not
have a user to own the configuration objects.

Also, in the event of a disk crash, restore the user profiles and authorities in one pass, and restore
the configuration objects in a second pass.

In the next article, I will discuss the less-frequent saves, such as the system, licensed programs, and

Stay tuned....
Tim Johnston is the manager of information systems at Hapco, a Division of Kearney National, Inc. in
Abingdon, Virginia. Tim can be reached via the MC Discussion forums on the MC Web site or by email at
This email address is being protected from spambots. You need JavaScript enabled to view it..

CL Reference, V3R1 (SC41-3722-00, CD-ROM QBKAUP00)



Support MC Press Online





  • White Paper: Node.js for Enterprise IBM i Modernization

    SB Profound WP 5539

    If your business is thinking about modernizing your legacy IBM i (also known as AS/400 or iSeries) applications, you will want to read this white paper first!

    Download this paper and learn how Node.js can ensure that you:
    - Modernize on-time and budget - no more lengthy, costly, disruptive app rewrites!
    - Retain your IBM i systems of record
    - Find and hire new development talent
    - Integrate new Node.js applications with your existing RPG, Java, .Net, and PHP apps
    - Extend your IBM i capabilties to include Watson API, Cloud, and Internet of Things

    Read Node.js for Enterprise IBM i Modernization Now!


  • Profound Logic Solution Guide

    SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation.
    Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects.
    The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the companyare not aligned with the current IT environment.

    Get your copy of this important guide today!


  • 2022 IBM i Marketplace Survey Results

    Fortra2022 marks the eighth edition of the IBM i Marketplace Survey Results. Each year, Fortra captures data on how businesses use the IBM i platform and the IT and cybersecurity initiatives it supports.

    Over the years, this survey has become a true industry benchmark, revealing to readers the trends that are shaping and driving the market and providing insight into what the future may bring for this technology.

  • Brunswick bowls a perfect 300 with LANSA!

    FortraBrunswick is the leader in bowling products, services, and industry expertise for the development and renovation of new and existing bowling centers and mixed-use recreation facilities across the entertainment industry. However, the lifeblood of Brunswick’s capital equipment business was running on a 15-year-old software application written in Visual Basic 6 (VB6) with a SQL Server back-end. The application was at the end of its life and needed to be replaced.
    With the help of Visual LANSA, they found an easy-to-use, long-term platform that enabled their team to collaborate, innovate, and integrate with existing systems and databases within a single platform.
    Read the case study to learn how they achieved success and increased the speed of development by 30% with Visual LANSA.


  • The Power of Coding in a Low-Code Solution

    LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks



  • Why Migrate When You Can Modernize?

    LANSABusiness users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
    In this white paper, you’ll learn how to think of these issues as opportunities rather than problems. We’ll explore motivations to migrate or modernize, their risks and considerations you should be aware of before embarking on a (migration or modernization) project.
    Lastly, we’ll discuss how modernizing IBM i applications with optimized business workflows, integration with other technologies and new mobile and web user interfaces will enable IT – and the business – to experience time-added value and much more.


  • UPDATED: Developer Kit: Making a Business Case for Modernization and Beyond

    Profound Logic Software, Inc.Having trouble getting management approval for modernization projects? The problem may be you're not speaking enough "business" to them.

    This Developer Kit provides you study-backed data and a ready-to-use business case template to help get your very next development project approved!

  • What to Do When Your AS/400 Talent Retires

    FortraIT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators is small.

    This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:

    • Why IBM i skills depletion is a top concern
    • How leading organizations are coping
    • Where automation will make the biggest impact


  • Node.js on IBM i Webinar Series Pt. 2: Setting Up Your Development Tools

    Profound Logic Software, Inc.Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. In Part 2, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Attend this webinar to learn:

    • Different tools to develop Node.js applications on IBM i
    • Debugging Node.js
    • The basics of Git and tools to help those new to it
    • Using as a pre-built development environment



  • Expert Tips for IBM i Security: Beyond the Basics

    SB PowerTech WC GenericIn this session, IBM i security expert Robin Tatam provides a quick recap of IBM i security basics and guides you through some advanced cybersecurity techniques that can help you take data protection to the next level. Robin will cover:

    • Reducing the risk posed by special authorities
    • Establishing object-level security
    • Overseeing user actions and data access

    Don't miss this chance to take your knowledge of IBM i security beyond the basics.



  • 5 IBM i Security Quick Wins

    SB PowerTech WC GenericIn today’s threat landscape, upper management is laser-focused on cybersecurity. You need to make progress in securing your systems—and make it fast.
    There’s no shortage of actions you could take, but what tactics will actually deliver the results you need? And how can you find a security strategy that fits your budget and time constraints?
    Join top IBM i security expert Robin Tatam as he outlines the five fastest and most impactful changes you can make to strengthen IBM i security this year.
    Your system didn’t become unsecure overnight and you won’t be able to turn it around overnight either. But quick wins are possible with IBM i security, and Robin Tatam will show you how to achieve them.

  • Security Bulletin: Malware Infection Discovered on IBM i Server!

    SB PowerTech WC GenericMalicious programs can bring entire businesses to their knees—and IBM i shops are not immune. It’s critical to grasp the true impact malware can have on IBM i and the network that connects to it. Attend this webinar to gain a thorough understanding of the relationships between:

    • Viruses, native objects, and the integrated file system (IFS)
    • Power Systems and Windows-based viruses and malware
    • PC-based anti-virus scanning versus native IBM i scanning

    There are a number of ways you can minimize your exposure to viruses. IBM i security expert Sandi Moore explains the facts, including how to ensure you're fully protected and compliant with regulations such as PCI.



  • Encryption on IBM i Simplified

    SB PowerTech WC GenericDB2 Field Procedures (FieldProcs) were introduced in IBM i 7.1 and have greatly simplified encryption, often without requiring any application changes. Now you can quickly encrypt sensitive data on the IBM i including PII, PCI, PHI data in your physical files and tables.
    Watch this webinar to learn how you can quickly implement encryption on the IBM i. During the webinar, security expert Robin Tatam will show you how to:

    • Use Field Procedures to automate encryption and decryption
    • Restrict and mask field level access by user or group
    • Meet compliance requirements with effective key management and audit trails


  • Lessons Learned from IBM i Cyber Attacks

    SB PowerTech WC GenericDespite the many options IBM has provided to protect your systems and data, many organizations still struggle to apply appropriate security controls.
    In this webinar, you'll get insight into how the criminals accessed these systems, the fallout from these attacks, and how the incidents could have been avoided by following security best practices.

    • Learn which security gaps cyber criminals love most
    • Find out how other IBM i organizations have fallen victim
    • Get the details on policies and processes you can implement to protect your organization, even when staff works from home

    You will learn the steps you can take to avoid the mistakes made in these examples, as well as other inadequate and misconfigured settings that put businesses at risk.



  • The Power of Coding in a Low-Code Solution

    SB PowerTech WC GenericWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks



  • The Biggest Mistakes in IBM i Security

    SB Profound WC Generic The Biggest Mistakes in IBM i Security
    Here’s the harsh reality: cybersecurity pros have to get their jobs right every single day, while an attacker only has to succeed once to do incredible damage.
    Whether that’s thousands of exposed records, millions of dollars in fines and legal fees, or diminished share value, it’s easy to judge organizations that fall victim. IBM i enjoys an enviable reputation for security, but no system is impervious to mistakes.
    Join this webinar to learn about the biggest errors made when securing a Power Systems server.
    This knowledge is critical for ensuring integrity of your application data and preventing you from becoming the next Equifax. It’s also essential for complying with all formal regulations, including SOX, PCI, GDPR, and HIPAA
    Watch Now.

  • Comply in 5! Well, actually UNDER 5 minutes!!

    SB CYBRA PPL 5382

    TRY the one package that solves all your document design and printing challenges on all your platforms.

    Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product.

    Request your trial now!

  • Backup and Recovery on IBM i: Your Strategy for the Unexpected

    FortraRobot automates the routine tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
    - Simplified backup procedures
    - Easy data encryption
    - Save media management
    - Guided restoration
    - Seamless product integration
    Make sure your data survives when catastrophe hits. Try the Robot Backup and Recovery Solution FREE for 30 days.

  • Manage IBM i Messages by Exception with Robot

    SB HelpSystems SC 5413Managing messages on your IBM i can be more than a full-time job if you have to do it manually. How can you be sure you won’t miss important system events?
    Automate your message center with the Robot Message Management Solution. Key features include:
    - Automated message management
    - Tailored notifications and automatic escalation
    - System-wide control of your IBM i partitions
    - Two-way system notifications from your mobile device
    - Seamless product integration
    Try the Robot Message Management Solution FREE for 30 days.

  • Easiest Way to Save Money? Stop Printing IBM i Reports

    FortraRobot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing.
    Manage your reports with the Robot Report Management Solution. Key features include:

    - Automated report distribution
    - View online without delay
    - Browser interface to make notes
    - Custom retention capabilities
    - Seamless product integration
    Rerun another report? Never again. Try the Robot Report Management Solution FREE for 30 days.

  • Hassle-Free IBM i Operations around the Clock

    SB HelpSystems SC 5413For over 30 years, Robot has been a leader in systems management for IBM i.
    Manage your job schedule with the Robot Job Scheduling Solution. Key features include:
    - Automated batch, interactive, and cross-platform scheduling
    - Event-driven dependency processing
    - Centralized monitoring and reporting
    - Audit log and ready-to-use reports
    - Seamless product integration
    Scale your software, not your staff. Try the Robot Job Scheduling Solution FREE for 30 days.