Safe to pointer overlay a varchar onto a clob?

[JonBoy]

Right - it was 64K not 32K.

The pre-compiler has been changed in the past and the change could be easily done compatibly - all they need to do is add the varchar to the DS as an overlay.

[Scott Klement]

Originally it would have had to do it this way since RPG varchar was (until V6) limited to 32K

Actually, the RPG limit was 64k.

And, the approach with a data structure was also limited to 64k since RPG's CHAR as a subfield in the DS was limited to 64k. So the 64k limit was not the reason it used a data structure.

The original implementation was actually before RPG had a varchar or varying string -- that is why it is a DS with a LEN and DATA subfield. They couldn't change it thereafter because programs were now referring to the _LEN and _DATA subfields. (Though, they probably could've had some sort of keyword to indicate the use of VARCHAR/VARYING, etc, I guess...)

It certainly would be more elegant to work with a varchar/varying field than the DS, though.

[Vectorspace]

I imagine they can't change the precompiler now because existing programs will be referencing data structure myCLOB, and subfields myCLOB_LEN and myCLOB_DATA?

Unless they add a control spec keyword to tell the precompiler to make it a varchar instead?

Or how about a new SQLTYPE that still means Clob, but generates a varchar rather than a DS? (presumeably a Blob/VarGraph version too?)

Or maybe simply allow large varchars to directly interact with SQL, by the precompiler recognising they are varchars larger than 32kb so treat them the same as a clob data structure?
I can see from the *LISTING code that when you reference a clob host variable in embedded SQL, it works by pointer using %addr. As clobs always have 4 byte lengths whereas varchars have 2 bytes or 4, the precompiler would need to be smart enough to recognise if the varchar has a 2 or 4 byte prefix and adjust accordingly.

[JonBoy]

The answer to your question is yes - it should be perfectly safe. Actually I'm surprised that the SQL pre-compiler hasn't been updated to generate a VarChar rather than the old approach. Originally it would have had to do it this way since RPG varchar was (until V6) limited to 32K but now that the limit no longer exists it really should change. I'm meeting the IBMers responsible for the pre-compiler in a week or two and will try to remember to ask them about this. Of course you could always write an RFE requesting the change <grin>.

[Vectorspace]

We have cases where huge varchars are passed in to programs as parameters.

[B.Hauser]

Why to use pointers? Just modify your data with SQL if you are working with SQLTYPE datatypes.

Is it save modifying the original data directly (or data structure) directly or through a pointer data within pure RPG?

Birgitta

[Vectorspace]

This:

Dcl-S myClob SqlType(CLOB:3000);

is converted by the SQL precompiler to this:

Dcl-Ds myClob;
  myClob_LEN  UNS(10);
  myClob_DATA CHAR(3000);
End-Ds;

I had a realisation. UNS(10) is a 4 byte unsigned integer. A varchar has a 2 or 4 byte prefix to store the numeric number of characters, just like the myClob_LEN component of SqlType(CLOB).
Which means, the memory layout for these two definitions:

Dcl-S myClob SqlType(CLOB:3000);
Dcl-S myVar  Varchar(3000:4);

should be the same - 4 byte unsigned integer for number of characters, followed by 3000 bytes of characters.

Which means, it should be safe to use pointers to overlay the two variables on top of each other? We have programs that use varchars larger than the maximum 32kb supported by SQL, and being able to directly overlay a larger varchar with a CLOB would make them simpler to deal with if we ever needed to process that variable in SQL. Example:

Dcl-S myDataC  SqlType(CLOB:3000000);
Dcl-S myDataV  Varchar(3000000:4) based(@myDataV);
Dcl-S @myDataV Pointer inz(%addr(myDataC));

myDataV = 'some long data';
exec sql set :myDataC = upper(:myDataC);
// myDataV now equals 'SOME LONG DATA'

So RPG code can use myDataV and SQL can use myDataC, and both are manipulating the same data.

Is this safe? Or are there reasons to not do this?