× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Back to a possible solution - and I know there will be issues with this - I'd offered the idea of using pointers to the values to be compared - here is some code for a min() procedure and tests that include 2 packed values and 2 character values.

The result is meaningless if data types don't match (other than zoned and character, maybe), since it is a hexadecimal comparison. Basically, all data types should be the same.

ctl-opt dftactgrp(*no) actgrp(*caller);

dcl-s ptr pointer;

dcl-s minPacked packed(5 : 0) based(ptr);
dcl-s Packed1 packed(5 : 0);
dcl-s Packed2 packed(5 : 0);
dcl-s minChar char(15) based(ptr);
dcl-s Char1 char(15);
dcl-s Char2 char(15);


Packed1 = 4;
Packed2 = 7;
ptr = min(%addr(Packed1) : %addr(Packed2));

Packed1 = 4;
Packed2 = -2;
ptr = min(%addr(Packed1) : %addr(Packed2));

Char1 = 'this is some text';
Char2 = 'now you see me';
ptr = min(%addr(Char1) : %addr(Char2));

*inlr = *on;

// --------------------------------------------------
// Procedure name: min
// Purpose: Determine minimum of 2 values
// Returns: Minimum value (pointer)
// Parameter: pValue1 => Value 1 (pointer)
// Parameter: pValue2 => Value 2 (pointer)
// --------------------------------------------------
DCL-PROC min ;
DCL-PI *N POINTER;
pValue1 POINTER CONST;
pValue2 POINTER CONST;
END-PI ;
// Your local fields go here
dcl-s value1 char(256) based(pValue1) ccsid(65535);
dcl-s value2 char(256) based(pValue2) ccsid(65535);

DCL-S retField POINTER;

// Your calculation code goes here
if value1 <= value2;
retField = pValue1;

else;
retField = pValue2;
ENDIF;

return retField ;
END-PROC ;

Have all the fun you want - and no SQL needed.

Cheers
Vern

On 8/22/2016 1:40 PM, Jon Paris wrote:
I seemed to recall that there was a manual reference some place that noted that certain functions (and I thought embedded SQL was one of them) could only use what I believe IBM calls "simple qualified names” i.e. Just DSname.fieldName. I have searched the Reference and Programmer’s guides but could not find the reference.

However - buried in the Embedded SQL manual for V7 I find this which seems to cover the situation:

"The precompiler will recognize a host structure defined using the LIKEDS keyword. However, the SQL syntax for a host variable only allows using a single level of qualification in an SQL statement. This
means that if a data structure DS has a subfield S1 which is defined like a data structure with a subfield S2, an SQL statement cannot refer to S2 using the fully qualified host variable name of DS.S1.S2. If you use S1.S2 as the host variable reference, the precompiler will recognize it as DS.S1.S2."

Note the "single level of qualification”. It appears that you can use a third level - but ONLY if the top level DS is not qualified.

It really should be better documented and the restriction removed. It should not be rocket science to fix this.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Aug 22, 2016, at 1:16 PM, dlclark@xxxxxxxxxxxxxxxx wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 08/22/2016 12:15:17
PM:
So this problem isn't/wasn't restricted to SQL.
I didn't get any errors resolving multiqualified variables in
either the editor or in an RPG/LE program without SQL. In fact, I have no
problem using those variables in RPG statements -- even if SQL is used in
the program. I only get these errors when I am trying to use those
variables in an embedded SQL statement.

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331




*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.