'Mismatched number of parameters passed to procedure /optmp/p76465r.ped. (3234) '

[Kremena Hagen]

Hi All,

I get the error:
'Mismatched number of parameters passed to procedure /optmp/p76465r.ped. (3234) '

For the following code:

/*date.p */
define input parameter dt as date initial "02/11/22".
define output parameter dt1 as character.

run dtconv.p ( input dt, output dt1).

display dt.


/*dtconv.p*/
define input parameter dt as date.
define output parameter dt1 as character.

define variable dt-yr as character.
define variable dt-mo as character.
define variable dt-day as character.
define variable n as integer.

dt-yr = string (year (dt)).

dt-mo = string (month (dt)).
n = integer(dt-mo).
if n < 10 then
dt-mo = "0" + string (month(dt)).

dt-day = string (day (dt)).
n = integer(dt-day).
if n < 10 then
dt-day = "0" + string (month(today)).

dt1 = dt-yr + dt-mo + dt-day.


What do I do wrong? I am very new to Progress, and probably this is a very simple question for most of you.

Thank you in advance.

Kremena

 

[warba]

Change date.p to read:

/*date.p */
define var dt as date initial "02/11/22".
define var dt1 as character.

run dtconv.p ( input dt, output dt1).

display dt.


In the calling program, dt and dt1 are not input or output parameters, they are only variables.

It is in the called program that accepts parameters where you define the variables using "input/output" parameter.

 

[Kremena Hagen]

Thank you Warren.

I have another question. When I first run my program I was getting the date in the format I wanted it (20021203). I haven't made any changes to the program since that moment, but when I run it now I get "dt-day" string without the zero infront (2002123). Is this have to do something with my system since I haven't made any changes to the program?

Thank you,

Kremana

/*dtconv.p*/
define input parameter dt as date.
define output parameter dt1 as character.

define variable dt-yr as character.
define variable dt-mo as character.
define variable dt-day as character.
define variable n as integer.

dt-yr = string (year (dt)).

dt-mo = string (month (dt)).
n = integer(dt-mo).
if n < 10 then
dt-mo = "0" + string (month(dt)).

dt-day = string (day (dt)).
n = integer(dt-day).
if n < 10 then
dt-day = "0" + string (day (today)).

dt1 = dt-yr + dt-mo + dt-day.

 

[warba]

I think if you want to convert a date format variable into a character variable in the format YYYYMMDD, you may use this syntax:

dt1 = string(year(dt),"9999")
+ string(month(dt),"99")
+ string(day(dt),"99").

The format mask of "99" will always pad zeros so "3" will be "03".

Warren.

 

[Kremena Hagen]

You are right because the month comes out right but the day still doesn't have the zero infront. I am getting 2002099 for the code below. It has to be something with the system.


define variable dt2 as character.
run dtconv.p ( input 09/09/02, output dt2).
display dt2.

/*dtconv.p*/
define input parameter dt as date.
define output parameter dt1 as character.

define variable dt-yr as character.
define variable dt-mo as character.
define variable dt-day as character.
define variable n as integer.

dt-yr = string (year (dt)).

dt-mo = string (month (dt)).

dt-day = string (day (dt)).

dt1 = string(year(dt),"9999") + string(month(dt),"99") + string(day(dt),"999").

 

[warba]

That is odd.

If you change your "display" statement to read:

message dt2 view-as alert-box.

Do you then see 200209009 ?

 

[Kremena Hagen]

Same thing no zero.

|-------Message -------+|
2002099

Do you get the zero?

 

[warba]

Yes, I get 200209009.

If you simply execute the following:

message string(day(today),"99") view-as alert-box.

Do you get 05 ?

If you try:

message string(day(today),"999") view-as alert-box.

Do you get 005 ?

 

[Kremena Hagen]

This is so odd.

I do get.

05

and

005

 

[warba]

Then we have proven that your system does return the correct data for the string formatting.

I would maybe suggest that when you "run" dtconv.p you are maybe running a different version than you think ?

Maybe you could prove you are running the correct version by modifying dtconv.p so the last line reads:

dt1 = "A" + string(year(dt),"9999") + string(month(dt),"99") + string(day(dt),"99").

When you run your program, if it is running this version, you should get "A20020909".

If you just get "2002099" then it is running another version of the program from elsewhere.

You could further test this by creating one program that has an internal procedure, but with the same code.
If you just cut and paste the following into a progress editor and run it, you should get the correct result:

define variable dt2 as character.
run dtconv (input 09/09/02, output dt2).
message dt2 view-as alert-box.

procedure dtconv:
define input parameter dt as date.
define output parameter dt1 as character.

define variable dt-yr as character.
define variable dt-mo as character.
define variable dt-day as character.
define variable n as integer.

dt-yr = string (year (dt)).
dt-mo = string (month (dt)).
dt-day = string (day (dt)).
dt1 = string(year(dt),"9999") + string(month(dt),"99") + string(day(dt),"999").

end procedure.

 

[Kremena Hagen]

Thank you so much. I guess my file was corrupted or something. Thank you.

Kremena

 

[Kremena Hagen]

Warren,

Is it very common to be running a different program version than what you think? I am referring to the problem I had with the dates. I notice that some of my programs do this and it's really hard to fix a corrupt file like that. What should I do to avoid this problem?


Thank you,
Kremena

 

[tdi]

I had the same problem, once....

What i do to avoid same situation where in develoment the compiler missed to generate new .r, and i ended runing some old version of the program, and noticing no change on the output from "new" code, just compiled, was:
i made a batch file to erase all the .r files in my development directory, and voila, you see inmediately the changes.

 

[Kremena Hagen]

I deleted the .r files in my home directory. Is it possible that I have .r files somewhere else?

Kremena

 

[warba]

There are maybe 2 issues.

1. When running programs, your PROPATH and home directory are going to be searched, and the first found program matching your program name will be run. It is important to control where you put software (.p) and compiled programs (.r); also control your PROPATH settings.

2. Another issue may be with Progress quick request startup parameter. If this is ON then only the first request of a program will search the PROPATH; this is documented in the Progress Startup Command and Parameter Reference guide. Here is the excerpt:

Quick Request (-q)
-
Use Quick Request (-q) to tell Progress to search PROPATH directories only on the first use of a procedure.

Ordinarily in a Progress procedure, when the RUN statement is used to run a subprocedure, Progress searches the directories named by the PROPATH environment variable, looking for a procedure of the same name with a .r extension. If it finds a file with a .r extension (an r-code file), it checks to make sure the r-code file has not changed since that r-code file was created.
This search is very useful in a development environment where procedures change regularly and you want to make sure you are always running the most current version of your application. However, in a production environment, you might want to bypass this search.

With Quick Request (-q), after the initial search, if the procedure still resides in memory or in the local session-compiled file, Progress uses that version of the procedure rather than searching the directories again. However, Progress always checks whether Data Dictionary definitions related to a procedure were modified. If they were modified, Progress displays an error when it tries to retrieve the procedure.