SQL & PL/SQL

According to Morgan's library, this function is undocumented. (Which begs the question - are you using this in a critical production environment, and if so, why?)
https://www.morganslibrary.org/reference/pkgs/dbms_scheduler.html#sched15
In any case - it appears that rprJob is a package (either user-defined or perhaps another Oracle-provided but undocumented) which, among other things, defines the various constants used in your calls. It seems pretty clear that in one environment (the older one) the constants are in fact defined (15, 30 12) while in the other environment they are not. In other words: don't look at the function; look at the values passed to it. Where they come from, and how they are different in the two databases.

@mathguy Thanks for the quick response. I was using this function in oracle 11g now I'm trying to upgrade my version to 18c which made me run into this issue. Also, I've looked at the values that are passed to the function in both versions and they are the same. In Oracle 18c I tried checking their values before and after the function is called and at both the time, the value is as expected(15,30,12). So I don't think there is a value change in the values passed to the function.

Hi,
As mathguy said, this function is undocumented, so there can be changes from one version to another without notice. It isn't recommended to use undocumented features especially for this reason. Building the repeat_interval string isn't that complicated, so you can very well do it on your own.

When troubleshooting, the first task is to localize the issue. If you do want to continue to investigate (at the very least, out of curiosity) - the next thing you might try is to pass hard-coded numeric literals (such as 12, 15 etc.) Does the function, then, work as expected?
If it doesn't, you will know something changed about the function itself, and the problem has nothing to do with the package constants. Conversely, if in that case the function works as expected, you will know that the issue has to do with how the values are passed, and not the function itself. Either way you will have a smaller problem to tackle.

@gregv @mathguy Thanks for your responses. I did try and hard code and pass the values to the function in sqldeveloper still getting a result that is different from the older version. So I've decided to create a string my own or modify the string returned accordingly.