|
View previous topic :: View next topic
|
| Author |
Message |
Aravinthkumar
New User
Joined: 09 Feb 2009
Posts: 5
Location: India
|
|
|
|
Hi,
I am trying to write an easytrieve code which in turn calls a COBOL program to read a VSAM file. As I understand, Easytrieve automatically opens the file so that read operation can be performed. When I try to read the VSAM file through the COBOL call, the read fails with a file status of 47 (Trying to read a VSAM file that is not opened in INPUT or I-O mode). So, I even tried to open the file again through the COBOL call wherein the open was successful but the subsequent call to read the VSAM file failed with file status 47.
The reason being am trying to read the file through the COBOL call is that the code to read that particular file already exists and performs few operations on the retrieved record and our requirement is to call the existing COBOL code to achieve this instead of coding the same set of logic again.
Could someone please suggest what am I missing here?
I tried having FILE <VSAM DD name> VS in easytrieve code and without this statement as well but still getting the same file status - 47.
Is there any restriction in reading the file through a COBOL code from Easytrieve?
I can confirm that the COBOL code is perfect as this is running for long time but I couldn't find an existing Easytrieve code that calls this COBOL code.
Please let me know if any additional information is required.
Thanks & Regards,
Aravinth Kumar J. |
|
| Back to top |
|
 |
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
The reason being am trying to read the file through the COBOL call is that the code to read that particular file already exists and performs few operations on the retrieved record and our requirement is to call the existing COBOL code to achieve this instead of coding the same set of logic again.
|
Never seen such a load of crap. Why calling a cobol routine for vsam access, if Easytrev has it all?
So who ever thought out that requirement is brain dead. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| PeterHolland wrote: |
| Quote: |
The reason being am trying to read the file through the COBOL call is that the code to read that particular file already exists and performs few operations on the retrieved record and our requirement is to call the existing COBOL code to achieve this instead of coding the same set of logic again.
|
Never seen such a load of crap. Why calling a cobol routine for vsam access, if Easytrev has it all?
So who ever thought out that requirement is brain dead. |
Reusable code. The standard in my shop is that all I/O and data accesses are done in dynamically-linked external subroutines, and programs call those subroutines.
(Did this cause us a wee bit of trouble when we converted from MVS PL/I to Enterprise PL/I? Why yes, yes it did.) |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
If part of "the rules" is that you must call the existing COBOL program (without changing it) you may have to tell "them" this will not work. . . |
|
| Back to top |
|
|
Aravinthkumar
New User
Joined: 09 Feb 2009
Posts: 5
Location: India
|
|
|
|
| dick scherrer wrote: |
Hello and welcome to the forum,
If part of "the rules" is that you must call the existing COBOL program (without changing it) you may have to tell "them" this will not work. . . |
Thanks Dick!!!That will be my next move but thought I can check whether I am missing something before going back.
But to confirm there isn't any problem with the COBOL code. This is called by other programs but everything coded in COBOL again. This is the first time we are trying to call it from an Easytrieve code.
Regards,
Aravinth Kumar J. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Easytrieve calls COBOL code as easily as COBOL code calls COBOL code. . . However, Easytrieve is a different running environment than COBOL.
With the existing processes that work correctly, how is the vsam file OPENed? In which program(s)? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Read the chapter "Subprograms" in the manual :
"CA-Easytrieve/Plus Reference Guide".
Beside that you can not mix Easytrev IO and called programs IO, it is or
only Easytrev or only called programs. |
|
| Back to top |
|
|
Aravinthkumar
New User
Joined: 09 Feb 2009
Posts: 5
Location: India
|
|
|
|
| dick scherrer wrote: |
Hello,
Easytrieve calls COBOL code as easily as COBOL code calls COBOL code. . . However, Easytrieve is a different running environment than COBOL.
With the existing processes that work correctly, how is the vsam file OPENed? In which program(s)? |
Hi Dick,
The existing COBOL programs call the subprogram to perform open, read and close operations on the VSAM file. The subprogram just receives a value which tells what operation has to be perfomed on the VSAM file.
I even tried similarly from Easytrieve code to call the subprogram to open the file before performing read operation. The open was successful but the subsequent read operation failed with file status 47.
Does it has something to do with DD statement in JCL/FILE statement in Easytrieve code? jst started thinking wild 
Regards,
Aravinth Kumar J. |
|
| Back to top |
|
|
Aravinthkumar
New User
Joined: 09 Feb 2009
Posts: 5
Location: India
|
|
|
|
| PeterHolland wrote: |
Read the chapter "Subprograms" in the manual :
"CA-Easytrieve/Plus Reference Guide".
Beside that you can not mix Easytrev IO and called programs IO, it is or
only Easytrev or only called programs. |
Hi PeterHolland,
I had a look at the manual but couldn't find anything that could help me resolving this. Still scrolling the manual from top to bottom - doesn't help much. 
Regards,
Aravinth Kumar J. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Well it says enough about Linkage conventions, parameter lists etc.
Your calling sequence could be something like this :
CALL cobolprg USING ('OPEN' 'ddname')
CALL cobolprg USING ('GET' buffer)
Maybe you need to find out which parameters are accepted by your cobol
routine.
Once again use the Easytrev vsam io handling. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I still have (at least) one confusion
If the subroutine does the open/close/read why is the vsam file referenced in the Easytrieve code? All that should be needed is the record layout. . . |
|
| Back to top |
|
|
Aravinthkumar
New User
Joined: 09 Feb 2009
Posts: 5
Location: India
|
|
|
|
The environment parameter on JOB statement in Easytrieve code made the difference. As I understand from the manual, it is installation specific which can be set to either NONE or COBOL. This decides in which environment the called programs will be executed.
It was defaulted to NONE in my case and an override of COBOL to ENVIRONMENT resolved the problem.
A lesson learnt!!!
Thanks to Dick - I have now removed FILE statement in Easytrieve code and all the IO operations are taken care by the called COBOL program.
Thanks to PeterHolland - It was you who made me go back and have a fresh look at the manual to identify the culprit!!!
Regards,
Aravinth Kumar J. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| What can i say? Good luck with your requirement. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Good to hear it is working - thank you for posting the resolution 
d |
|
| Back to top |
|
|
|
|
