Sidebar

Multi-format and Join Logicals

General
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

How and when to use them.

Brief: Logical files can include data from more than one underlying physical file format. Those logical files are defined as multiple-format logicals or join logicals. Although it is not particularly difficult to define either type, it is sometimes not easy deciding which type to use. This article looks at the definition and use of these two types of logical files.

It is important to be aware of the alternatives to single-format logical files. I know that in my experience, I have often written and tested a program using single-format logical files, only to realize a day or two later that a multiple-format logical file or a join logical file could have been used and would have made the program much simpler.

The alternative that seems all too obvious after the fact might not be so evident in the heat of the moment, merely because most logical files are created in response to an immediate programming need. For instance, if I need a customer search program, I start by creating a logical file ordered by the customer name. I would create that as a logical file, rather than use the Open Query File (OPNQRYF) approach, since the file will be used repeatedly and should be available as needed. This logical file is created specifically for the customer search and exists in addition to the physical or logical file that is ordered by the customer number.

The customer record probably contains fields that reference data in other files. For example, a salesman identifier may be in the record, along with a customer type code. There are also other records associated with a customer. These other records can be such things as ship-to addresses, orders and accounts receivable information. An example of the customer record appears in 1 and the related database is shown in 2.

The customer record probably contains fields that reference data in other files. For example, a salesman identifier may be in the record, along with a customer type code. There are also other records associated with a customer. These other records can be such things as ship-to addresses, orders and accounts receivable information. An example of the customer record appears in Figure 1 and the related database is shown in Figure 2.

When you write programs to work with this database, you may start out with a program similar to that shown in 3. In that program, you name all of the files that you need in the F-specs, and then in the C-specs include the code needed to access the files. This is a typical usage of the database. For each customer master record that is processed, records from the other files are retrieved, based upon the values in the customer master. Note that a great deal of code is needed just to set up the "read loop" that gets all of the associated records. As more files are added, the amount of "read code" also increases.

When you write programs to work with this database, you may start out with a program similar to that shown in Figure 3. In that program, you name all of the files that you need in the F-specs, and then in the C-specs include the code needed to access the files. This is a typical usage of the database. For each customer master record that is processed, records from the other files are retrieved, based upon the values in the customer master. Note that a great deal of code is needed just to set up the "read loop" that gets all of the associated records. As more files are added, the amount of "read code" also increases.

There is nothing wrong with this approach, but you should consider that you can get the system to do the "read loop" processing for you, simply by defining a logical file that refers to all the associated records. The example illustrates, case in point, that recognizing the alternatives to single-format logical files can save you time and effort.

Two Different Needs

If you look at the customer record format, the database files and the code sample, you will see that there are two different requirements for accessing records associated with a customer. One requirement is to access a single other record, such as the salesperson for the customer or the customer type description. The access in the RPG code is by means of the CHAIN operation. In this case, there is a "one-to-one" correspondence be-tween the customer record and the salesperson and customer type files. The other requirement is to read one-to-many associated records. For example, many address records or orders may be associated with each customer. The RPG code for this type of access is SETLL and a READE loop.

You can simplify the program code by defining either a multiple-format logical file or a join logical file. Either of those types of logical files allows you to work with data from more than one physical file. OS/400 is in charge of returning the records to your program in the correct sequence, relieving you of the coding chore. The question is, which type of logical file should you use in this situation? What pattern is there to help you decide which type to use in another case?

Multiple-format Logical Files

A multiple-format logical file is defined over two or more physical files and, as its name implies, includes more than one record format within the logical file. Each record format is usually associated with a different physical file; the record formats define the data that is included from the physical files. The record formats, then, represent records that are available to your program. When your program reads from the multiple-format logical file, the records are sequenced according to key specifications that are defined for each of the record formats.

If you have worked with a S/36 or earlier machine and have converted your files to AS/400 database files, you may have encountered multiple-format files on the old machine. It is common on those machines to put related records into the same file; for example, order header, detail and discount records would all be together. The rationale for this is that there is enough "common" information for those records that it is easier to put them all together, rather than break them out into separate files. Generally, the common fields are limited to key fields, after which the records have very little in common.

File design includes finding the longest record length of the different types, then adding a few pad bytes. Terrible design problems are perpetrated with this technique when additional fields need to be added. But it is usually done this way so that the records can be read in order, either by key or as a primary file. Apart from sorting and matching record processing, there is no easy way on the S/36 to sequence records from separate files, and besides, sorting and matching are of no help if the files need to be processed by key.

Given that a great deal of the effort in converting from the S/36 to the AS/400 involves splitting out those multiple-record type files into separate physical files, former S/36 programmers may be astonished to find that OS/400 provides a facility to group the records back into the same file. It's provided because there are valid reasons for processing your files in that manner. But there are compelling reasons to use the separate physical file technique, the primary reason being that a modification to one file of a related group does not affect the other files.

4 shows an example of the DDS that defines a multiple-format logical file for the sample database. This logical file includes the CUSMASTP file (Customer Master), the CUADDRP file (Customer Addresses), the ORDERSP file (Orders) and the ORDETLP file (Order Detail). Note that the first two record formats, CUMAST and CUADDR, are defined just as if they were in single-format logical files by themselves. However, the ORDERS and ORDETL formats include a peculiar key specification, the *NONE value.

Figure 4 shows an example of the DDS that defines a multiple-format logical file for the sample database. This logical file includes the CUSMASTP file (Customer Master), the CUADDRP file (Customer Addresses), the ORDERSP file (Orders) and the ORDETLP file (Order Detail). Note that the first two record formats, CUMAST and CUADDR, are defined just as if they were in single-format logical files by themselves. However, the ORDERS and ORDETL formats include a peculiar key specification, the *NONE value.

The primary key field for the logical file is the customer number field. This is defined in the four physical files as a decimal field, 5 digits with 0 decimal positions. To start the sequencing in the logical file, you list that key field as the first key for each of the record formats, using the name of the key field from the physical file. As in single-format logical files, you can use more than one key field. This is shown in the CUADDR format, where the second key field is the address number field. Assume for this example that the CAADNO (Address number) field is a DEC(3,0) field.

