RE: GLOBAL TEMPORARY TABLE issues

Rob,
        We create a model file that is used for compile purposes, use
the DECLARE GLOBAL TEMPORARY TABLE (embedded SQL) to create the object
in QTEMP (it's a work file), dump data into it for further processing in
one job stream (possibly in more that one program but just one program
at this time).  

        To get around the record format name issue we named the model
file format the same as the file (just like SQL does), then rename it on
the F-SPEC. The code examples I sent with the first message shows the
bare minimum I used for testing to find a solution around this issue.

        The solution we need must be compatible with our CMS product
from Aldon.  So, during promotion time the model file object must exist
because all promotions to the next environment must be done in batch.
We do not want to build special exit program processing just for this
one instance.  We could create the model file using SQL and add it to
Aldon as a non-source based object, but as I said before our current
standard is to use DDS only for files.  

        If you play around with the same code I provided compile all
with the date in the model file and run the program, it halts.  Comment
out the date field, compile and run it runs just fine.  If you just use
the date field, compile and run it, the program halts again.  It's the
date that is causing the difference in the DDS model file and the SQL
temporary table and I am wondering why.  Knowing this helps me tell
others the reason and why they might want to go another direction. 

Thanks, Matt