In general, don't do much with *CURLIB. We create all work files in QTEMP.

The only exception I can think of is when you start FTP, and if the default naming is 0 (lib/file), then the default "directory" is the current library (if no current library, then QGPL).

So if you CHGCURLIB before starting FTP, you don't need a "cd somelib" in the !--script--. If it's not in the !--script--, you don't need separate versions for each environment. Of course you you may want to put it back the way it was:

   DCL        VAR(&CURLIB) TYPE(*CHAR) LEN(10)
   RTVJOBA    CURLIB(&CURLIB)
   CHGCURLIB  CURLIB(somelib)
   FTP ...
   IF         COND(&CURLIB *EQ '*NONE') THEN(CHGCURLIB CURLIB(*CRTDFT))
   ELSE       CMD(CHGCURLIB CURLIB(&CURLIB))

I agree. I think QTEMP is where "work" files should be placed.

Today, they create goofy named files with a 1, 2, 3, 4.... 99 suffix in *CURLIB.

Problem is, if they are on one of their other systems, they don't always have *CURLIB set to what they think it should be. So the default (QGPL) is used, and then the stuff that follows doesn't work.

FTP'ing isn't an issue since I installed the FTPFILE command.

Only time I use even set a *CURLIB is when I am about to run an SQL !--script-- from a source member - I don't qualify the SQL !--script-- for, say, create table - so I set the *CURLIB to where I want the table created at !--script-- run time.

The only other times I ever qualify anything is:

1. QTEMP use - for WORK files!!
2. Trash program to do single task multiple times - set up test environment, copy live file to test, etc.

I can see the point in having work files not in QTEMP - when you need to refer to content at a later time.  Though experience teaches that typically nobody cares what was in a work file, unless a program fails - you could always trap the error and call a routine to copy QTEMP files/dataareas/etc to a debug library for later referal.

Agree, I never use curlib for production stuff.

Goofy named suffix hearkens back to of XYZ?WS? and it's ilk.

Dale, I think you're more accurate than you think. These were all legacy S/36 and S/36E guys who think how ever they do things is "correct" because they've decided its their standard.

A great example is source files. We create all new source files as RCDLEN(112). Yet the other day, I witnessed one of the lead developers copy our QRPGLESRC to a new source file. I asked about it, and he said he needed to convert an old RPGII/III program to RPG IV, and our source files were 80-byte long.

I said, no they are 112. His response was, right, but our standard is 120 so I created a new one at RCDLEN(120) because that way our comments will be preserved and we can continue to place our comments out to the right of the calc spec's.

Now, other than just being a goofy reason to do that (we don't use that area since moving to RPG IV) they also FTP source members between systems and use hand-written FTP !--script--s to do so. They always use ASCII transfer mode. And if you're transferring between source files and those source files have different lengths, you get "word wrapped" results.

I always use BINARY or IMAGE mode with FTP and avoid that issue, but nonetheless it is another example of S/36 developers who haven't taken the time to learn the system and are still programming like they did on S/36.