On 12-May-2016 12:46 -0500, Roger Harman wrote:
I always keep a shortcut for these....
[http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzakz/rzakzsysvaltable.htm]
FWiW:
QDAY is documented there as a CHAR(3), but with DCL (&DAY) *CHAR
LEN(3) as declarative and then requesting RTVSYSVAL QDAY &DAY, that
would be expected to fail for most installations with msg CPF1095 "CL
variable length not valid for system value QDAY." F/QWCSRTLR, because
CHAR(2) is required. Not very handy docs, if\when they are incorrect or
incomplete :-( The same issue for QDATE, showing CHAR(6) in the docs,
but most installations will require declaring CHAR(5) for the retrieve
to function without that error stating "CL variable length not valid for
system value QDATE." Neither of those caveats, nor another for QMONTH
are listed in the docs, not even in the Notes; they are are at least
alluded-to in the help text.
In the _help text_ for RTVSYSVAL, the type specifications listed near
the bottom have always been [somewhat] accurate; though somewhat
deceptive as well. I am unsure why the Retrieve System Value
(RTVSYSVAL) has always been so lame as to have different definitional
requirements based on the Date Format (QDATFMT) system-value instead of
dependent on the Date Format (DATFMT) of the job :-( Easy enough to
issue a Change Job (CHGJOB) to set the desired format, but not so easy
or perhaps more appropriately stated as being /especially unwise/, for a
CLP to reset the system Date Format using the Change System Value
(CHGSYSVAL) to enable the request to obtain the desired value. Again,
similarly for QDATE. And then for QMONTH, there is the silly
restriction diagnosed by msg CPF1074 "SYSVAL(QMONTH) not valid for
Julian date format."; these restrictions\mandates never made any sense
to me, because the answers to the inquiries are known and thus could be
returned, as well the likely intent of the setter\changer should be
understood, irrespective the QDATFMT -- the date is a\the _date_, no
matter the formatting chosen for the date.
The following CLP should /fail/ on every system, exhibiting how the
choice of the 2-byte vs 3-byte can not be accomplished as a reflection
of the Date Format job setting\attribute; instead, must rely on the QDATFMT:
<code>
dcl (&xk ) *char 4
dcl (&day3) *char 3
dcl (&day2) *char 2
dcl (&dtfS) *char 3
dcl (&dtfJ) *char 4
monmsg cpf1095 exec(goto reset)
rtvjoba datfmt(&dtfJ)
rtvsysval qdatfmt &dtfs
if (&dtfS *ne 'JUL') then(do)
rtvsysval qday &day2
chgjob datfmt(*jul) /* expect 3-digits! but*/
rtvsysval qday &day3 /* why does this fail? */
enddo
else /* the system date format is JUL */ do
rtvsysval qday &day3
chgjob datfmt(*mdy) /* anything but *JUL */
rtvsysval qday &day2 /* why does this fail? */
enddo
reset:
rcvmsg pgmq(*same) msgq(*pgmq) msgtype(*excp) rmv(*no) +
keyvar(&xk)
chgjob datfmt(&dtfJ)
dmpclpgm
dspsplf qppgmdmp
monmsg cpf0000
if (&xk *ne ' ') then(call qmhrsnem (&xk x'0000000000000000'))
</code>
As alluded, similarly with QDATE, and QMONTH another related difficulty.
midrange.com
