options(*CONVERT) in RPGfree '

By -

*CONVERT option in RPG



The *CONVERT option in RPG is specified to tell the compiler to automatically convert a value passed as a parameter to the correct type if it differs from the type defined in the procedure.

 

How OPTIONS(*CONVERT) Works

OPTIONS(*CONVERT) allows for automatic data conversion between compatible types when a procedure or function is called with a parameter of a different type than expected. For example, if a procedure is defined with a numeric parameter and a different type, such as a decimal, is passed to it, the compiler will automatically handle the conversion so that the value matches the declared type.


For example:

**free
//      *******************************************************
//      * convert to char                                     *
//      *******************************************************
ctl-opt main(main) dftactgrp(*no);
 
//      *******************************************************
//      * PGM start                                           *
//      *******************************************************
dcl-proc main;
  dcl-s UTF8uni char(25) ccsid(*utf8) inz('IBM i (AS400) fans only');
  dcl-s vFloat Float(8)  inz(123) ;
  dsply (cvtToChar(UTF8uni))      ;
  dsply (cvtToChar(vFloat))       ;
  dsply (cvtToChar(%timestamp())) ;
  dsply (cvtToChar(%date()))      ;
  dsply (cvtToChar(1.2345678901)) ;
end-proc;
 
dcl-proc cvtToChar;
  dcl-pi *n varchar(40);
    ConvertedtoChar varchar(40) const options(*convert);
  end-pi;
  return ConvertedtoChar;
end-proc;


Here’s a breakdown of how each call works:

  1. String with UTF-8 (UTF8uni): cvtToChar receives a UTF-8 character string and uses OPTIONS(*CONVERT) to ensure it's interpreted as VARCHAR(40). Since it’s already a character type, minimal conversion is required.
  2. Float Value (vFloat): OPTIONS(*CONVERT) converts vFloat, a floating-point number, into a character string.
  3. Timestamp and Date (%timestamp() and %date()): Both are non-character types, but OPTIONS(*CONVERT) allows them to be passed as parameters, and the compiler automatically converts them to a string representation.
  4. Constant Decimal (1.2345678901): This decimal constant is automatically converted to a VARCHAR type, demonstrating compatibility with numeric literals.


When to Use It

Using OPTIONS(*CONVERT) is useful when you want to maintain flexibility in parameter data types, avoiding type errors when passing values of a compatible but different type. This is particularly valuable when integrating procedures with predefined data types or working on projects where parameter types may vary. 


Some tips to use it effectively?

What do you think? Have you used OPTION(*CONVERT) in your RPG projects?




Comments

  1. AnonymousNovember 18, 2024 at 11:09 AM

    Triggers for log-programs. We can now drop MOVEL and use this instead.

    ReplyDelete
    Replies
    1. Aldo SUCCIDecember 17, 2024 at 1:48 PM

      Thank you for your comment! You’re absolutely right: using OPTIONS(*CONVERT) is a huge step forward compared to the old MOVEL, especially in modern IBM i programming.
      Not only does it simplify the code by eliminating the need for explicit conversion operations, but it also makes programs more robust, minimizing errors related to spacing or data truncation.

      In the context of triggers for log programs, as you highlighted, this feature can significantly improve data management and integration. I’m considering diving deeper into this topic in a future article, perhaps with some practical examples on how to implement these triggers using OPTIONS(*CONVERT).

      Thanks again for your input! If you have further suggestions or examples, feel free to share them!

      Delete

Post a Comment

Popular posts from this blog

(IBM i fans only) Efficient WRKSPLF with WSF - How to Search string into spooled files, Sort, and Generate PDFs on IBMi

By -
Image
Searching Spooled Files Made Easy: A Unique Solution Managing spooled files efficiently is crucial for users dealing with numerous rows of print data. IBM's WRKSPLF command provides a standard way to interact with spooled files, but it lacks certain features that can significantly enhance user experience. In this article, we'll delve into a powerful functionality that IBM doesn't offer — the ability to search among spooled file lists. Our goal is to highlight the advantages of this capability and introduce a practical solution. The Limitations of Standard WRKSPLF While the WRKSPLF command is a handy tool for working with spooled files, it falls short in certain aspects. One prominent limitation is the inability to search efficiently through the list of spooled file rows. Users often find it challenging to quickly locate specific files based on criteria like creation date, status, or content. Introducing a Unique Solution: WSF (WorkSpooledFiles) To address the limitations of...
Read more

(IBM i fans only) Detecting and Handling Non-Printable Characters in DB2 SQL Using LOCATE() and REPLACE() Functions

By -
Image
When working with DB2 SQL on the IBMi platform, one of the challenges we might encounter is dealing with non-printable characters in our data. These are characters that don't have a direct representation on a standard keyboard and can cause display programs to crash if not handled properly. For this example, we'll be working with the CLANA00F file, which contains customer data. You can find details on how to create this file on my blog post here . Non-printable characters can sneak into our records for various reasons, and to prevent issues, we can run an SQL query that uses the LOCATE() function. This function returns the position of the first occurrence of a substring within a string, allowing us to detect these problematic characters. Suppose we have a customer name with a non-printable character, specifically the EBCDIC '0D' character, which corresponds to the "Carriage Return" (CR) control character in ASCII. To find this character in our records, we can ...
Read more

(IBM i fans only) How to Sniff User Access

By -
Image
If you need to monitor user access on your IBM i system, you can use SQL to query the history log. Note: At the end of this post, you'll find a request directly addressed to you, the readers. Here’s a simple example of how you can do this: SELECT MESSAGE_ID,        MESSAGE_TIMESTAMP,        FROM_USER,        MESSAGE_TEXT     FROM TABLE (             QSYS2.HISTORY_LOG_INFO()         )     WHERE message_id IN ('CPF1164', 'CPF1124')           AND FROM_USER IN ('QSECOFR', 'QSYS', 'QSYSOPR')     ORDER BY MESSAGE_TIMESTAMP In this query: - QSYS2.HISTORY_LOG_INFO(): This function retrieves information from the history log. -  message_id IN ('CPF1164', 'CPF1124') : Filters the results to include only specific message IDs, which indicate sign-on and sign-off events. - FROM_USER in ('QSECOFR', 'QSYS', 'QSYSOPR'): Filters the resu...
Read more