Temporary job file.

[TedHolt]

Re: Temporary job file.

for it to work you need to have QTEMP towards the top of your library list - or at least above your data libraries *OR* an OVRDBF executed prior to opening it.

Every shop I've worked in included QTEMP in the library list, some at the top, others at the bottom. A good case could be made for never putting QTEMP in the library list, forcing every program to qualify the objects in QTEMP.

[Rocky]

Re: Temporary job file.

In my narrow minded view, I think it should be in the library list at the top. Otherwise you run the risk of putting data not in the temporary file as intended - but in the template file which isn't intended. Two jobs run that use the same file and you have problems. But - that's me...

[Scott Klement]

Re: Temporary job file.

I've never needed to use KEYLOC() (and I'm not sure why anyone would want to nowadays), but I had understood that it was only meaningful for program-described files. So, why does it imply a need for DDS/DDL? After a couple seconds of thought, it makes sense that it's needed for the creation, and then, once created, it can be accessed as a program-described file.

Correct, KEYLOC is for program-described files. The OP was asking if he could use CRTPF RCDLEN(xxx), therefore no field definitions in DDS, which implies program-described access. He mentioned KEYLOC in one of his posts -- it wasn't my idea.

But the fact is that CRTPF RCDLEN(xxx) cannot add a key to a file. So you'd need to use DDS/DDL to create a keyed file unless you can use the S/36 BLDFILE procedure (which he says he cannot use.) You could, however, do a minimalist DDS where you just define the key fields and make everything else be one big long character field. (I wouldn't recommend it... just saying it's possible.) Then you could use program-described access to get actual field definitions.... this would give you both the key and the program-described access.

Or you could just make the file externally defined... or eliminate the need for the temp file altogether, as I suggested earlier. Which would certainly be better.

[tomliotta]

Re: Temporary job file.

So you'd need to use DDS/DDL to create a keyed file unless you can use the S/36 BLDFILE procedure (which he says he cannot use.)

That should be only "mostly" or "practically" true. That is, for example, the file could be created without direct use of DDS/DDL by going into IDDU; but I can accept the principle. I don't know what IDDU does behind the scene. Also, IDDU wouldn't be as handy for the apparently needed process of dynamic creation in QTEMP by a "batch" kind function, i.e., one that wouldn't ever present IDDU's 'Create Database File' display.

Regardless, for something like this, I would either have a 'model' file description already created in a production library that I could duplicate into QTEMP with CRTDUPOBJ or use a CREATE TABLE statement in the programming. Hard to say which would be better for the OP.

Tom

[Scott Klement]

Re: Temporary job file.

That should be only "mostly" or "practically" true. That is, for example, the file could be created without direct use of DDS/DDL by going into IDDU; but I can accept the principle.

IDDU is something I'm not familiar with. I vaguely remember it being mentioned years ago... but have never seen/used it. Is this something used in many shops?

Like I said, DDS/DDL is only one option, the S/36 BLDFILE command is another. The point is, simply doing CRTPF without source is not "enough" (which is what the OP asked... you might remember not being happy with his use of the term "enough") if a key is needed.

[tomliotta]

Re: Temporary job file.

IDDU is something I'm not familiar with. I vaguely remember it being mentioned years ago... but have never seen/used it. Is this something used in many shops?

I have no idea how widely used it is. I wouldn't think it's got much of a following at all nowadays. (When was the last time we heard a reference?) It works fine for me in i 6.1; use STRIDD to get into it. I haven't used it for anything except trivial tests since perhaps V2R3. It's probably easier for most people to use than creating DDS as long as the needed fields and files don't require some of the more advanced attributes.

As for the OP and KEYLOC(), etc., all of that makes sense.

[TedHolt]

Re: Temporary job file.

IDDU is something I'm not familiar with. I vaguely remember it being mentioned years ago... but have never seen/used it. Is this something used in many shops?

IDDU was a S/36 utility that we used to attach external definitions to data files. We had to do this so we could query the files with Query/36. I've never used it on AS/400 or its descendents. Most of the systems I've worked on did not use the S/36 environment. For those that did, I created DDS-described physical files where possible.

[tomliotta]

Re: Temporary job file.

IDDU was a S/36 utility...

I'm also pretty sure IDDU came from a S/36 background, but it doesn't seem quite part of the S/36 environment. It's apparently fully OS/400 (and later). I've had no S/36 (nor S/38) environment on my systems, and IDDU is completely functional.