On 24 Jun 2013 02:01, Gad Miron wrote:

I think I'll wait with the DCR ... (-:

Just set the column to the DEFAULT on the UPDATE, if you want the column updated to the default value which was defined as the USER special register. I am unsure of what is the concern noted by Rob, because the User Special Register is AFaIK the /current user/ of the job, which is generally the desirable value from the perspective of the typical application. And if another special register is desirable to effect for an UPDATE [e.g. CLIENT USERID or SYSTEM_USER], then an application can set the column directly to that special register or to a variable name that was previously set to the value of that special register.

How about "With default User" ?
It does not work in my tests.

<sarcasm> Wow! Having so explicitly described the difficulty that was encountered, receipt of valuable assistance from numerous replies should be expected to provide a quick resolution to whatever is the problem. </sarcasm>

Should we presume that the column definition on the CREATE TABLE was incompatible with the chosen Special Register as DEFAULT? That perhaps the default-clause specifying USER was had been declared as less than CHAR(18) [or VARCHAR(18) or some other compatible\cast-able] data type, for which SQL0574 "DEFAULT, identity, or sequence attribute is not valid." was the error, for which the CREATE TABLE "does not work"? And that message presumably had further clarified that "If the DEFAULT value is defined as the value of the USER special register, the column must be defined as a CHAR or VARCHAR and the length attribute must be greater than or equal to 18."? If not, then perhaps "does not work" can be clarified with a script and the errors effected.?

Rob on Fri, 21 Jun 2013 07:58:38 -0400 wrote:

There is not a row change user capability at this time. Upon
initial thought one would think this would be easy and you should
submit a DCR and/or a COMMON requirement to get IBM on this. You
still may want to. But consider this; what about all those jobs
that run under one profile but service another? <<SNIP>>

Of course an UPDATE [and optionally also an INSERT] TRIGGER could do for any column that should always be assigned the value of the current USER, effectively the same thing that the database does for a ROW CHANGE TIMESTAMP. That is, irrespective of what is requested to be inserted or updated for that column, the TRIGGER(s) can override\set the more desirable value. And of course, the minimal declaration of 18 characters for DEFAULT USER is also easily removed as a requirement.

This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page