Deck: Journaling makes data recovery easier
Have you ever designed a file, and included fields in it such as the user ID of the last user to update the record, the workstation ID and date and time of the last update? And have you ever actually been able to make any use of that information? Probably not. That type of information is usually included because you have the vague idea that it will someday, somehow, be useful. Hardly ever addressed is the issue of how to accurately keep those fields up to date. Every program that touches those records, including DFU and other quick-fix utilities, has to maintain those fields. Also, any changes done through logical files have to be considered. Because of these problems, and because I can honestly say that I've never had any case in which that information helped, I long ago gave up keeping such fields in my records.
And yet, I've had a nagging anxiety that I should be keeping "history." The problems associated with programming a system to provide historical accuracy are so daunting that I also gave up on that. What to do?
It turns out that OS/400 provides a history-keeping mechanism which is so easy to use that many people doubt its efficacy. This mechanism is called journaling. One truly remarkable aspect of journaling is that you don't have to change any of your programming; you merely indicate to the system that you would like the system to start maintaining a history of all changes to one or more of your database files. Take note of the words "all changes" in the last sentence. Everything that happens to your file is noted, summarized and stored for safe keeping.
In addition to keeping history for your data, journaling can be used for several other important functions. These include security auditing, system history, program testing and debugging and commitment control, among others.
Why Didn't I Know About This?
If you haven't used journaling, you may have haphazardly stumbled upon the system journals. Your system, as shipped, includes four journals that silently record events of certain system activities. You may have learned about those journals when you were browsing around your system, looking for ways to save some disk space. This is because the events that these journals are noting are placed into objects called journal receivers, which can only grow in size until they are replaced.
The journals that are supplied, gratis, are QAOSDIAJRN, QDSNX (or QDSNXJRN), QSNADS and QSXJRN. You can see those journals on your system by executing the Work with Journals (WRKJRN) command. The text description gives you some idea of what they're used for. It looks like the supplied journals are not very interesting if you have a stand alone system and are not using the OfficeVision product. QAOSDIAJRN is the journal for Document Interchange Architecture (DIA) files, which includes documents, mail and things like that. The QDSNX journal is used by the Distributed Systems Network Executive product. The QSNADS journal is used for SNA Distribution Services, which includes such activities as sending files and objects to other systems. The one journal on your system that is likely to contain quite a number of entries is QSXJRN--the problem database journal (where the SX comes from, I don't know).
If you're still on the Work with Journals display, you can type an Option 5 next to any of those journals to display the journal status. Enter a five next to the QSXJRN entry and press ENTER. The next display, "Display Journal Status," has a few lines of heading, then something called the attached receiver. On my system, the receiver is QSXJRN0008; yours will probably be similar, except for the last four digits. What do we have here?
The Worker and the Work
Journaling, either system-supplied or defined by you, involves the use of at least two objects. The first object is called a journal. You can specify journal objects on commands like WRKOBJ with the abbreviation *JRN. The second object is called a journal receiver, and its abbreviation is *JRNRCV. These two objects work together to gather information about your system; the information gathered is called a journal entry and these entries are kept in the journal receiver.
Think of a journal as a receptionist in a small office who does nothing but answer the telephone all day. The journal receiver is the telephone log book in which each call is recorded. Each call is logged in the order it is received, and the entry includes the name and number of the caller, and any information provided by the caller. Unlike today's modern offices, though, the receptionist only answers one call at a time; there's none of this putting-on- hold-and-listening-to-music business. However, the receptionist is very quick at answering and recording each call.
The one receptionist model can be used until things start to get too busy, or it becomes desirable to split the workload. For example, as the company grows, it may add another person who does nothing but answer calls for sales, and eventually one for product support, and so on. The important concept with each of these workers is that their responsibilities are very sharply defined; the receptionist will never answer a sales call. Another important idea with the growing model is that each worker (journal) has a unique telephone log (journal receiver).
As in real life, the telephone logs will eventually become full. When the last entry is made in the log, the receptionist may make a note identifying the next telephone log. The log that was just completed can then be filed, analyzed or destroyed. As other workers fill their logs, they go through a similar change of logs.
On the other hand, the logs don't necessarily have to be full before they are changed. For example, the daily log might be filed away every night for safe keeping, with a new log started each morning. This procedure might be used for all of the log keepers or just some of them.
An interesting sidenote to all this record keeping is that the boss might occasionally call any of the workers and dictate a short message. The message doesn't give instructions to anybody or any other process, but is rather just a status report. For example, the boss might call in every time a decision is made or something is noticed, just to have the receptionist record the date and time of the inspiration.
The point of all of this record keeping is that it can be used to reconstruct business activities when disaster strikes. For example, in the middle of a business day the office above our busy office catches fire, and smoke billows through the building. Our dutiful workers evacuate, taking their logs with them. The next day, the boss and the salesmen, who hadn't been keeping up-to- the-minute notes, can get back up to date by examining the logs and then restarting the business from that point.
Application
If you have followed the example to this point, you can now begin to follow the application of journaling on the AS/400. Conceptually, journaling is quite simple. Although the practice is not necessarily difficult, it can be quite involved. There are any number of commands, concepts and choices that you have to make to create a useful journaling environment.
The first issue you have to address is, what am I going to journal? The simple answer, "everything," might not be at all practical.
You have to understand that there are only two things that you can journal: physical files and access paths. You can also cause journal entries to be written to a journal receiver. If you are journaling a physical file, every activity that changes records in the file is recorded in the journal receiver. This includes adds, updates and deletes, but doesn't include reading the file. Also recorded in the journal are such activities as saving the file, moving it or renaming it, and other actions that apply to the file but not to particular records. Journaling applies across all members in the file.
Access path journaling is used to record changes to any access paths described for the physical file. This includes the key for the physical file itself, if any, and all logical files that are built over the physical file. Access path journaling is used for recovery purposes in the event that a file was not closed properly. For example, if your large physical file with many access paths is open for update when the power fails, your next IPL will be quite lengthy if the access paths have to be rebuilt. If the access paths are journaled, the system can recover--rather than rebuild--the access paths.
So what do we journal?
What You're Getting
Before you decide to start journaling, you need a clear idea about what the journal receiver will contain, and what you might be able to do with it.
First, you should realize that a journal receiver is similar to an optical write once, read many (WORM) device. No one or nothing provided with the system--not even the security officer--can alter a journal entry once it is written. This simple fact explains a great deal of the extraordinary usefulness of journaling; you can create an indelible history for your database.
The cost of this power is measured in two distinct units of measure: disk space and system management activities. The disk space cost is the easier to understand, even though it is probably impossible to arrive at an informed guess until you've run journaling for some time.
At the lowest level, you have a journal entry in a journal receiver for each change transaction against a database file. Every journal entry contains two sections: a 125-byte header, followed by the user portion. Now swallow hard and take a look at 1. You'll see that a great deal of those first 125 bytes is composed of exactly the kind of information that you may have laboriously been trying to program into your files--such things as the date and time stamp, the user and program making the change, and so on. The primary advantages of the journal entry header are that the information is correct and that it is consistent. Later on, you'll see how you can dump journal entries from a journal receiver and, using the header fields, select and sort so that you can really trace activities against your database.
At the lowest level, you have a journal entry in a journal receiver for each change transaction against a database file. Every journal entry contains two sections: a 125-byte header, followed by the user portion. Now swallow hard and take a look at Figure 1. You'll see that a great deal of those first 125 bytes is composed of exactly the kind of information that you may have laboriously been trying to program into your files--such things as the date and time stamp, the user and program making the change, and so on. The primary advantages of the journal entry header are that the information is correct and that it is consistent. Later on, you'll see how you can dump journal entries from a journal receiver and, using the header fields, select and sort so that you can really trace activities against your database.
The second portion of the journal entry, the user portion, is an image of the record. By default, the image is a recording of the record as it was after the activity. You can elect to have before images also, and in fact you must specify before images in addition to the after image when you use commitment control, which we will discuss in the near future. The image that is recorded is the entire record, whether it is one byte or the AS/400 maximum record length. So if one of your journaled physical files contains records that are 128 bytes long, the journal entry for that file could potentially be 253 bytes. I say potentially because journal entries are stored in a compressed format in the journal receiver. When you retrieve journal entries from a receiver for use in your programs, the entire journal entry length is seen in your program.
That is why it is difficult to predict what the disk space cost will be. You would have to calculate the journal entry length for each of the physical files that you are journaling, then compute the stored length after compression (I don't know--and haven't seen--what the compression factor is.) You would then have to predict the number of journal entries that will be generated within any given time period. This number can only be an average; for example, you might find that your customer master file has an average of 1,000 change operations per day. This is still not the entire equation; you have to allow for some journal entries to record activities at the file level- -such as opens, closes, invalid access attempts and so on. So it is probably useless to try and predict how much disk space a journal receiver will require. The only practical method of dealing with this introduces the second cost consideration: management.
What Will You Do?
Actually, the issue of disk space usage is not the primary determinant of how you manage journaling. The main issue is: why are you journaling?
In addition to the obvious reasons to journal--such as database recovery and auditing--there are the other uses, such as program testing, online access to history, commitment control, etc. The reason why you need to know "why am I journaling" is so that you can answer these questions: when can I save the current journal receiver? When can I delete a journal receiver? For what reasons would I need to keep a journal receiver on the system?
In many ways, if your primary motivation for journaling is to simplify database recovery, your management issue is simple: save the journal receivers on a regular basis. For example, you may be able to perform an actual physical file save once a week. If the file is journaled, you can simply save the journal receiver associated with the file every day. If you need to recover the file, you restore the last full save, then apply the journal receivers that were saved after the full save. With this approach, you never need to keep a journal receiver on your system for more than a day, which probably means that the journal receiver will not grow to an unwieldy size. If you are really tight on disk space, but still want to journal, you might have to utilize this method.
On the other hand, if you are not especially concerned with using journaling for recovery purposes and you have a surfeit of disk space, you can consider keeping journal receivers on the system for a longer period. You can monitor a journal receiver with the Work with Journal Attributes (WRKJRNA) command. If you can try that now, execute that command for the QSXJRN journal.
At the display, the system shows you the attached receiver for the QSXJRN journal. You can display the attributes for the receiver; do that. The Journal Receiver Attributes display shows you quite a lot of interesting and useful information about the journal receiver. You can see the size of the receiver, the number of journal entries and the length of the longest entry. You can also see the date and time that this journal receiver was attached to the QSXJRN journal. If you plan to keep journal receivers on your system, you can periodically monitor these numbers and then decide when to start a new journal receiver.
For example, you might create programs that are able to show history. Suppose you want to be able to review a customer master record, and roll backward through time, reviewing changes made to the record. If you have been journaling the file or files that contain your customer master data, you can retrieve the changes from your journal receivers. You would start with the current journal receiver, and work your way back through it. When you come to the oldest entry in that receiver, there is an entry that points to the previous journal receiver. If that receiver is still on the system, you can continue with that. So in this scenario, the issue might be, how many journal entries in a receiver are optimal for the application? Keeping in mind that journal entries have to be brought up from the receiver in order to be used by your programs, you need to determine what is a good number of entries for your response-time requirement. The answer to that question can only be determined from experience.
How Things Happen
In the preceding section, I covertly mentioned the attach date of the journal receiver to the journal. I have also been implying that you can have many journal receivers, either on or off the system. Just how do these things happen?
You can set up journaling very easily, just to try the commands. The first thing you do is create a journal receiver. The command for this is Create Journal Receiver (CRTJRNRCV). Specify the name of the journal receiver and the library where it is located. The library cannot be QTEMP. There is an advantage in creating a journal receiver name that is six characters long or less: when you need to switch from this journal receiver to the next one, the system will generate a sequentially numbered journal receiver name. For example, if you start out with journal receiver MYJRN, when you tell the system to generate the next journal receiver, it will assign the name MYJRN0001. Each generation increments the sequence number.
A useful parameter of the CRTJRNRCV command is THRESHOLD. This indicates the number of kilobytes that you will let the journal receiver use. When it has used that much space, a message is sent to the message queue of the associated journal, indicating that the threshold has been reached. Journal entries are still added to the journal receiver; the message is just sent to let you know that the receiver has reached that point.
If your primary motivation for journaling is recovery, and you have the requisite amount of DASD, you should seriously consider the Auxiliary Storage Pool ID (ASP) parameter. You may decide that the journal receiver, which will contain journal entries for one or more of your physical files, should be in a different ASP than the files themselves. You might be able to specify the UNIT (Preferred storage unit) parameter to accomplish the same thing, but this technique has probably fallen by the wayside in favor of the ASP specification.
If you need journaling for audit purposes, you can specify the Authority (AUT) parameter for the journal receiver. Bearing in mind that journal entries are write only (no changes or deletions allowed by anybody), you can and should also secure the journal receiver (and the journal) so that only an authorized user can manipulate the journal receiver object. After all, if you're going to carve in stone, you don't want the stone to disappear.
You can create as many journal receivers as you want. Simply creating them does not yet result in any action. For that, you still need to create the journal itself. To create a journal, you use the Create Journal (CRTJRN) command. This command requires that you specify the name of the journal and the library where it will be located. You can also specify one or two journal receivers that are to be attached to the journal.
Now why would you attach two journal receivers to a journal? This is kind of like wearing a belt and suspenders. If your machine has lots of disk, you can create two journal receivers, possibly in separate ASPs, then have the journal write journal entries to the two receivers for every transaction that comes through the journal. This is great if you really need a high assurance of recovery, but don't have quite enough disk to mirror. The idea is that if one of the journal receivers becomes damaged, the other will continue to be available, either to receive entries or to be used for recovery.
The CRTJRN command also lets you specify the ASP parameter, with the proviso that the library of the files being journaled and the library containing the journal must be in the same ASP. This is probably not a big problem, in terms of recovery, since the journal receivers can be in other ASPs. The journal itself can simply be recreated if it is destroyed, and reattached to the same or new journal receivers.
As on the CRTJRNRCV command, you can also specify the AUT parameter on the CRTJRN command. If auditing is the requirement, specify accordingly.
And Now the Files
Once you have the journal receivers and the journal created, you can pick one or more physical files that are to be journaled. Indicate that you want files to be journaled with the Start Journal Physical File (STRJRNPF) command. This command is pretty simple: specify the files that are to be journaled, the journal that they are journaled through (notice that you do not specify the journal receivers; the journal receivers are specified through the journal), the type of images that you want journaled and whether or not you want to omit the OPEN and CLOSE journal entries from the journal receivers.
The images are the record images that make up the second part of each journal entry (the first part is the 125-byte header). You can specify that you want AFTER images or BOTH (BEFORE and AFTER) images written to the journal receiver. The images are written to the receiver prior to the equivalent activity happening to the affected record. An important point also is that the journal entry is written to disk as it happens, whereas the activity against a database record might not be written to disk until the file is closed. This is one of the techniques used to enable the database to be recovered with journaling; to affect a similar recovery with programs that you write, you would have to specify FRCRATIO(1) for all of the files so that any changes would be written to disk as they happen.
Note: The STRJRNPF command requires an exclusion lock on the physical file. When STRJRNPF completes, the lock is released.
As soon as you start journaling for a file, you can use the Display Journal (DSPJRN) command to look at the journal entries. To use this command, specify the journal name that you used on the STRJRNPF command. The Display Journal Entries display is shown next. If you have just started journaling (the journal and journal receiver are new), you will see at least two entries. The first entry will probably be a code "J" entry, type "PR." You can use Option 5 to display more information about that entry. The additional information display tells you that code "J" is a "journal or journal receiver operation," and type "PR" indicates "previous journal receivers." If this is your first journal receiver for this journal, the entry-specific data is blank. If this receiver is a new journal receiver for this journal, the entry-specific data will contain the name of the previous journal receiver. This chain of receivers can be used to trace backward and forward through your journal receivers.
The second journal entry is code "F", type "JM." Use Option 5 again to display the details of that entry. The code "F" entry is used to indicate a "database file operation." The type "JM" is used to indicate "start journaling for member." In this case, the entry specific data is set to "0," which for this type of journal entry is used to indicate that the "file was synchronized with (the) journal." If you started journaling a file that is actively used, you might also see additional entries that are specific to records in the file. You can examine those entries, and see that the entry specific data shows images of your data.
The Backup and Recovery Guide (SC41-8079) contains charts of all of the possible journal codes and entry types that can be associated with each code. If you review those charts, you can begin to get an idea of the possibilities of using journal entries. You can use journal entries in your programs with the DSPJRN, Receive Journal Entry (RCVJRNE) and Retrieve Journal Entry (RTVJRNE) commands. These commands let you select the journal entries that you want, based on date, time, job, program, sequence number within the journal receiver and other parameters. Each of the commands brings up the journal entry from the internal journal receiver format to a format that can be used by your programs.
With each of these commands, you can specify the type of header information that is to be retrieved. Header information *TYPE1 includes all of the information shown in 1 (page 84). Header *TYPE2 also includes the user profile and the system name. (As of V2R1.1, there will be a *TYPE3 header.) You can use the DSPFFD command for files QADSPJRN and QADSPJR2 to review the fields included in the header.
With each of these commands, you can specify the type of header information that is to be retrieved. Header information *TYPE1 includes all of the information shown in Figure 1 (page 84). Header *TYPE2 also includes the user profile and the system name. (As of V2R1.1, there will be a *TYPE3 header.) You can use the DSPFFD command for files QADSPJRN and QADSPJR2 to review the fields included in the header.
When you use these commands, there is one peculiar condition for which you must account. That condition is the length of the journal entry. In addition to the header information, the entry-specific data that you saw with the DSPJRN display is included with each journal entry returned to your program. If you are retrieving entries for more than one physical file, chances are that you will be working with what are essentially variable length records. You must allow for the longest record length of interest to you. If you don't allow enough space to hold the entire retrieved journal entry, the entry- specific data is simply truncated. (Note, though, that the entry-specific data is not lost; it is still in the journal receiver. The data is simply unavailable to your program until you allow for a longer record length.)
Retrieval Commands
Although the three retrieval commands perform the same function--to get and format a journal entry from a journal receiver--they each are used differently. The retrieval command to use depends upon your requirements.
The simplest retrieval command is the one you have already used, DSPJRN. If you prompt for this command again, one of the last parameters is OUTPUT. You can specify display, print or output file output. If you select output to an output file, you can choose the type of header information (*TYPE1 or *TYPE2) and specify the output file and member to contain the journal entries. You will have to go back a few parameters, though, to find the other important parameter, Entry Data Length (ENTDTALEN). This is set to a default of 100, meaning that up to 100 bytes of entry-specific data will be retrieved. You can specify a value from 0 to 32640 for this parameter, and this is where you want to specify a length that will accommodate the longest entry that was journaled.
For example, if you are journaling three files, with record lengths 55, 78 and 155, and you are displaying journal entries for all three files, you would specify 155 as the entry data length, so that you can retrieve the entire journaled record. The record in the output file will contain the header information (at least 125 bytes) followed by the 155 bytes of entry data. When entries for the shorter files are retrieved, they are placed into the 155-byte entry data area, and filled with blanks after the end of their data.
The RTVJRNE command can be used in a CL program or a REXX program to retrieve a single journal entry. You can specify the same type of selection parameters as on the DSPJRN command, so that you can get quite specific about which journal entry is retrieved. With this command, the retrieved entry and associated information are placed into CL program variables. You can retrieve the journal entry sequence number, journal code, entry type, journal receiver name and library and the journal entry data. The journal entry data is retrieved into the CL program variable specified in the RTNJRNE parameter, and you have to specify an adequate field length for that field to contain the entire retrieved entry. This is just like specifying the ENTDTALEN parameter on the DSPJRN command, the difference being that you also have to add in the amount of space for the header information.
For example, to use the RTVJRNE command to retrieve journal entries for the three files mentioned above, you would declare a CL program variable 280 bytes long. This would accommodate 125 bytes of *TYPE1 header data and 155 bytes for the maximum record length. You can use the CL or REXX substring functions to pick out parts of this variable.
The RCVJRNE command is probably the most complex command to use to get journal entries, but it may be just what you need in certain applications. This command lets you specify the same type of selection criteria as the other two commands. The big difference is what happens with the journal entry: it is passed to an exit program that you specify when you execute this command. This command is a never ending command, which means that you have to take action to end it. When you execute the command, the journal receiver is examined to see if there are any journal entries that meet the selection criteria. If there are any, the exit program is called for each of the qualifying journal entries in succession. When all of the qualifying entries have been passed to the exit program, the command does not end, but waits for a specified time period. When the time period is up, the journal receiver is examined again. If any new qualifying entries have been added to the journal receiver, they are passed to the exit program. The default delay time is 30 seconds; you can specify a delay value of 1 to 99,999 seconds.
The RCVJRNE command is ideal for situations where you want to have immediate access to journal entries on a continuous basis. For example, if you are running dual systems to back each other up, you can receive journal entries and use the exit program to send the journal entries to the other system. Because the receive is an ongoing process, you don't have to take a copy of the entire receiver at one time; the second system will be current with the primary system within the delay time specified in this command plus the processing time for the exit program.
The exit program can be written in any HLL. Two parameters are passed to the program. The first parameter is the journal entry, including the header information. This parameter is defined as a *CHAR variable, and has to be long enough to accommodate the longest journal entry plus the header. No error is signaled if a longer journal entry is received; it is merely truncated.
The second parameter is a *CHAR field, length 1. When the RCVJRNE command calls the exit program with a journal entry, this field is set to "1." Your program can test that value and process accordingly. When there are no more journal entries available, the RCVJRNE command calls the exit program with this field set to "0." The RCVJRNE command goes into the delay mode upon return from the exit program. Finally, the exit program can set this field to "9" to indicate that the RCVJRNE command should end. The exit program can use any number of factors to determine when the command should end; for example, a file might be full or communication with the second system has been lost.
The RCVJRNE command can also be ended with the ENDJOB command. If you design a journal processor that uses this command, the program will probably be run as a batch job, so you can change or end it just like any other batch job.
Your Own Entries
You can also send your own entries to any journal on your system. The command used for this is Send Journal Entry (SNDJRNE). When you use this command, you specify the journal you are sending to, the journal entry type, the entry- specific data, and the name of a physical file and member if you want the entry associated with a file.
The journal type can be any two characters that you want. They can even be the same as system-defined journal types, because the journal code associated with entries created by the SNDJRNE command is "U" (for user-created entry).
The entry-specific data can be literally anything, up to 9999 bytes. For example, if you are placing a new program into production that uses some of your journaled files, you can use SNDJRNE to create a journal entry in which you indicate the date and time that the program was first used. You can use the same technique to create an entry after a program has been modified. This would let you bracket the effects of the program. You can examine the effect on your files between modifications, and possibly determine if the changed program is malfunctioning.
There's More
You are probably starting to realize that there is quite a bit to know about journaling. Journaling is actually a fascinating subject, since it cuts across so many aspects of the AS/400: security, auditing, backup, recovery and programming to name a few. Journaling is not just a programming issue, nor just a management or operational concern, but rather a combination. If you aren't journaling but think you should be, you will probably have to do quite a bit of planning and discussing with the rest of your staff before starting. There is no real penalty for starting to journal and then stopping or changing, but you should have a pretty good idea of why you are journaling and how to use the functions.
In next month's article, I will show you some of the commands that are available to use in recovery situations. I will also review some of the factors involved in using journals for recovery. Also, there are many tools in the QUSRTOOL library that I will discuss, as they make journal management a good deal easier than the standard system commands.
Introduction to Journaling, Part 1
Figure 1 Journal entry header information (*TYPE1)
Figure 1: Journal Entry header information (*TYPE1) JOENTL 5.0 Length of entry JOSEQN 10.0 Sequence number JOCODE 1 Code JOENTT 2 Type JODATE 6 Entry date JOTIME 6.0 Entry time JOJOB 10 Job name JOUSER 10 User name JONBR 6.0 Job number JOPGM 10 Program name JOOBJ 10 Object name JOLIB 10 Object library JOMBR 10 Member name JOCTRR 10.0 Relative Record Number JOFLAG 1 Flag JOCCID 10.0 Commit Cycle ID JORES 8 Reserved JOESD *** Entry Specific Data Note: Numeric fields are zoned, not packed
Introduction to Journaling, Part 1
Figure 2 A view of journaling (unable to display)
More 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 company are not aligned with the current IT environment.
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. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) 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:
Business 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.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? 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:
LATEST COMMENTS
MC Press Online