Skip to main content

Read data in IFS file from SQL - IBM i

IFS Stream File

IFS (Integrated File System) Stream files are major part of any (or most of) IBM i applications. Having to read data from the Stream files become necessary. 

We can read the IFS file from Programs in two different ways. 
  • By copying the data from IFS file to Database file (CPYFRMSTMF or CPYFRMIMPF).
  • By using 'open' & 'read' procedures written in 'C' language. Click Here to see more about how to read IFS file using these procedures from RPGLE.

One other way to do this is by using SQL table function 'IFS_READ'. There are couple of more table functions 'IFS_READ_BINARY' and 'IFS_READ_UTF8' to read the data and return in Binary and UTF8 formats accordingly. 

In this post, we will see how to read IFS file using 'IFS_READ' and little about the other two table functions towards the end.

E.g.: 

Read IFS file from SQL

Above query is simple and straight forward, All we need to do is pass the required file name (along with full path) against parameter 'PATH_NAME'.

Read IFS file from SQL

This table function has got only two columns. 
  • 'LINE_NUMBER' - Indicates the position of the line in file.
  • 'LINE' - Actual data in the file.

Let's say if there is a limit on the number of characters to receive, We can control this using MAXIMUM_LINE_LENGTH parameter. 

Read IFS file from SQL

  • Parameter 'MAXIMUM_LINE_LENGTH' accepts numeric values.
Read IFS file from SQL

If we look at the above result, each row contains only 12 digits and any additional characters has been returned as new line. 

Line number 1, 4 & 7 has length of 12 digits and has returned only one row. Line numbers 2 & 6 are exceeding 12 digits, so only 12 digits are returned and the rest are returned as new lines (3 & 6).

There is another important parameter 'END_OF_LINE' this is used to determine the end of line in Stream file. Let's have a look at how it makes difference before we see the list of valid values. 

Read IFS file in SQL

In the above query, 'NONE' is passed as 'END_OF_LINE', Query will not consider any End of Line characters. 

Read IFS file in SQL

All the records has been returned in a single row. Number of digits allowed in a single line can be controlled using 'MAXIMUM_LINE_LENGTH'. If nothing is specified, by default 2GB is returned in a single line and the next is returned in a new line. 

Below are the possible options for END_OF_LINE parameter.
  • CRLF - A Carriage return and Line feed indicate End of line.
  • LFCR - A Line feed and Carriage return indicate End of line.
  • CR - A Carriage return indicate End of line.
  • LF - A Line feed indicate End of line.
  • ANY - Any of the above four indicate End of line (Default for IFS_READ & IFS_READ_UTF8).
  • NONE - No End of line characters are considered (Default and only allowed value for IFS_READ_BINARY). 

Let's see a simple example of how to get the data in Binary format using IFS_READ_BINARY. 

Read IFS file in Binary mode from SQL

Parameters are same as IFS_READ except 'END_OF_LINE' which always accepts 'NONE'. This implies that IFS_READ_BINARY always returns a single row (MAXIMUM_LINE_LENGTH restrictions apply).

Read IFS file from SQL in Binary format

In the same way, data can be retrieved in UTF8 format using IFS_READ_UTF8. 

Below is the syntax of IFS_READ with all the parameters.

SELECT * FROM
         TABLE(QSYS2/IFS_READ(
               PATH_NAME => 'ifs_path_name',
               MAXIMUM_LINE_LENGTH => maximum_length(in decimal),
               END_OF_LINE => 'end_of_line_characters'))

In all of the examples shared above returns a valid data. So, What happens if an incorrect path is passed? No data is received and query is completed with SQL Code '100'. 


If you have any Suggestions or Feedback, Please leave a comment below or use Contact Form.
Labels:

Comments

Post a Comment

Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel
4 comments
Read more

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke
Post a Comment
Read more

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i
2 comments
Read more