Insufficient disk space or Write access denied. (291)

rodz

New Member
I have a client using Progress 9.1D (see platform below) that is regularly getting the error: Insufficient disk space or Write access denied. (291) when trying to print a report in their application.

I have looked at this error on other posts but the setup does not seem to mirror what my client has. As their hardware and networking supplier, I have supplied their HP platform and W2K3 OS and using TS for their client PC's to connect over a TCP/IP network. The application provider has a character based application - I believe formally written for UNIX - that is using a Progress db backend. The application provider seems to indicate that it is a server or networking issue however, I have confirmed the following...


[*]this error only occurs when printing in their app
[*]there is tons of free space in the mirrored array (16GB free)
[*]the error only happens occasionally - perhaps one in 30 reports
[*]the permissions have been stable so that cannot be a factor as most of the time there is no problem
[*]network has no congestion (100MB with 1GB link to server from the switch
[*]no problems occur in any Windows applications
[*]hdd has been checked and contains no errors, no problem there

When the error occurs, the user gets booted out of the Terminal Services session. Under TS this app is the only app they can run.

I would really, really like some ideas to point me in the right direction as I don't know Progress or the Application but my client is requesting my help here. So if you can give me some ideas, please consider that you will need to tell me where to look as I am only just getting to know a little about Progress. (I did not do the install, the app provider did so remotely) YES... I know the app provider should be helping with this but they seem quite disinterested so, can anyone share any wisdom with a newbie?

Thanks,
Rodz
 

vinod_home

Member
Hi,

it could be a permission issue. Check what the temporary folder setting is for the progress session. Its defined under -T parameter

hope that helps
 

rodz

New Member
Hi vinod_home,

Thanks. I found the directory specified in the .pf file and checked it's permissions. EVERYONE is allowed and have all but full control of the folder. (The error also happens to the Application Administrator that is in a Group that does have full control)

However, seeing that this is only an intermittant error (most times the users can print fine without seeing the error) I would not think that it could be a permissions error. I feel a permissions wouldn't allow them to print most of the time and then just cause an error occasionaly.

It's still got me baffled.

Here is something else - could anyone comment on this. The -T directory is specifed the same for all users as the same batch file to start the application is used for each Terminal Server user. Does PROGRESS generate temp files that could be named the same? The application seems to always generate reports, temp files etc that have the users username in the filename, and each username in unique so that isn't a problem, but I don't know if PROGRESS would just create some generic file in the temp file that could be the same name for each user? Any comments
 

vinod_home

Member
Hi,

https://progress.primushosting.net/...t&user=&strCurrentSymptom=&strDisplaySymptom=

That is the link for progress knowledge base search. You would find different scenario's which you can verify.

When a user logs into the TS, does the temp (windows system temp) located in the users client machine or is it on the server. If its the client machine, can you have -T point to that. Basically have the temp folder point to a location on the local machine and not the server. It could be that or that the resource (printer in this case) being locked up by another process, which I dont think could be possible cause the print jobs normally queue..


hope the search on the progress web site gives you a clue...

:) I also found there is a bug in Progress 9.1D09 and they recommend to upgrade to 9.1E to fix it .. The link to that is ..
https://progress.primushosting.net/...archclass=&bnewsession=False&selecttype=match

If you have your support still active, thats your best option 'call progress'
 
Top