We use PKZIP to programmatically make backups from within our application.
I have a problem with only one file that gives an error "Warning! Could not open file VPMS2006.pay".
I thought it might be that the file is in an open state but that was not the case.
The file select is :
ASSIGN TO RANDOM MIS2NAME
WITH ENCRYPTION COMPRESSION
COMPRESSION CONTROL VALUE 70
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
LOCK MODE IS AUTOMATIC
FILE STATUS IS DSTAT
RECORD KEY IS MIS2KEY-NEW.
Any ideas on what could be causing this?
We used to use pkzip but had issues when switched to win7 We now call a batch file which runs the command line version of 7zip for making backups.
We don't use the compression control or encryption compression but I have a question.
Is the MIS2NAME file the backup of the original or is it the original file that is to be backed up?
You say that the file is not open, so that makes me think its the original, but just checking.\
Is it an Acucobol warning message or a warning message generated from within your program. Is it possible to provide the extended file status (four character file status)
Is VPMS2006.pay the name of the file assigned to MIS2NAME? Why would PKZIP need to actually open a file, a zip is a list of files and PKZIP makes an archive? Are your files Vision 3 file (single format file)?
Yes, VPMS2006.pay is the name of the file assigned to MIS2NAME. We are using vision version 5 files, so there is also a VPMS2006.vix file which gives the same problem. All the other similar indexed files works fine except this one. I agree about the open but that is a pkzip message and most likely part of their process that they use to archive.
Justing guessing, it appears that the file is still being held by the runtime until the stop run. Are you using transaction management, what type of locking are you using on the file, and is the file closed before the runtime stop run statement.
Not using transaction management. I have tried to close the file before calling the archiving process to make sure that it is in fact closed, but I get a status "42" - file not open on the close. The file appears to be closed, but when I do a trace, there is a warning that the file is not closed just before the stop run. This tells me that my test with the close before the archiving, wrongly indicates that the file is not open. This does not make sense.
I also suspect Windows Opportunistic Locking may be involved. Capturing a Process Monitor log while exercising this part of your application will likely help you sort it out.