Assume also that the order number fields (ORORNO and ODORNO) in the ORDERS and ORDETL formats are defined as DEC(5,0), and that you want to use that field to sequence the order and order detail records in the logical file. This is a problem in the multiple-format logical file, since the second key field position is already defined as a DEC(3,0) field as a result of CUADDR specifying that field length prior to the ORDERS format. One of the rules for a logical file access path is that key fields in corresponding positions must be of the same data type and length. Because the second key fields for the CU- ADDR, ORDERS and ORDETL formats are different lengths [DEC(3,0) and DEC(5,0)], you cannot simply define the second key field for the order record formats as the order number field. If you try to create the logical file with unlike corresponding key fields, you'll encounter error message CPF3238 (Key field &1 not same as previous formats) and the file will not be created.

The *NONE value for the key specification is used in this situation. *NONE indicates that you do not have a field in that key field position, but that you do have key fields following. OS/400 accepts that and creates the file. When records are read from the logical file, all of the records for a customer are read from the CUADDR format before any records are read for the same customer from ORDERS. That happens because there is no relationship between the address records and the order records, other than the customer number.

The *NONE value is also used for the ORDETL format. In this case, there is a "header-detail" relationship between the ORDERS records and ORDETL records. There may be more than one detail record for each order, so those are sequenced by the order detail line number field (ODLNNO). In the ORDETL format, you see that the key fields are in agreement with the previously defined ORDERS format, so you can simply add the ODLNNO field as the last key field.

One of the strengths of logical files is their ability to use select/omit specifications for any of the record formats included in the logical file. Select/omit specifications could cause a problem, though, when utilized in conjunction with records that are used in a "header-detail" relationship. The problem occurs if the select/omit condition omits a header record but does not omit the corresponding detail records. In that case, sequentially reading the file will return detail records to your program for which a header record was not read.

Using a Multiple-format Logical File in RPG

Having done the extra work of creating a multiple-format logical file, you can take advantage of it to simplify your programs. 5 shows an RPG program fragment that reads the file. Note that the multiple read loops shown in 3 are replaced by a single read loop. The program is reading the logical file and using record identifying indicators to indicate which of the four record formats in the logical file is read.

Having done the extra work of creating a multiple-format logical file, you can take advantage of it to simplify your programs. Figure 5 shows an RPG program fragment that reads the file. Note that the multiple read loops shown in Figure 3 are replaced by a single read loop. The program is reading the logical file and using record identifying indicators to indicate which of the four record formats in the logical file is read.

The F-spec is used to specify the name of the multiple-format logical file. On the compiled listing, the record formats found in the file are listed under the file name. That is similar to the listing of a display file with multiple formats, which is the type of multiple-format file that you are probably most familiar with.

As shown in 5, we need I- specs to determine which record has been read. There is an I-spec for each of the record formats in the file. Note that the record format name is supplied on the I-spec, not the file name. Each record format is associated with its own record identifying indicator. The indicator is set on when a record is read from the file for the corresponding record format. It is vitally important that you remember that the record identifying indicators are not set off automatically if the file is read as a full procedural file. You must provide the coding to set the indicators off. If you read the file as a primary or secondary file, you do not have to set the record identifying indicators off.

As shown in Figure 5, we need I- specs to determine which record has been read. There is an I-spec for each of the record formats in the file. Note that the record format name is supplied on the I-spec, not the file name. Each record format is associated with its own record identifying indicator. The indicator is set on when a record is read from the file for the corresponding record format. It is vitally important that you remember that the record identifying indicators are not set off automatically if the file is read as a full procedural file. You must provide the coding to set the indicators off. If you read the file as a primary or secondary file, you do not have to set the record identifying indicators off.

6 shows an alternative, indicatorless method which uses the INFDS for the multiple-format logical. Simply define the INFDS, using a subfield with *RECORD in columns 44-50 of the I-specs and a field name in columns 53-58, such as RCDNAM. When you read CUSTFILL, RCDNAM will automatically contain the name of the record format just read-CUMAST, CUADDR, ORDERS or ORDETL. The field you specify for *RECORD is automatically defined as an eight-byte alphanumeric field.

Figure 6 shows an alternative, indicatorless method which uses the INFDS for the multiple-format logical. Simply define the INFDS, using a subfield with *RECORD in columns 44-50 of the I-specs and a field name in columns 53-58, such as RCDNAM. When you read CUSTFILL, RCDNAM will automatically contain the name of the record format just read-CUMAST, CUADDR, ORDERS or ORDETL. The field you specify for *RECORD is automatically defined as an eight-byte alphanumeric field.

The C-specs show a read loop that processes all records for a specific customer number. The SETLL (Set Lower Limit) operation is used to set a lower limit for a customer number against the file. You could supply a record format name as the factor 2 for the SETLL rather than the file name. For example, if you use the SETLL for record format ORDERS, then the records would be supplied from the logical file starting with the ORDERS format. When you want to read all of the records for a particular common key value, use the file name in the SETLL operation, as I've done in both examples.

After ensuring that there is at least one record in the access path with the specified customer number (indicator 98 is on), the loop starts. The record identifying indicators are set off, then a READE (Read Equal) operation is performed, again for the file. This is another operation where you can specify either the file name or the record format name. Because the program is supposed to process all records for the common key "customer," and because the program cannot predict what type of record will be supplied next, the file name is used rather than a record format name. Assuming that a record with an equal customer number key is read (indicator 99 is not set on), the program is told what type of record was read by the record identifying indicator or the RCDNAM field. For each READE operation, only one of the four record identifying indicators will be set on. The CASEQ (Case Equal) construct is shown as a simple example of how the program can process the record, once it has determined what type of record was read.

