I wanted to define this UDF as all SQL to make it easier to use with external platforms like SSRS. Is there a hard limit of one SQL UDF per source member?  See attached.  When I did the single, it worked and CREATE passed.  When I tried various ways to code more than one UDF in the same source member, it failed every time.  I await the wisdom from my companions on the journey. 



------------------------------
David Taylor
Senior Developer
Range Resources Corporation
Fort Worth TX US
------------------------------

Hi David,

Thank you for your enquiry.

By definition, LMi manages objects with or without source.
In most cases, each object may be managed with its source as a pair. (One source generates one object)

SQL objects are non-source based and may be managed with their specific pseudo source.
In your example, you have two distinct objects.
FUNCTION DATE_TO_USA_NUM
FUNCTION DATE_TO_ISO_NUM

Hence I would expect two distinct functions (*FUNCTN) to be defined and managed in LMi. Each function may have its distinct pseudo source or as no-source.

Of course, you could manage an object of type *SRCMBR which could contain a number of SQL objects. However, this source member cannot be linked to a specific LMi object since one object is paired with its own source. The *SRCMBR may be executed outside of LMi to generate multiple objects where each object could be managed in LMi as non-source object. This approach is not recommended since *SRCMBR would have to be checked out / edited for each object being changed possibly by different developers.

Please let us know if you have further questions on this topic.
Best regards

------------------------------
Jay Mikaiel
Senior Technical Support Engineer
Rocket Software
UK
------------------------------

---

Hi David,

Thank you for your enquiry.

By definition, LMi manages objects with or without source.
In most cases, each object may be managed with its source as a pair. (One source generates one object)

SQL objects are non-source based and may be managed with their specific pseudo source.
In your example, you have two distinct objects.
FUNCTION DATE_TO_USA_NUM
FUNCTION DATE_TO_ISO_NUM

Hence I would expect two distinct functions (*FUNCTN) to be defined and managed in LMi. Each function may have its distinct pseudo source or as no-source.

Of course, you could manage an object of type *SRCMBR which could contain a number of SQL objects. However, this source member cannot be linked to a specific LMi object since one object is paired with its own source. The *SRCMBR may be executed outside of LMi to generate multiple objects where each object could be managed in LMi as non-source object. This approach is not recommended since *SRCMBR would have to be checked out / edited for each object being changed possibly by different developers.

Please let us know if you have further questions on this topic.
Best regards

------------------------------
Jay Mikaiel
Senior Technical Support Engineer
Rocket Software
UK
------------------------------

Jay, thank you for the quick response.  You confirmed what I found from trial and error.  This does make sense within the Aldon framework.

------------------------------
David Taylor
Senior Developer
Range Resources Corporation
Fort Worth TX US
------------------------------

---