Re: SQL Sequences again ... a bit lower level though

By review of the dumps of an original and altered sequence, the original START value is maintained. This is done apparently, to enable support for ALTER SEQUENCE RESTART without any restart value being specified; i.e. the value for START is reset to its original value even after an intermediate ALTER SEQUENCE RESTART WITH value was performed where value<>original.

The UDF QSYS2/SEQUENCE [implemented by *srvpgm ??] which manifests the START value in the catalog VIEW QSYS2/SYSSEQ as a DECIMAL(63,0) starting at the position 552, is apparently returning the original START value irrespective of any RESTART WITH value. Just a SWAG, but I would think the implementation for the SEQUENCE function should be performing some extra logic to determine which data to return in the string at position 552, instead of consistently returning only the original START value from the data in the data area. Much less likely, improbable even, that the catalog VIEW should manifest a RESTART column to return the RESTART value.

Probably best to open a PMR with, and ask of IBM what should be returned in SELECT START FROM SYSSEQ, valueX or valueY, after a simple script of:

CREATE SEQUENCE START WITH valueX
;
ALTER SEQUENCE RESTART WITH valueY.
;

Regards, Chuck

David Gibbs wrote:

I've run into another curiosity regarding SQL sequences that I
can't understand.

If I run an alter sequence statement and restart the sequence at
a new value, the system table QSYS2/SYSSEQUENCES doesn't reflect
the new start value.

If I retrieve a new value from the sequence however, I get the
correct results based on the new start value.

I'm not using commitment control.