The advantage of using this method, rather than defining and reading the four files separately, is that you only need one read construct in the program, rather than four. The construct is easier to understand and maintain, since there is only one level to it. In contrast, reading the logical files used in this example as single-format logical files implies a multilevel read construct. The outer layer is a read operation against the customer master file. If that record is found, then a read loop is required to read the corresponding address file records. After that, another read loop is used to process the orders records. Embedded within that loop is a loop to read corresponding order detail records. This approach is troublesome if another file is added to the process or if a file has to be removed. For example, if order detail comment records are added, another embedded loop would have to be added to the order processing loop. With the multiple-format logical file method, you need only add another record identification I-spec and another CASEQ operation to direct processing for the comment records to their own subroutine.

If you need to process all of the records in the file, you should consider reading the file as a primary file. The processing in that case is considerably simpler, since the only required constructs are the I-spec record identifications and the CASEQ (or equivalent) constructs. The RPG cycle performs the same function as the read loop shown in Figures 5 and 6.

Ignoring a Record Format

There may be times when you need some, but not all, of the records in a multiple-format logical file. For example, using the logical file in 4, you may want to read the CUMAST, ORDERS and ORDETL records, but not the CUADDR records. You can choose either to not process the records in your program or to ignore the record format entirely.

There may be times when you need some, but not all, of the records in a multiple-format logical file. For example, using the logical file in Figure 4, you may want to read the CUMAST, ORDERS and ORDETL records, but not the CUADDR records. You can choose either to not process the records in your program or to ignore the record format entirely.

Not processing is a decision made in your program. Using the program in 5 as an example, you can ignore the CUADDR records by simply removing the CASEQ operation for *IN02. You will still need the I-spec record identification for the CUADDR format. You can include or omit the record identifying indicator on the I-spec. If you remove the I-spec, an undefined record type error will occur when the program reads from the file and gets a record from the CUADDR format, but this will not halt processing.

Not processing is a decision made in your program. Using the program in Figure 5 as an example, you can ignore the CUADDR records by simply removing the CASEQ operation for *IN02. You will still need the I-spec record identification for the CUADDR format. You can include or omit the record identifying indicator on the I-spec. If you remove the I-spec, an undefined record type error will occur when the program reads from the file and gets a record from the CUADDR format, but this will not halt processing.

The other option is to ignore the record format entirely. This is done with the F-spec continuation shown in 7. The IGNORE continuation option is used, with the name of the record format that is to be ignored. As read requests are passed to the OS/400 database, the database is informed that any records belonging in the CUADDR format are not to be given to the program. Using the IGNORE option is almost the same as removing the record format from the logical file. As far as the program is concerned, the ignored format is not in the logical file. However, the ignored records are still read by the lower level file access routines that your program uses, so there is the same overhead of the actual read from disk. Records are read and discarded until the next record for one of the included record formats is read.

The other option is to ignore the record format entirely. This is done with the F-spec continuation shown in Figure 7. The IGNORE continuation option is used, with the name of the record format that is to be ignored. As read requests are passed to the OS/400 database, the database is informed that any records belonging in the CUADDR format are not to be given to the program. Using the IGNORE option is almost the same as removing the record format from the logical file. As far as the program is concerned, the ignored format is not in the logical file. However, the ignored records are still read by the lower level file access routines that your program uses, so there is the same overhead of the actual read from disk. Records are read and discarded until the next record for one of the included record formats is read.

Using a Single-format Logical Instead of a Multiple-format Logical

You probably would not want to read a logical file such as the one used in this example to process just the CUMAST records. The reason for that is because each customer record is probably separated by a great number of other records (address records and order records). For example, two customer records could be separated by dozens or hundreds of intervening records. Reading the customer records sequentially would mean reading all of those other records also.

In this case, it would be preferable to simply have a single-format logical file defined over the customer master file. You might choose to define a single-format file even if the key is the same as the usage of the customer master in the multiple-format logical file. If you can define the access paths so that they are similar enough, the system will share the access paths between the files. That means that the apparent overhead of maintaining two logical files is not really there. A change to the access path of the single- format logical file is the same change for that record format in the multiple- format logical file. The AS/400 Database Guide gives details about how access paths can be shared.

Join Logical Files

A join logical file is used when you need to get related fields from different files into one record format. This differs from a multiple-format logical file in that there is only one record format in a join logical file, and all of the information from the related files is presented to your program in that record format. Reading one record from a join file might actually cause up to 32 physical file records to be read. A join logical file is similar to using the OPNQRYF command to create a view, although the OPNQRYF method includes the important capability of using fields from any of the joined files to form the access path. The access path of a join logical file can only be created with fields from the primary file in the join specification. (For a more complete discussion of creating join logical files, see the February 1992 issue of Midrange Computing, "Get Relation-al and Join.")

Because of the key field limitation, a join logical file cannot always be used in the place of a multiple-format logical file (or multiple-format processing in your program). For example, if the multiple-format logical file shown in 4 is instead defined as a join logical file, the entire key for the record format would be limited to fields in the CUMASTP file. That means that some of the important access path definition features are not available to you. So when special access path definitions are needed, or sequential or indexed sequential processing is required, a join logical file is probably not the best choice.

Because of the key field limitation, a join logical file cannot always be used in the place of a multiple-format logical file (or multiple-format processing in your program). For example, if the multiple-format logical file shown in Figure 4 is instead defined as a join logical file, the entire key for the record format would be limited to fields in the CUMASTP file. That means that some of the important access path definition features are not available to you. So when special access path definitions are needed, or sequential or indexed sequential processing is required, a join logical file is probably not the best choice.

Join logical files are most useful when there are related "facts" about a record in a single record of another file, not when there are multiple related "records", as in a header-detail situation. An example of related facts is shown in the sample database in 2. The customer record contains two fields, CUSLS (Salesperson) and CUTYPE (Cus-tomer Type). These fields are codes; that is, the code is kept in another database file along with descriptive information about the code. The RPG program in 3 shows how the related fact is usually retrieved: with the CHAIN operation.

Join logical files are most useful when there are related "facts" about a record in a single record of another file, not when there are multiple related "records", as in a header-detail situation. An example of related facts is shown in the sample database in Figure 2. The customer record contains two fields, CUSLS (Salesperson) and CUTYPE (Cus-tomer Type). These fields are codes; that is, the code is kept in another database file along with descriptive information about the code. The RPG program in Figure 3 shows how the related fact is usually retrieved: with the CHAIN operation.

