Good day - i have a stumper:

I have an odd problem doing an APPEND - I did figure out that the problem ONLY exists in 1 PPN of a large server.

I get the following error IF the outfile already exists.

ex:

.append fjd.lst=systat.lst,ps.lst
?Could not create temporary file

In this case fjd.lst already exists, but of course this is legal. Even if I try the following it fails:

.append fjd.lst=fjd.lst,ps.lst
?Could not create temporary file

If I erase fjd.lst this works:
.append fjd.lst=ps.lst,systat.lst
.
So the problem seems to be if the target or <outfile> already exists. Oddly after an hour of tracking this down i found that it IS working in other ppns:

.make fjd.lst
.append fjd.lst=fjd.lst,ps.lst
.

OS VER: A-Shell Version 6.4.1547.0 Up and Running
APPEND LIT 9 2.1(116)

I realize 6.4 is more than long in the tooth but I don't believe thats the issue here since it works on same system other PPN. So what should I look for? Some sort of permission issue? I should also note that this had been working fine until just a couple days ago w/o any changes made to the code.

TIA

APPEND creates a temporary file if the target file already exists. (You could trace this by SET TRACE FOPENS ON, and if the BASERR trace is also on, the ashlog may well contain a better description of the error.) But my guess is that the privileges on this directory don't allow your process the right to create a new file. (Creating a new file requires the write access to the directory, whereas merely writing to an existing file does not.) If this is the situation, it would be easy enough to recreate with any other command involving file create, such as MAKE, CREATE, etc. Or a 2 line program consisting of opening a non-existent file for output and closing it again.

Thanks for the reply. This is a live running database if there were write problems this would be the least of my concern. However i tested both MAKE and CREATE commands from the dot and both work. I added FOPENS to trace and retired append and it failed as before but no entries are in ashlog.

(lobs pickelball back to your court... )

PS: What is the name of the tmp file that is created? Perhaps it is "stuck" on the drive and not allowing the system to re-use it?

PSS: Sonofabitch - i found it. APN##.tmp files. Maxed out at 99 apparently. I erased them and gtg... but wth man - please add to "fix list".

PSSS: Having checked other hosted servers for the same problem this is the only one with residual APN*.TMP files - all running 6.4 so now i am even more stumped.

Hmmm... on closer reading of the code, the "Could not create temporary file" message is actually a literal print statement in APPEND.LIT, issued in exactly the circumstance you have, i.e. that the range of 100 APN##.TMP files was used up. The file is normally erased on completion of the operation, so that implies that prior to getting to this point the APPEND operations were failing in some other way.

BTW, I'm assuming you have 2.1(116) of APPEND.LIT (hasn't changed since 2012).

So that might explain why there were no entries in the ashlog. But now that you've removed the TMP files, what happens? Is it working? Failing? With an error or without one? If still unclear, then add SET TRACE RW ON to the FOPENS ON, which should output a bunch of traces.

If that still doesn't bring any clarity, I can create an updated APPEND.LIT with more detailed traces to track the operation at a lower level.

On a side note, although you have probably already heard this, we're on the verge of rolling over to 7.0, at which point we'll start looking for a shady spot under a tree somewhere to bury 6.4. So although it's a major hassle to update large production systems like this, almost certainly the Linux version is equally beyond its expiration date, so the time to face up to the task is nigh.

Yes, perhaps you glanced over it but yes its working now. I have the version listed there on post #1 and yes, its 116.

And yes - time to pay the piper, 2024 will be the year of the update!

Ah right -- I guess it's true that people are as good at multi-tasking as they think they are. And I might have mistook gtg for some kind of onomonopoeiac freeform expression of frustration rather than "good to go".

But just to be clear, is it leaving behind TMP files? If not, perhaps we'll never know what caused it. Unfortunately it's too late now, but it might have been interesting to look at the file dates. The only theory I can think of is that at some point there was a privilege issue which quickly led to 100 of those files being created. The privilege got fixed but the files didn't get erased, causing APPEND to fail ever since.

I guess it's time to review and update that code.

I should be able to recreate easily if you want to see - but I did erase them in order to move on.

BRB - (be right back!)

OK so oddly now that it is "working" there are no .tmp file droppings left behind... how odd that it would randomly do that then stop. There were remnant .tmp files across all ppns on this server but now the problem has disapperad. (what we call here FM - F#$%^ magic :D)

I realize that you could reproduce the problem by creating 100 APN*.TMP files. But that wouldn't tell us what error caused them to be created and not erased in the first place. If any of those files were recent, you might still have a record of the error in one of your ashlog files. (This is a good use for the new VIEWASHLOG; for example VIEWASHLOG/PROG:APPEND/LOOKBACK:10 would search for all logged messages for the program APPEND in the last 10 archived copies of the ashlog file.)

GTL (gone to lunch.)

No i realize that, however I would presume that i would now have a APN1.TMP and ANP2.TMP etc every time this attempted until it ran out of resources at 100.

If you want to add a link to download VIEWASHLOG i will be happy to give it a try.

TTYL

Sorry, VIEWASHLOG requires 1739+, so it won't run under 6.4.

But as for the TMP files, I'm still not clear: are those still being created and left on disk now? Or not? If so, that surely implies that the program is aborting somehow, but it seems like you would see the error message, if not on the screen, then in the ashlog (which you may just have to use EZTYP on manually).

ROOA (Ran Out of Acronyms)

Evening,

Oddly it is not saving those .tmp files now and I don't know what to tell you why... so nothing to show you unfortunately.

WIBF (Well it's been fun)!

A lot of distractions here today, but there's a good chance of a quiet spell before cocktail hour, so maybe I'll give APPEND a refresh. If nothing else, the symptoms would at least be different next time.

EYW (Enjoy your weekend)

FWIW, I did a modernization pass on APPEND.LIT and pushed the new version 2.2(117) to the 7.0 repository where it can be retrieved (on to a 7.0 system) via UPDCUR. It won't work with 6.4 though, so doesn't do you any immediate good, but it does eliminate the temp file scheme for future use. (It uses a single temp file based on the jobname, overwriting any prior one if somehow it failed to get removed by the prior instance.)

Thanks for the update Cap.