Wednesday, January 4, 2023

Procedure parameter option to convert data type

Another addition to RPG within the IBM i 7.5 TR1 and 7.4 TR7 updates was a new option in the OPTIONS parameter when defining the call to a procedure.

Previously if you passed, for example, a date to a procedure the parameter within the procedure's interface would have to be a date too. If the wrong data type was passed it would error.

The addition to the OPTIONS parameter is:

OPTIONS(*CONVERT)

To use this new option the prototype parameter must be defined with CONST or VALUE. It will convert the data type of the variable or value used to character or UCS-2. In the examples below I am going to be using this to convert various data types to character.

I have a program with two subprocedures, each one using a different parameter type:

The code is not ordered in the way it exists, I put the pieces of code for each subprocedure together to make it easier to follow. Let me start with the code for the first procedure: TestProcedure

01  **free
02  ctl-opt dftactgrp(*no) ;

04  dcl-pr TestProcedure ;
05    *n char(30) const options(*convert) ;
06  end-pr ;


10  TestProcedure(%time()) ;
11  TestProcedure(%date()) ;
12  TestProcedure(%timestamp()) ;
13  TestProcedure(100) ;


//-----------------------------------------------
20  dcl-proc TestProcedure ;
21    dcl-pi *n ;
22      inChar char(30) const options(*convert) ;
23    end-pi ;

24   dsply (%concat(': ' : %proc : inChar)) ;
25  end-proc ;

Line 1: This program is in free format RPG.

Line 2: As I am calling procedures, this program will not run in the default activation group.

Lines 4 – 6: Here is the procedure prototype for TestProcedure. It has one parameter, line 5, that I have not given a name to, hence the *N. The parameter has the CONST parameter, as the parameter is a constant it cannot be changed within the called subprocedure. The OPTIONS(*CONVERT) will convert the value passed in the parameter to character.

Line 10: Call the TestProcedure subprocedure passing the current time.

Line 11: Call the subprocedure passing today's date.

Line 12: Call with the current timestamp.

Line 13: Call with a numeric value of 100.

Lines 20 – 25: The subprocedure just a few lines of code to illustrate what the convert option does.

Lines 21 – 23: This is the procedure interface, I never give mine a name so it is *N. On line 22 I do give the procedure's parameter a name, and it is defined like the prototype.

Line 24: Within the DSPLY operation code I am concatenating, using the %CONCAT BiF, the name of the procedure and the value in inChar. The %PROC BiF, returns the name of the procedure.

The DSPLY operation code displays:

DSPLY  TESTPROCEDURE: 21.29.20
DSPLY  TESTPROCEDURE: 2022-12-08
DSPLY  TESTPROCEDURE: 2022-12-08-21.29.21.745098   
DSPLY  TESTPROCEDURE: 100

All of the various data types used when I called this procedure have been converted to character.

The procedure parameters of the second subprocedure, AnotherProcedure, are defined as VALUE, which passes the parameter as a value.

03  dcl-s wkPacked packed(5:2) inz(123.45) ;


07  dcl-pr AnotherProcedure ;
08    *n char(30) value options(*convert) ;
09  end-pr ;


14  AnotherProcedure(t'12.10.23') ;
15  AnotherProcedure(d'2032-12-31') ;
16  AnotherProcedure(z'1905-10-24-09.08.00.000000') ;
17  AnotherProcedure(88.88) ;
18  AnotherProcedure(wkPacked) ;


//---------------------------------------------------
26  dcl-proc AnotherProcedure ;
27    dcl-pi *n ;
28      inChar char(30) value options(*convert) ;
29    end-pi ;

30   dsply (%concat(': ' : %proc : inChar)) ;
31  end-proc ;

Line 3: I am defining this variable to be used when I call AnotherProcedure subprocedure.

Line 7 – 9: Procedure prototype for the subprocedure AnotherProcedure. On line 8 notice that the parameter has the VALUE keyword.

Line 14: Calling the subprocedure, and passing a time to it.

Line 15: Calling and passing a date to the subprocedure.

Line 16: Calling the subprocedure, and passing a timestamp.

Line 17: This time the subprocedure is passed a number.

Line 18: This is where I use the variable defined on line 3.

Lines 26 – 31: The only difference between AnotherProcedure and the earlier subprocedure, TestProcedure, is the presence of the VALUE in the protype interface definition.

The results show that the values passed to subprocedure all were converted to character.

DSPLY  ANOTHERPROCEDURE: 12.10.23
DSPLY  ANOTHERPROCEDURE: 2032-12-31
DSPLY  ANOTHERPROCEDURE: 1905-10-24-09.08.00.000000
DSPLY  ANOTHERPROCEDURE: 88.88
DSPLY  ANOTHERPROCEDURE: 123.45

 

You can learn more about the OPTIONS(*CONVERT) command from the IBM website here.

 

This article was written for IBM i 7.5 TR1 and 7.4 TR7.

1 comment:

  1. Simon, the line "Line 2: As I am calling procedures, this program will not run in the default activation group." is incorrect. The program most certainly can run in the default AG. But the *No option must indeed be used because you are using subprocs.

    God how I hate how we were forced to name that option! Should have been OPMCMP (OPM Compatibility) or something!

    ReplyDelete

To prevent "comment spam" all comments are moderated.
Learn about this website's comments policy here.

Some people have reported that they cannot post a comment using certain computers and browsers. If this is you feel free to use the Contact Form to send me the comment and I will post it for you, please include the title of the post so I know which one to post the comment to.