When you are creating or updating a record that includes related fact fields, you will probably use coding such as is shown in 3. But when you read the record, either for display or printing, you can take advantage of the join logical file. Rather than recreate the code to get the related information, you define the join logical file and let the system retrieve the information. The retrieval is done as part of your read request. The record that is presented to your program includes whatever fields you defined for the customer master record, in addition to fields from related files.

When you are creating or updating a record that includes related fact fields, you will probably use coding such as is shown in Figure 3. But when you read the record, either for display or printing, you can take advantage of the join logical file. Rather than recreate the code to get the related information, you define the join logical file and let the system retrieve the information. The retrieval is done as part of your read request. The record that is presented to your program includes whatever fields you defined for the customer master record, in addition to fields from related files.

8 shows an example of a join logical file used to get fields related to the customer master record. The join is done by corresponding fields in the files. When a record is returned to the program in the CUMAST record format, the four "CU" fields are from the customer master record. In addition, the salesman name and customer type description are part of the record.

Figure 8 shows an example of a join logical file used to get fields related to the customer master record. The join is done by corresponding fields in the files. When a record is returned to the program in the CUMAST record format, the four "CU" fields are from the customer master record. In addition, the salesman name and customer type description are part of the record.

It is possible to define and use a join logical file to process records in a "header-detail" relationship. But is that really the approach that you want to use? To replace the multiple-format logical file shown in 4, you would have to create a join logical file that lists all of the fields from the four files. You would then have to create the join specifications, which in this case are more complicated because there are multiple levels of join (CUMASTP to ORDERSP, ORDERSP to ORDETLP). You will probably also have to specify a number of Join Duplicate Sequence (JDUPSEQ) statements to simulate what the key fields for each format in the multiple-format logical file provide: retrieval in order number/order line sequence. This is not a very useful construct, especially when the simpler multiple-format logical file is available as an alternative.

It is possible to define and use a join logical file to process records in a "header-detail" relationship. But is that really the approach that you want to use? To replace the multiple-format logical file shown in Figure 4, you would have to create a join logical file that lists all of the fields from the four files. You would then have to create the join specifications, which in this case are more complicated because there are multiple levels of join (CUMASTP to ORDERSP, ORDERSP to ORDETLP). You will probably also have to specify a number of Join Duplicate Sequence (JDUPSEQ) statements to simulate what the key fields for each format in the multiple-format logical file provide: retrieval in order number/order line sequence. This is not a very useful construct, especially when the simpler multiple-format logical file is available as an alternative.

On the other hand, using the join logical file in a program is certainly simpler than using the multiple-format logical file. Because you are working with only one record format, you do not need to include record identifying specifications and a control construct to direct processing for each type of record format.

Picking the Right Logical File

No hard-and-fast rules can dictate which logical file you should use, without fail, in a given situation. The choice is yours, and it's not always easy. You can choose single format logical files, multi-format logical files or join logical files. The determinants seem to be the number of physical files referenced and the likelihood of reusing the more complicated file definition. If your multiple file uses are simple header-detail situations with only two files, it may be easier to simply read the two files. However, as the short code examples have shown, the complication of the code required to read header-detail files escalates rapidly as more files are added to the relationship. This set of circumstances suggests the use of multiple-format logicals.

Deciding to use a join logical file is more complicated, primarily because a join file is read only. If your program needs to access a record for update, and there are related records, it is probably easier to just use the single- format logical files. But if there is not an update requirement, the decision is more complicated. Would you create a join logical file for only one related file? For two? This then becomes a question of frequency of use, in terms of how often you have to program for those particular files If you have a master record with many related records, it may be advantageous to create a join logical file that contains all (or as many as possible) of the related records. You can use that join logical file in any programs that use one or more of the related records, with the attitude that the additional fields that are returned are of no importance if you don't need them.

These decisions are not always easy to make. The problem is that one way, you can just use single-format logical files and write a lot of code. The other way, you can have the system do the retrieval work and write less code, but you may lose some flexibility. This is not so much of a concern with multiple- format logical files, but does apply to the read-only nature of a join logical file. Though you may still end up favoring single-format logicals in some cases, adding multiple-format and join logicals to your repertoire helps you to evaluate the best approach to each situation before you've finished the job.

References AS/400 Database Guide (SC41-9659, CD-ROM QBKA7201) Midrange Computing, February 1992, "Get Relational and Join" RPG/400 Reference (SC09-1349, CD-ROM QBKA4E01)


Multi-format and Join Logicals

Figure 1 Customer record, file CUMASTP

 
  Figure 1: Customer Record-File CUMASTP 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  A          R CUMAST                    TEXT('Customer master file') 
  A            CUSNO          5  0       TEXT('Customer number') 
  A            CUNAME        30          TEXT('Customer name') 
  A            CUSLS          5          TEXT('Sales person ID') 
  A            CUTYPE         5          TEXT('Customer type code') 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 

Multi-format and Join Logicals

Figure 2 Sample database for customers

 
  Figure 2: Sample Database for Customers 
 
  File                    Record Format                Description 
 
  CUMASTP        CUMAST            Customer master 
  CUMASTL        CUMAST            Customer master - logical by CUSNO 
  CUADDRP        CUADDR            Customer addresses 
  ORDERSP        ORDERS            Orders master 
  ORDETLP        ORDETL            Order details 
  CUTYPEP        CUTYPE            Customer type code 
  SLSMSTP        SLSMST            Sales person master 

Multi-format and Join Logicals

