View previous topic :: View next topic |
Author |
Message |
misi01 Advanced
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
|
Posted: Thu Oct 02, 2014 8:35 am Post subject: OPEN and CLOSE of GSAM files |
|
|
I'm almost embarrassed to append this question, but here goes.
I've been asked to revisit a checkpoint program that reads a file as GSAM. What I've never seen in a program GSAM program before is the fact that the program must perform a pass through the whole file first (to extract various records). After that, it rereads the file.
The colleague who wrote this swears that it works correctly, so my question is this ....
Does IMS (under the covers) automatically close the file when it reaches an EOF so that the next read automatically places the read pointer at the first record????
(I've never seen ANYONE write a program like this before) _________________ Michael |
|
Back to top |
|
|
William Collins Supermod
Joined: 03 Jun 2012 Posts: 437 Topics: 0
|
Posted: Thu Oct 02, 2014 10:32 am Post subject: |
|
|
Isn't a GSAM file actually a VSAM file where IMS manages the content, and uses AMS so it doesn't have to have a separate IO system?
With a VSAM file, there is no need to close a file and reopen it to get the pointer back to the start. At least not with Assembler for an ESDS (using EBA access) but even COBOL can do a START.
If the GSAM file is being read by IMS (I have no clue about such things, sorry) it may well be the standard behaviour. A test on something with only a small amount of data should quickly confirm. |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
|
Posted: Thu Oct 02, 2014 11:06 am Post subject: Re: OPEN and CLOSE of GSAM files |
|
|
misi01 wrote: |
Does IMS (under the covers) automatically close the file when it reaches an EOF so that the next read automatically places the read pointer at the first record????
(I've never seen ANYONE write a program like this before) |
IMS does NOT close the file under the covers. When you reach the end of file you check the status code and then you can issue the close or or perform a "Get Unique" if you have saved the first record pointer/key in the RSA.
William Collins wrote: | Isn't a GSAM file actually a VSAM file where IMS manages the content, and uses AMS so it doesn't have to have a separate IO system? |
GSAM files are regular sequential files, But IMS lets you check-point and restart the files when you save the keys. _________________ Kolusu
www.linkedin.com/in/kolusu |
|
Back to top |
|
|
William Collins Supermod
Joined: 03 Jun 2012 Posts: 437 Topics: 0
|
Posted: Thu Oct 02, 2014 11:12 am Post subject: |
|
|
Thanks Kolusu.
So, Misi01, you have a mystery.
I'd try to minimise the code, and running on small data, and either find out in the process what is going on, or having something where you can concentrate on what is actually happening. SOP. I guess you know this anyway
Treat your colleague's assertion as an assertion. It may look like the program is working, but it ain't necessarily so. |
|
Back to top |
|
|
misi01 Advanced
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
|
Posted: Thu Oct 02, 2014 2:01 pm Post subject: |
|
|
Kolusu Quote: | IMS does NOT close the file under the covers. When you reach the end of file you check the status code and then you can issue the close or or perform a "Get Unique" if you have saved the first record pointer/key in the RSA.
|
Not sure I understand that with respect to the fact (as you mentioned) that the GSAM file is a simple sequential file. What would I use for the GU key? I've never heard of doing an explicit CLOSE on a GSAM file (in the same way the COBOL program never explicitly OPENs the file)
William. I chopped the file to a manageable length and ran code similar to the following
Code: |
set gsam-eof-no to true
perform until gsam-eof-yes
perform read-gsam-file
display first 40 bytes of record
end-perform
set gsam-eof-no to true
perform until gsam-eof-yes
perform read-gsam-file
display first 40 bytes of record
end-perform
|
The read-gsam-file section contains code that sets gsam-eof-yes to true when we get a GB status code back from the AIBTDLI call.
What I saw were records 1-20 being displayed and then records 1-20 being displayed again _________________ Michael |
|
Back to top |
|
|
William Collins Supermod
Joined: 03 Jun 2012 Posts: 437 Topics: 0
|
Posted: Thu Oct 02, 2014 3:05 pm Post subject: |
|
|
Well, looks like your colleague was correct then.
I guess mostly people stop reading when they get eof
Have you checked in any IMS manuals to see if it is documented behaviour? |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
|
Posted: Thu Oct 02, 2014 7:07 pm Post subject: |
|
|
misi01 wrote: | Kolusu Quote: | IMS does NOT close the file under the covers. When you reach the end of file you check the status code and then you can issue the close or or perform a "Get Unique" if you have saved the first record pointer/key in the RSA.
|
Not sure I understand that with respect to the fact (as you mentioned) that the GSAM file is a simple sequential file. What would I use for the GU key? I've never heard of doing an explicit CLOSE on a GSAM file (in the same way the COBOL program never explicitly OPENs the file)
|
misi01,
I stand corrected. Under the "GB" status code explanation it lists the following
IMS wrote: | IMS also returns this status code when it has closed a GSAM data set. The assumed position for a subsequent request for a GSAM or full-function database is the beginning of the database, or if a SETR statement was used for a DEDB database, the beginning of the current range. |
Full text of the message.
Code: |
GB
Explanation:
In trying to satisfy a GN call, DL/I reached the end of the database or, if you used a SETR statement, the end of the current range. In this situation, the SSA for the call or qualification for the command specified data beyond the last occurrence, and the search was not limited to the presence of a known or expected segment occurrence.
For example, a GN call was specified for a key greater than a particular value, rather than a GU call specifying a key value beyond the highest value.
A GB status code can be returned for:
An unqualified GN call
A qualified GN call without a maximum key (if no data is returned to the I/O area)
In contrast, a GE status code, instead of a GB status code, can be returned for:
A GU call
A qualified GN call without a maximum key (if data is returned to the I/O area)
A qualified GN call with a maximum key
IMS also returns this status code when it has closed a GSAM data set. The assumed position for a subsequent request for a GSAM or full-function database is the beginning of the database, or if a SETR statement was used for a DEDB database, the beginning of the current range.
Rather than having an abnormal termination occur, this status code is returned to the application program that issued the EXEC DLI command.
Programmer response:
User determined. |
http://pic.dhe.ibm.com/infocenter/eiic/v1r1/topic/com.ibm.ims9.doc.mc/p0hexpl.htm?path=2_7_2_34_1_1#p0hexpl |
|
Back to top |
|
|
misi01 Advanced
Joined: 02 Dec 2002 Posts: 629 Topics: 176 Location: Stockholm, Sweden
|
Posted: Fri Oct 03, 2014 12:11 am Post subject: |
|
|
Thanks Kolusu.
Wow, I'll bet that's news for 99% of us !!!!!! _________________ Michael |
|
Back to top |
|
|
William Collins Supermod
Joined: 03 Jun 2012 Posts: 437 Topics: 0
|
Posted: Fri Oct 03, 2014 12:57 am Post subject: |
|
|
And not just GSAM, either.
There's a little hint that a "close" may be involved, but it is one of those frustrating manual references where it might me "when it is closed and you do this, you'll get the code, on the next request you'll get the start of the db" or "when you do this you'll get the code and the GSAM/db will be closed, with the next request opening, so getting the start of the GSM/db".
I'd put it at higher than 99%. There's your colleague and... now a few more... |
|
Back to top |
|
|
|
|