Summary: Are there any know limits (in particular: 8.3) to the use of "OUTFILE" in a FILEDEF commnad?

Does anyone know of any limitations on OUTFILE when used in a FILEDEF command, such as this:

FILEDEF OUTFILE DISK myappfolder/yyyymmdd_WSS_RPT_??????.txt

Note that the first 8 characters (yyyymmdd) are not going to be unique when "?????" is different for each of 99999 report generations for a given date. Or is OUTFILE a key or reserved word?

What I have found is that, when using OUTFILE, the only "yyyymmdd_WSS_RPT_??????.txt" file out there is the one from the last execution which issued the FILEDEF command. It seems as though it checks the 8.3 part of the FILEDEF'd name and over-writes it.

If anyone has come across this, then they know what this is all about, If not, it may seem a bit confusing ~ in which case I can, if need be, elaborate a bit more.

Thanks In Advance for your input,
Doug

This message has been edited. Last edited by: Doug,

Can you give us some sample code ?

What OS is it on, I assume Windows.

Doug,

try this:

-SET &x = 1;
-REPEAT :endloop 3 TIMES
-SET &ver = &x | '.txt';
APP HOLD saved_reports
APP FI outfile DISK saved_reports/outfile_20120119_&ver
TABLE FILE CAR
PRINT
COUNTRY
ON TABLE HOLD AS outfile
END
-RUN
-SET &x = &x + 1;
-:endloop

I have'nt tried it with more than 5 iterations but in theory it should'nt make any difference.

Cheers
Håkan

Waz: Your assumption is correct: Windows.
Håkan: My isse is not with the number of FILEDEF commands issued. It is the length of the final filename. In my case "rsyyyymmdd_WSS_RPT_??????.txt" is 25 characters long. But, it seems to have an issue because the 1st 8 characters are not unique. And in seeing it as 8 characters, it seems that it is always overwriting the previous file with the latest one. So, it seems that is checks the 1st 8 then write the full name to that file.

I did redo this as follows:

FILEDEF rsyyyymmdd_WSS_RPT_?????? DISK myappfolder/rsyyyymmdd_WSS_RPT_??????.txt

This worked as I expected, i.e: files rsyyyymmdd_WSS_RPT_000001.txt to rsyyyymmdd_WSS_RPT_001000.txt were created. With that in mind, I'm leaning towards an imposed limit associated with OUTFILE...

This message has been edited. Last edited by: Doug,

Doug, I don't know of any limitation in Windows to a filename length.

OUTFILE is nothing more than a DDNAME, just like JCL.

You cannot, imo, have multiple dots in a filename or Windows will not know how to open it...

Thanhks Tom,

quote:

You cannot, imo, have multiple dots in a filename

Sorry, do I have multiple dots someplace? The question marks indicate placehold for the example only. There are no question marks in the actual code.

Well, at the top you stated 8.3. Obviously, I misinterprated that, and, that was the reason for my statement...

NP.. that was just a reference to the good ol (original) DOS filename sizes...

Does this happen for one file, no iterations.

Just a simple filedef and hold ?

If so, can you post the code.


Could there be some sort of OS setting that is causing it ?

This message has been edited. Last edited by: Waz,

Perhaps it's a habit from my mainframe days, but I always avoid beginning file names with a number. You might try using a letter(s) as the first character(s) of the file names.

Doug

can't test it for the moment, but I would say, leave the logical name short and then just issue an APP FI logical_name DISK physical_name. There might be a limitation when it comes to the logical name, but as far as I know, the name of the physical file is just limited by the operating system. Besides, why do you want duplicate Master files, when you can use one only. You can even create a static Master file and SAVE/SAVEB the data file.

Håkan

quote:

I did redo this as follows:
FILEDEF rsyyyymmdd_WSS_RPT_?????? DISK myappfolder/rsyyyymmdd_WSS_RPT_??????.txt
This worked as I expected, i.e: files rsyyyymmdd_WSS_RPT_000001.txt to rsyyyymmdd_WSS_RPT_001000.txt were created. With that in mind, I'm leaning towards an imposed limit associated with OUTFILE...

If you have multiple procedures using OUTFILE as a DDNAME, just clear it at the end:

FILEDEF OUTFILE CLEAR
-RUN

quote:

FILEDEF OUTFILE CLEAR
-RUN

I had a

quote:

FILEDEF CLEAR
-RUN

in there. It seems that I left out the ddname. wouldn't "FILEDEF CLEAR" clear all FILEDEFs?

Nope...

Do a ? FILEDEF after FILEDEF CLEAR and the OUTFILE DDNAME will still be there.

BTW, the suggestion "just clear it at the end" was at the end of "every" procedure, BUT,
I know, that, you know, that was what I meant...

From the manual:

  
Syntax: How to Clear a Logical Name With Syntax

  FILEDEF ddname CLEAR

where:

ddname
     Is the logical name. It may contain one to eight alphanumeric characters.

CLEAR
     Clears the specified ddname.

Thanks for the refresher on this... Gotta tell FILEDEF what to CLEAR, as in: "FILEDEF ddname CLEAR".
... End Of Line ...