Ao executar um subprograma ("CALL") ao ler um arquivo indexado onde a chave é um registro funcional a execução é interrompida.
O mesmo programa é executado no COBOL versão 4.1 sem problemas.
Já foram analisados o registro do arquivo (não está corrompido), abertura do arquivo, parâmetros.
Alguém teve algum problema semelhante?
MOVE PAR-EMPRESA TO A-EMPRESA
MOVE PAR-CODFUN TO A-CODFUN
READ ARQUIVO INVALID KEY
EXIT PROGRAM.
Hi Cristina,
From the English translation of your question:
Subprogram Execution in Micro Focus Visual COBOL 7.0 for Eclipse
When executing a subprogram ("CALL") when reading an indexed file where the key is a working record, execution is interrupted.
The same program runs on COBOL version 4.1 without any problems.
The file record (it is not corrupted), file opening, parameters.
Has anyone had a similar problem?
MOVES PAIR-COMPANY TO A-COMPANY
MOVE PAR-CODFUN TO A-CODFUN
READ INVALID KEY FILE
EXIT PROGRAM.
--------------------
I am afraid that you have not provided enough information to investigate this.
The READ appears to be failing with an invalid key condition, but I am not sure what the current state of the program or the file is in.
Is it possible to create a small test program that simply opens the file, moves the same data to the key and attempts the read to see if you can reproduce the failed read?
Thank you
Hi Cristina,
From the English translation of your question:
Subprogram Execution in Micro Focus Visual COBOL 7.0 for Eclipse
When executing a subprogram ("CALL") when reading an indexed file where the key is a working record, execution is interrupted.
The same program runs on COBOL version 4.1 without any problems.
The file record (it is not corrupted), file opening, parameters.
Has anyone had a similar problem?
MOVES PAIR-COMPANY TO A-COMPANY
MOVE PAR-CODFUN TO A-CODFUN
READ INVALID KEY FILE
EXIT PROGRAM.
--------------------
I am afraid that you have not provided enough information to investigate this.
The READ appears to be failing with an invalid key condition, but I am not sure what the current state of the program or the file is in.
Is it possible to create a small test program that simply opens the file, moves the same data to the key and attempts the read to see if you can reproduce the failed read?
Thank you
Hi Chris.
Thank you for your attention.
I have already performed tests by running the program separately and it was successfully executed.
The key of the indexed file is the company code and functional record.
The file was opened as INPUT: "OPEN INPUT FUNCI".
SELECT FUNCI ASSIGN TO DISK
FILE STATUS FUNCI-XSEEDSTATUS ORGANIZATION INDEXED
ACCESS MODE DYNAMIC RECORD KEY FUNCI1 =
FUNCI-FUNEMPRES OF FUNCI
FUNCI-FUNCODFUN OF FUNCI
Reading the file in the program:
MOVE PAR-EMPRESA TO FUNCI-FUNEMPRES.
MOVE PAR-CODFUN TO FUNCI-FUNCODFUN.
READ FUNCI INVALID KEY
EXIT PROGRAM.
The problem occurs when reading the file when the program is executed by calling the main program.
Example: the main program is F20 and the subprogram is F201
Within the program F20, the program F201 is called as follows: CALL "F201" USING W-PARAMETER.
When the program is executed, no error code is displayed; the program just stops at the reading command line.
Hi Chris.
Thank you for your attention.
I have already performed tests by running the program separately and it was successfully executed.
The key of the indexed file is the company code and functional record.
The file was opened as INPUT: "OPEN INPUT FUNCI".
SELECT FUNCI ASSIGN TO DISK
FILE STATUS FUNCI-XSEEDSTATUS ORGANIZATION INDEXED
ACCESS MODE DYNAMIC RECORD KEY FUNCI1 =
FUNCI-FUNEMPRES OF FUNCI
FUNCI-FUNCODFUN OF FUNCI
Reading the file in the program:
MOVE PAR-EMPRESA TO FUNCI-FUNEMPRES.
MOVE PAR-CODFUN TO FUNCI-FUNCODFUN.
READ FUNCI INVALID KEY
EXIT PROGRAM.
The problem occurs when reading the file when the program is executed by calling the main program.
Example: the main program is F20 and the subprogram is F201
Within the program F20, the program F201 is called as follows: CALL "F201" USING W-PARAMETER.
When the program is executed, no error code is displayed; the program just stops at the reading command line.
Without being able to run it here, it is impossible to say what is causing the issue.
If it truly is an invalid key condition, then no error would be displayed because you are simply exiting the program at that point.
It would mean that whatever the value you are setting the key to cannot be found in the indexed file. This makes no sense if you can open the same file in a main program and use the same key value and have the record be found.
Is the parameter being passed the actual value that is being used as the record key?
Is the description of the parameter in the linkage section the same as the description in the calling program?
Under debug can you query the value of the key prior to the read to ensure that it is the value you are expecting?
If you have a small test program that reproduces the problem, I would be glad to take a look at it?
Without being able to run it here, it is impossible to say what is causing the issue.
If it truly is an invalid key condition, then no error would be displayed because you are simply exiting the program at that point.
It would mean that whatever the value you are setting the key to cannot be found in the indexed file. This makes no sense if you can open the same file in a main program and use the same key value and have the record be found.
Is the parameter being passed the actual value that is being used as the record key?
Is the description of the parameter in the linkage section the same as the description in the calling program?
Under debug can you query the value of the key prior to the read to ensure that it is the value you are expecting?
If you have a small test program that reproduces the problem, I would be glad to take a look at it?
Hi Chris
Sorry for the delay in responding and thank you for your attention.
Is the parameter being passed the actual value that is being used as the registry key?
Answer: the parameter is correct
Is the description of the parameter in the binding section the same as the description in the calling program?
Answer: the parameter is the same
In debugging, can you check the key value before reading to ensure that it is the value you are expecting?
Answer: in debugging I can see the parameter value and it is correct
The problem that is happening is that in the main program the file is opened as I-O because the fields are being written and in the subprogram the same file is opened as INPUT.
When reading the indexed file the program execution is blocked.
The support team is currently analyzing the best solution but if you can I can send you the programs and file.
Hi Chris
Sorry for the delay in responding and thank you for your attention.
Is the parameter being passed the actual value that is being used as the registry key?
Answer: the parameter is correct
Is the description of the parameter in the binding section the same as the description in the calling program?
Answer: the parameter is the same
In debugging, can you check the key value before reading to ensure that it is the value you are expecting?
Answer: in debugging I can see the parameter value and it is correct
The problem that is happening is that in the main program the file is opened as I-O because the fields are being written and in the subprogram the same file is opened as INPUT.
When reading the indexed file the program execution is blocked.
The support team is currently analyzing the best solution but if you can I can send you the programs and file.
The problem is that the main program is locking the record in the file when it reads it so when the 2nd program tries to read it, it just appears to hang but it is really waiting for the lock to be released.
You do not specify the LOCK MODE in your select statement but you use the fileshare directive which causes lock mode to be automatic which means records will be locked by the first program read so the 2nd program read cannot read the record.
There are a few ways around this:
You could read add the NO LOCK phrase to the first read but that would mean that someone else could modify it after it was read.
It is recommended to create an EXTFH.CFG file which contains the following options and then set the environment variable EXTFH to point to that file at run-time. The docs for the config file can be found here.:
[xfh-default]
openinputshared=on
ignorelock=on
runitlockdetect=OFF
Also in your example you never close the file so on the second time thru the subprogram the open will fail because the file is still open.
The problem is that the main program is locking the record in the file when it reads it so when the 2nd program tries to read it, it just appears to hang but it is really waiting for the lock to be released.
You do not specify the LOCK MODE in your select statement but you use the fileshare directive which causes lock mode to be automatic which means records will be locked by the first program read so the 2nd program read cannot read the record.
There are a few ways around this:
You could read add the NO LOCK phrase to the first read but that would mean that someone else could modify it after it was read.
It is recommended to create an EXTFH.CFG file which contains the following options and then set the environment variable EXTFH to point to that file at run-time. The docs for the config file can be found here.:
[xfh-default]
openinputshared=on
ignorelock=on
runitlockdetect=OFF
Also in your example you never close the file so on the second time thru the subprogram the open will fail because the file is still open.
Thank you Chris for your help.
I used NO LOCK when reading the file in the main program and closed and reopened the same file in the subprogram before reading it as an indexed file.
The execution was successful.
