Re: Embedded SQL with fully free form code?

On 18-Jul-2016 11:31 -0500, David Gibbs wrote:

OK, maybe I'm missing something obvious ... but I can't tell this
routine won't compile ...

----------
dcl-proc getTypeId;

dcl-pi *n like(im_AttributeTypeID);
pTypeName like(im_AttributeTypeName) const;
end-pi;

dcl-s typeId like(im_AttributeTypeID);

exec sql
select ATID
into :typeId
from IMUATP
where UCASE(ATNAME) = UCASE(:pTypeName);

if sqlCode <> *zero;
typeId = *blank;
endif;

return typeId;
end-proc;
----------

I'm getting a SQL0312 complaining that TYPEID and PTYPENAME aren't
defined or not usable.

The procedure compiles fine if TYPEID or PTYPENAME are either defined
as char's or like fields in files.

Both im_AttributeTypeID & im_AttributeTypeName are defined in a copy
book as 'template' character fields.

This is on 7.1 TR11

I seem to recall having had some difficulties with use of TEMPLATE, for what is referenced by the SQL pre-compiler as a host variable; when I first got access to v7r1. Those were easily resolved, however, by converting the TEMPLATE to the older method of achieving effectively the same; i.e. by making the declarative use BASED instead.

Determining if the issue is solely per use of fully-free-form, I suppose could be tested by changing the TEMPLATE declarative to use actual D-specs.? FWiW, a particular source I just found, one that I figured might have been SQLRPGLE source that I had some troubles with, and thus for I had made the change to use a BASED(null@) specification, compiles fine presently on [the more up-to-date] v7r1, after changing the line of source to use the previously commented-out version with TEMPLATE coded as a keyword in the D-spec. I could reformat mine as fully freeform to effect that same test, but doing that likely would be quite a bit slower.