Figure 3 Sample RPG program to access customer database

 
  Figure 3: Sample RPG Program to Access Customer Database 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  FCUMASTL IF  E           K        DISK 
  FCUADDRP IF  E           K        DISK 
  FSLSMSTP IF  E           K        DISK 
  FORDERSP IF  E           K        DISK 
  FORDETLP IF  E           K        DISK 
  C                     READ CUMASTL                  99*99 - EOF 
  C* 
  C*  GET CUSTOMER ADDRESS RECORDS 
  C* 
  C           *IN99     IFEQ *OFF                       *NOT EOF 
  C           CUSNO     SETLLCUADDRP                  99*99 - FOUND 
  C* 
  C           *IN99     IFEQ *ON                        *FOUND RECORD 
  C           *IN99     DOUEQ*OFF                       *UNTIL NE KEY 
  C           CUSNO     READECUADDRP                  99*99 - NE KEY 
  C                      . 
  C                      . 
  C                     ENDDO 
  C                     ENDIF 
  C                     ENDIF 
  C* 
  C*  GET SALES PERSON RECORD 
  C* 
  C           CUSLS     CHAINSLSMSTP              99    *99 - NRF 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 

Multi-format and Join Logicals

Figure 4 DDS for multiple-format logical file

 
  Figure 4: DDS for Multiple-format Logical File 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  A*  LOGICAL FILE CUSFILL 
  A*  MULTIPLE-FORMAT LOGICAL OVER CUMASTP, CUADDRP, ORDERSP, ORDETLP 
  A 
  A          R CUMAST                    PFILE(CUMASTP) 
  A          K CUSNO 
  A 
  A          R CUADDR                    PFILE(CUADDRP) 
  A          K CACSNO 
  A          K CAADNO 
  A 
  A          R ORDERS                    PFILE(ORDERSP) 
  A          K ORCSNO 
  A          K *NONE 
  A          K ORORNO 
  A 
  A          R ORDETL                    PFILE(ORDETLP) 
  A          K ODCSNO 
  A          K *NONE 
  A          K ODORNO 
  A          K ODLNNO 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 

Multi-format and Join Logicals

Figure 5 Using multiple-format logical file

 
  Figure 5:  Using Multiple-format Logical File 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  FCUSFILL IF  E           K        DISK 
  ICUMAST      01 
  ICUADDR      02 
  IORDERS      03 
  IORDETL      04 
  C* 
  C           CSNO      SETLLCUSFILL                  98*98 - FOUND 
  C* 
  C           *IN98     IFEQ *ON                        *EQ KEY FOUND 
  C           *IN99     DOUEQ*ON                        *UNTIL NE KEY 
  C                     SETOF                     010203 
  C                     SETOF                     04 
  C           CSNO      READECUSFILL                  99*99 ON - NE KEY 
  C* 
  C           *IN99     IFEQ *OFF                       *EQ KEY FOUND 
  C           *IN01     CASEQ*ON       #CUMS            *CUMAST RECORD 
  C           *IN02     CASEQ*ON       #CUAD            *CUADDR RECORD 
  C           *IN03     CASEQ*ON       #ORDR            *ORDERS RECORD 
  C           *IN04     CASEQ*ON       #ORDT            *ORDETL RECORD 
  C                     ENDCS 
  C                     ENDIF 
  C                     ENDDO 
  C                     ENDIF 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 

Multi-format and Join Logicals

Figure 6 Inicatorless alternative to Figure 5

 
  Figure 6:  Indicatorless Alternative to Figure 5 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  FCUSFILL IF  E           K        DISK 
  F                                              KINFDS INFDS 
  IINFDS       DS 
  I                                     *RECORD  RCDNAM 
  C* 
  C           CSNO      SETLLCUSFILL                  98*98 - FOUND 
  C* 
  C           *IN98     IFEQ *ON                        *EQ KEY FOUND 
  C           *IN99     DOUEQ*ON                        *UNTIL NE KEY 
  C           CSNO      READECUSFILL                  99*99 ON - NE KEY 
  C* 
  C           *IN99     IFEQ *OFF                       *EQ KEY FOUND 
  C           RCDNAM    CASEQ'CUMAST'  #CUMS            *CUMAST RECORD 
  C           RCDNAM    CASEQ'CUADDR'  #CUAD            *CUADDR RECORD 
  C           RCDNAM    CASEQ'ORDERS'  #ORDR            *ORDERS RECORD 
  C           RCDNAM    CASEQ'ORDETL'  #ORDT            *ORDETL RECORD 
  C                     ENDCS 
  C                     ENDIF 
  C                     ENDDO 
  C                     ENDIF 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 

Multi-format and Join Logicals

Figure 7 Ignoring a record format in multiple-format LF

 
  Figure 7: Ignoring a Record Format in a Multiple-format Logical File 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  FCUSFILL IF  E           K        DISK 
  F                                              KIGNORECUADDR 

Multi-format and Join Logicals

Figure 8 Join logical file for customer database

 
  Figure 8: Join Logical File for Customer Database 
 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
  A*  JOIN LOGICAL FILE FOR CUSTOMER DATABASE 
  A* 
  A          R CUMAST                    JFILE(CUMASTP SLSMSTP CUTYPEP) 
  A          J                           JOIN(CUMASTP SLSMSTP) 
  A                                      JFLD(CUSLS SMSLS) 
  A          J                           JOIN(CUMASTP CUTYPEP) 
  A                                      JFLD(CUTYPE CTTYPE) 
  A            CUSNO 
  A            CUNAME 
  A            CUSLS 
  A            SMNAME 
  A            CUTYPE 
  A            CTDESC 
  A          K CUNAME 
  ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+ 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

