u/Iguanas_Everywhere

The IBM docs say that "In an ANSI-compliant database, Select cursors are update cursors by default. An update cursor is a cursor that can be used to modify data."

This really surprises me. Why would a SELECT cursor be an update cursor by default? I do note that earlier in the same doc, it mentions that FOR READ ONLY is usually unnecessary for SELECT statements, since they are a read-only operation. But the sentence above confounds me.

I had heard they used to be a wonderful resource and community, but it no longer seems possible to register there (no verification emails ever come through). I reached out on their feedback form but am doubtful I'll hear a response. Just curious if that resource has gone the way of the dodo.

In my mind, I've always thought of Interactive jobs as being the jobs where a user is actively interacting with the screen, i.e. the program is awaiting their responses and proceeding when values are received. I've associated batch jobs with something where my CL has a SBMJOB command, and things run in the background.

When we bring the idea of an external ERP or a scheduler, I'm curious if my mental model still holds. If I have a program in an ERP where, say, a user enters a few params and then clicks a button to call my CL and execute the program, is that still interactive? I'm not 100% sure what goes on under the hood, but seeing as my CL just gets executed directly, there's no SBMJOB command in it, and the user has to wait a few secs (i.e. unable to do something else while it's processing), it feels like this would still be interactive.

Similarly, if a job scheduler calls my CL every day at a certain time, is that still "interactive" with the "user" being the scheduler itself? I'm not sure it's accurate for me to reduce the distinction of batch/interactive to the existence of a SBMJOB command in my CL program, haha! But just reading the definitions of these jobs isn't getting my head fully there on what happens in practice with these kinds of situations. Many thanks for any helpful thoughts!

I had always assumed that Century indicators in CYMD dates were as simple as "0 = 1900s and 1 = 2000s." However, I just learned that a QCENTURY value of 0 indicates 1928-1999, and 1 indicates 2000-2063. I'm sure there's a fascinating explanation for this, but I can't find what it is. Anyone have some insights to share to satiate my curiosity? Is there a storage issue at play, a la Y2K issues, but obviously different somehow?

I'm converting a decimal value to a VARCHAR on a DB2 system. I'm finding one syntactical version works, and another doesn't. I'm coming up short when trying to explain to myself why.

SELECT VARCHAR(My_Field)
FROM My_Table

works!

SELECT CAST(My_Field AS VARCHAR)
FROM My_Table

doesn't work--"Attributes not valid" error.

Weirdly:

SELECT CAST(My_Field AS CHAR)
FROM My_Table

works.

What am I not understanding? Many thanks!

I've realized that if I look at a dump from a CL program by using a DMPCLPGM command in the code, the variables that are declared and initialized (given a VALUE when declared) won't show up in the dump. If I "do something" with the variable, whether a CHGVAR or pass it as a PARM to another program, then they do show up in the dump properly. Strangely, this seems to be the case regardless of where the DMPCLPGM command is in my code (i.e. before or after the "do something with the variable" command).

I'm guessing there's an order of operations happening under the hood, like a variable doesn't really occupy memory until it's used in a command, and that DMPCLPGM runs after a program ends or something. But I haven't been able to track down any documentation to satisfy my curiosity on the subject. Can anyone shed some light? Many thanks!