RESOURCE CENTER

  • WHITE PAPERS

  • WEBCAST

  • TRIAL SOFTWARE

  • Mobile Computing and the IBM i

    SB ASNA PPL 5450Mobile computing is rapidly maturing into a solid platform for delivering enterprise applications. Many IBM i shops today are realizing that integrating their IBM i with mobile applications is the fast path to improved business workflows, better customer relations, and more responsive business reporting.

    This ASNA whitepaper takes a look at mobile computing for the IBM i. It discusses the different ways mobile applications may be used within the enterprise and how ASNA products solve the challenges mobile presents. It also presents the case that you already have the mobile programming team your projects need: that team is your existing RPG development team!

    Get your copy today!

  • Automate IBM i Operations using Wireless Devices

    DDL SystemsDownload the technical whitepaper on MANAGING YOUR IBM i WIRELESSLY and (optionally) register to download an absolutely FREE software trail. This whitepaper provides an in-depth review of the native IBM i technology and ACO MONITOR's advanced two-way messaging features to remotely manage your IBM i while in or away from the office. Notify on-duty personnel of system events and remotely respond to complex problems (via your Smartphone) before they become critical-24/7. Problem solved!

    Order your copy here.

  • DR Strategy Guide from Maxava: Brand New Edition - now fully updated to include Cloud!

    SB Maxava PPL 5476PRACTICAL TOOLS TO IMPLEMENT DISASTER RECOVERY IN YOUR IBM i ENVIRONMENT

    CLOUD VS. ON-PREMISE?
    - COMPREHENSIVE CHECKLISTS
    - RISK COST CALCULATIONS
    - BUSINESS CASE FRAMEWORK
    - DR SOLUTIONS OVERVIEW
    - RFP BUILDER
    Download your free copy of DR Strategy Guide for IBM i from Maxava today.

     

  • 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!

     

  • 2020 IBM i Marketplace Survey Results

    HelpSystems

    This year marks the sixth edition of the popular IBM i Marketplace Survey Results. Each year, HelpSystems sets out to gather data about how businesses use the IBM i platform and the IT initiatives it supports. Year over year, the survey has begun to reveal long-term trends that give insight into the future of this trusted technology.

    More than 500 IBM i users from around the globe participated in this year’s survey, and we’re so happy to share the results with you. We hope you’ll find the information interesting and useful as you evaluate your own IT projects.

  • AIX Security Basics eCourse

    Core Security

    With so many organizations depending on AIX day to day, ensuring proper security and configuration is critical to ensure the safety of your environment. Don’t let common threats put your critical AIX servers at risk. Avoid simple mistakes and start to build a long-term plan with this AIX Security eCourse. Enroll today to get easy to follow instructions on topics like:

    • Removing extraneous files
    • Patching systems efficiently
    • Setting and validating permissions
    • Managing service considerations
    • Getting overall visibility into your networks

     

  • 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

    HelpSystemsIT 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

     

  • IBM i Resources Retiring?

    SB HelpSystems WC GenericLet’s face it: IBM i experts and RPG programmers are retiring from the workforce. Are you prepared to handle their departure?
    Our panel of IBM i experts—Chuck Losinski, Robin Tatam, Richard Schoen, and Tom Huntington—will outline strategies that allow your company to cope with IBM i skills depletion by adopting these strategies that allow you to get the job done without deep expertise on the OS:
    - Automate IBM i processes
    - Use managed services to help fill the gaps
    - Secure the system against data loss and viruses
    The strategies you discover in this webinar will help you ensure that your system of record—your IBM i—continues to deliver a powerful business advantage, even as staff retires.

     

  • Backup and Recovery Considerations for Security Data and Encrypted Backups

    SB PowerTech WC GenericSecurity expert Carol Woodbury is joined by Debbie Saugen. Debbie is an expert on IBM i backup and recovery, disaster recovery, and high availability, helping IBM i shops build and implement effective business continuity plans.
    In today’s business climate, business continuity is more important than ever. But 83 percent of organizations are not totally confident in their backup strategy.
    During this webinar, Carol and Debbie discuss the importance of a good backup plan, how to ensure you’re backing up your security information, and your options for encrypted back-ups.

  • Profound.js: The Agile Approach to Legacy Modernization

    SB Profound WC GenericIn this presentation, Alex Roytman and Liam Allan will unveil a completely new and unique way to modernize your legacy applications. Learn how Agile Modernization:
    - Uses the power of Node.js in place of costly system re-writes and migrations
    - Enables you to modernize legacy systems in an iterative, low-risk manner
    - Makes it easier to hire developers for your modernization efforts
    - Integrates with Profound UI (GUI modernization) for a seamless, end-to-end legacy modernization solution

     

  • Data Breaches: Is IBM i Really at Risk?

    SB PowerTech WC GenericIBM i is known for its security, but this OS could be more vulnerable than you think.
    Although Power Servers often live inside the safety of the perimeter firewall, the risk of suffering a data leak or data corruption remains high.
    Watch noted IBM i security expert Robin Tatam as he discusses common ways that this supposedly “secure” operating system may actually be vulnerable and who the culprits might be.

    Watch the webinar today!

     

  • Easy Mobile Development

    SB Profound WC GenericWatch this on-demand webinar and learn how to rapidly and easily deploy mobile apps to your organization – even when working with legacy RPG code! IBM Champion Scott Klement will demonstrate how to:
    - Develop RPG applications without mobile development experience
    - Deploy secure applications for any mobile device
    - Build one application for all platforms, including Apple and Android
    - Extend the life and reach of your IBM i (aka iSeries, AS400) platform
    You’ll see examples from customers who have used our products and services to deliver the mobile applications of their dreams, faster and easier than they ever thought possible!

     

  • Profound UI: Unlock True Modernization from your IBM i Enterprise

    SB Profound PPL 5491Modern, web-based applications can make your Enterprise more efficient, connected and engaged. This session will demonstrate how the Profound UI framework is the best and most native way to convert your existing RPG applications and develop new modern applications for your business. Additionally, you will learn how you can address modernization across your Enterprise, including databases and legacy source code, with Profound Logic.

  • Node Webinar Series Pt. 1: The World of Node.js on IBM i

    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.

    Part 1 will teach you what Node.js is, why it's a great option for IBM i shops, and how to take advantage of the ecosystem surrounding Node.

    In addition to background information, our Director of Product Development Scott Klement will demonstrate applications that take advantage of the Node Package Manager (npm).

  • 5 New and Unique Ways to Use the IBM i Audit Journal

    SB HelpSystems ROBOT GenericYou must be asking yourself: am I doing everything I can to protect my organization’s data? Tune in as our panel of IBM i high availability experts discuss:


    - Why companies don’t test role swaps when they know they should
    - Whether high availability in the cloud makes sense for IBM i users
    - Why some organizations don’t have high availability yet
    - How to get high availability up and running at your organization
    - High availability considerations for today’s security concerns

  • Profound.js 2.0: Extend the Power of Node to your IBM i Applications

    SB Profound WC 5541In this Webinar, we'll demonstrate how Profound.js 2.0 enables you to easily adopt Node.js in your business, and to take advantage of the many benefits of Node, including access to a much larger pool of developers for IBM i and access to countless reusable open source code packages on npm (Node Package Manager).
    You will see how Profound.js 2.0 allows you to:

    • Provide RPG-like capabilities for server-side JavaScript.
    • Easily create web and mobile application interfaces for Node on IBM i.
    • Let existing RPG programs call Node.js modules directly, and vice versa.
    • Automatically generate code for Node.js.
    • Automatically converts existing RPGLE code into clean, simplified Node.js code.

    Download and watch today!

     

  • Make Modern Apps You'll Love with Profound UI & Profound.js

    SB Profound WC 5541Whether you have green screens or a drab GUI, your outdated apps can benefit from modern source code, modern GUIs, and modern tools.
    Profound Logic's Alex Roytman and Liam Allan are here to show you how Free-format RPG and Node.js make it possible to deliver applications your whole business will love:

    • Transform legacy RPG code to modern free-format RPG and Node.js
    • Deliver truly modern application interfaces with Profound UI
    • Extend your RPG applications to include Web Services and NPM packages with Node.js

     

  • Accelerating Programmer Productivity with Sequel

    SB_HelpSystems_WC_Generic

    Most business intelligence tools are just that: tools, a means to an end but not an accelerator. Yours could even be slowing you down. But what if your BI tool didn't just give you a platform for query-writing but also improved programmer productivity?
    Watch the recorded webinar to see how Sequel:

    • Makes creating complex results simple
    • Eliminates barriers to data sources
    • Increases flexibility with data usage and distribution

    Accelerated productivity makes everyone happy, from programmer to business user.

  • Business Intelligence is Changing: Make Your Game Plan

    SB_HelpSystems_WC_GenericIt’s time to develop a strategy that will help you meet your informational challenges head-on. Watch the webinar to learn how to set your IT department up for business intelligence success. You’ll learn how the right data access tool will help you:

    • Access IBM i data faster
    • Deliver useful information to executives and business users
    • Empower users with secure data access

    Ready to make your game plan and finally keep up with your data access requests?

     

  • Controlling Insider Threats on IBM i

    SB_HelpSystems_WC_GenericLet’s face facts: servers don’t hack other servers. Despite the avalanche of regulations, news headlines remain chock full of stories about data breaches, all initiated by insiders or intruders masquerading as insiders.
    User profiles are often duplicated or restored and are rarely reviewed for the appropriateness of their current configuration. This increases the risk of the profile being able to access data without the intended authority or having privileges that should be reserved for administrators.
    Watch security expert Robin Tatam as he discusses a new approach for onboarding new users on IBM i and best-practices techniques for managing and monitoring activities after they sign on.

  • Don't Just Settle for Query/400...

    SB_HelpSystems_WC_GenericWhile introducing Sequel Data Access, we’ll address common frustrations with Query/400, discuss major data access, distribution trends, and more advanced query tools. Plus, you’ll learn how a tool like Sequel lightens IT’s load by:

    - Accessing real-time data, so you can make real-time decisions
    - Providing run-time prompts, so users can help themselves
    - Delivering instant results in Microsoft Excel and PDF, without the wait
    - Automating the query process with on-demand data, dashboards, and scheduled jobs

  • How to Manage Documents the Easy Way

    SB_HelpSystems_WC_GenericWhat happens when your company depends on an outdated document management strategy?
    Everything is harder.
    You don’t need to stick with status quo anymore.
    Watch the webinar to learn how to put effective document management into practice and:

    • Capture documents faster, instead of wasting everyone’s time
    • Manage documents easily, so you can always find them
    • Distribute documents automatically, and move on to the next task

     

  • Lessons Learned from the AS/400 Breach

    SB_PowerTech_WC_GenericGet actionable info to avoid becoming the next cyberattack victim.
    In “Data breach digest—Scenarios from the field,” Verizon documented an AS/400 security breach. Whether you call it AS/400, iSeries, or IBM i, you now have proof that the system has been breached.
    Watch IBM i security expert Robin Tatam give an insightful discussion of the issues surrounding this specific scenario.
    Robin will also draw on his extensive cybersecurity experience to discuss policies, processes, and configuration details that you can implement to help reduce the risk of your system being the next victim of an attack.

  • Overwhelmed by Operating Systems?

    SB_HelpSystems_WC_GenericIn this 30-minute recorded webinar, our experts demonstrate how you can:

    • Manage multiple platforms from a central location
    • View monitoring results in a single pane of glass on your desktop or mobile device
    • Take advantage of best practice, plug-and-play monitoring templates
    • Create rules to automate daily checks across your entire infrastructure
    • Receive notification if something is wrong or about to go wrong

    This presentation includes a live demo of Network Server Suite.

     

  • Real-Time Disk Monitoring with Robot Monitor

    SB_HelpSystems_WC_GenericYou need to know when IBM i disk space starts to disappear and where it has gone before system performance and productivity start to suffer. Our experts will show you how Robot Monitor can help you pinpoint exactly when your auxiliary storage starts to disappear and why, so you can start taking a proactive approach to disk monitoring and analysis. You’ll also get insight into:

    • The main sources of disk consumption
    • How to monitor temporary storage and QTEMP objects in real time
    • How to monitor objects and libraries in real time and near-real time
    • How to track long-term disk trends

     

     

  • Stop Re-keying Data Between IBM I and Other Applications

    SB_HelpSystems_WC_GenericMany business still depend on RPG for their daily business processes and report generation.Wouldn’t it be nice if you could stop re-keying data between IBM i and other applications? Or if you could stop replicating data and start processing orders faster? Or what if you could automatically extract data from existing reports instead of re-keying? It’s all possible. Watch this webinar to learn about:

    • The data dilemma
    • 3 ways to stop re-keying data
    • Data automation in practice

    Plus, see how HelpSystems data automation software will help you stop re-keying data.

     

  • The Top Five RPG Open Access Myths....BUSTED!

    SB_Profound_WC_GenericWhen it comes to IBM Rational Open Access: RPG Edition, there are still many misconceptions - especially where application modernization is concerned!

    In this Webinar, we'll address some of the biggest myths about RPG Open Access, including:

    • Modernizing with RPG OA requires significant changes to the source code
    • The RPG language is outdated and impractical for modernizing applications
    • Modernizing with RPG OA is the equivalent to "screen scraping"

     

  • Time to Remove the Paper from Your Desk and Become More Efficient

    SB_HelpSystems_WC_GenericToo much paper is wasted. Attempts to locate documents in endless filing cabinets.And distributing documents is expensive and takes up far too much time.
    These are just three common reasons why it might be time for your company to implement a paperless document management system.
    Watch the webinar to learn more and discover how easy it can be to:

    • Capture
    • Manage
    • And distribute documents digitally

     

  • IBM i: It’s Not Just AS/400

    SB_HelpSystems_WC_Generic

    IBM’s Steve Will talks AS/400, POWER9, cognitive systems, and everything in between

    Are there still companies that use AS400? Of course!

    IBM i was built on the same foundation.
    Watch this recorded webinar with IBM i Chief Architect Steve Will and IBM Power Champion Tom Huntington to gain a unique perspective on the direction of this platform, including:

    • IBM i development strategies in progress at IBM
    • Ways that Watson will shake hands with IBM i
    • Key takeaways from the AS/400 days

     

  • Ask the RDi Experts

    SB_HelpSystems_WC_GenericWatch this recording where Jim Buck, Susan Gantner, and Charlie Guarino answered your questions, including:

    • What are the “hidden gems” in RDi that can make me more productive?
    • What makes RDi Debug better than the STRDBG green screen debugger?
    • How can RDi help me find out if I’ve tested all lines of a program?
    • What’s the best way to transition from PDM to RDi?
    • How do I convince my long-term developers to use RDi?

    This is a unique, online opportunity to hear how you can get more out of RDi.

     

  • 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 NodeRun.com as a pre-built development environment

     

     

  • Inside the Integrated File System (IFS)

    SB_HelpSystems_WC_GenericDuring this webinar, you’ll learn basic tips, helpful tools, and integrated file system commands—including WRKLNK—for managing your IFS directories and Access Client Solutions (ACS). We’ll answer your most pressing IFS questions, including:

    • What is stored inside my IFS directories?
    • How do I monitor the IFS?
    • How do I replicate the IFS or back it up?
    • How do I secure the IFS?

    Understanding what the integrated file system is and how to work with it must be a critical part of your systems management plans for IBM i.

     

  • 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.

  • How to Meet the Newest Encryption Requirements on IBM i

    SB PowerTech WC GenericA growing number of compliance mandates require sensitive data to be encrypted. But what kind of encryption solution will satisfy an auditor and how can you implement encryption on IBM i? Watch this on-demand webinar to find out how to meet today’s most common encryption requirements on IBM i. You’ll also learn:

    • Why disk encryption isn’t enough
    • What sets strong encryption apart from other solutions
    • Important considerations before implementing encryption

     

     

  • 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.

     

     

  • Fight Cyber Threats with IBM i Encryption

    SB PowerTech WC GenericCyber attacks often target mission-critical servers, and those attack strategies are constantly changing. To stay on top of these threats, your cybersecurity strategies must evolve, too. In 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

     

     

     

  • 10 Practical IBM i Security Tips for Surviving Covid-19 and Working From Home

    SB PowerTech WC GenericNow that many organizations have moved to a work from home model, security concerns have risen.

    During this session Carol Woodbury will discuss the issues that the world is currently seeing such as increased malware attacks and then provide practical actions you can take to both monitor and protect your IBM i during this challenging time.

     

  • How to Transfer IBM i Data to Microsoft Excel

    SB_HelpSystems_WC_Generic3 easy ways to get IBM i data into Excel every time
    There’s an easy, more reliable way to import your IBM i data to Excel? It’s called Sequel. During this webinar, our data access experts demonstrate how you can simplify the process of getting data from multiple sources—including Db2 for i—into Excel. Watch to learn how to:

    • Download your IBM i data to Excel in a single step
    • Deliver data to business users in Excel via email or a scheduled job
    • Access IBM i data directly using the Excel add-in in Sequel

    Make 2020 the year you finally see your data clearly, quickly, and securely. Start by giving business users the ability to access crucial business data from IBM i the way they want it—in Microsoft Excel.

     

     

  • HA Alternatives: MIMIX Is Not Your Only Option on IBM i

    SB_HelpSystems_WC_GenericIn this recorded webinar, our experts introduce you to the new HA transition technology available with our Robot HA software. You’ll learn how to:

    • Transition your rules from MIMIX (if you’re happy with them)
    • Simplify your day-to-day activities around high availability
    • Gain back time in your work week
    • Make your CEO happy about reducing IT costs

    Don’t stick with a legacy high availability solution that makes you uncomfortable when transitioning to something better can be simple, safe, and cost-effective.

     

     

  • 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

    SB HelpSystems SC 5413Robot 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

    SB HelpSystems SC 5413Robot 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.

  • ACO MONITOR Manages your IBM i 24/7 and Notifies You When Your IBM i Needs Assistance!

    SB DDL Systems 5429More than a paging system - ACO MONITOR is a complete systems management solution for your Power Systems running IBM i. ACO MONITOR manages your Power System 24/7, uses advanced technology (like two-way messaging) to notify on-duty support personnel, and responds to complex problems before they reach critical status.

    ACO MONITOR is proven technology and is capable of processing thousands of mission-critical events daily. The software is pre-configured, easy to install, scalable, and greatly improves data center efficiency.