File pointer

[sjay]

I am trying to close the file and then reopen it thereafter. I want the file pointer to point it at the 1st record but the pointer is pointing to the record which was last read by the file. File type used in Relative and I am using TAL for writing the program. Also, is it possible that the file is getting pointed at the 1st record when the file is opened after closing it when I am debugging the program and unlike this otherwise
Please suggest.

[Keith Dick]

I am trying to close the file and then reopen it thereafter. I want the file pointer to point it at the 1st record but the pointer is pointing to the record which was last read by the file. File type used in Relative and I am using TAL for writing the program. Also, is it possible that the file is getting pointed at the 1st record when the file is opened after closing it when I am debugging the program and unlike this otherwise.
Please suggest.

I am nearly certain that the program will operate the same way regardless of whether you are running it in the debugger or normally.

The normal behaviour is that the file pointer will point at the first record when the file is first opened, just as you expect.

One possible explanation for what you seem to be seeing is that the file does not actually get closed when you believe it is closed. To check that, you could use the INFO OPENS command in Inspect or the fopen command in Native Inspect. I do not know what the command is in Visual Inspect, but I am sure there is a way to see what files are open in Visual Inspect.

Use the command just before closing the file, then again after closing the file. If the file still appears in the second list, something has prevented the close from working. Look closely at how you are closing the file to see why it did not get closed. Perhaps some mistake is leading your program to close a different file number than you intended, or perhaps the close call gets skipped.

If you perform this check and do find that the file really is being closed, I do not have any other simple explanation of what might be happening. In that case, you probably will have to describe more about what the program does and how it is coded to let me think of some other possible reason for what you are seeing.

If I remember correctly, a file position is associated with each open of the file, independent of any other opens, so I think that it does not matter if your program has more than one simultaneous open of the file. Each new open should start with the file positioned at the beginning of the file. So I believe what you see cannot be explained by multiple opens of the file.

[dimandja]

I am trying to close the file and then reopen it thereafter. I want the file pointer to point it at the 1st record but the pointer is pointing to the record which was last read by the file. File type used in Relative and I am using TAL for writing the program. Also, is it possible that the file is getting pointed at the 1st record when the file is opened after closing it when I am debugging the program and unlike this otherwise.
Please suggest.

Check your Relative Key value. Your READ statement may be using it to
position to a record. Resetting the key value to zero, before
reading, may solve your problem.

[Keith Dick]

Post by dimandja

I am trying to close the file and then reopen it thereafter. I want the file pointer to point it at the 1st record but the pointer is pointing to the record which was last read by the file. File type used in Relative and I am using TAL for writing the program. Also, is it possible that the file is getting pointed at the 1st record when the file is opened after closing it when I am debugging the program and unlike this otherwise.
Please suggest.

Check your Relative Key value. Your READ statement may be using it to
position to a record. Resetting the key value to zero, before
reading, may solve your problem.

Are you sure you are remembering this correctly? I do not remember there being any way to specify a file position as part of an Enscribe READ call. As far as I know, you have to use one of the positioning procs to set the file position.

If he were programming in COBOL, then what you suggest could be happening, but he said he was programming in TAL. Do you know of a way that could happen in TAL? Please explain further if you do. I don't remember anything like that, but maybe I have forgotten something.

[dimandja]

Are you sure you are remembering this correctly?  I do not remember there being any way to specify a file position as part of an Enscribe READ call.  As far as I know, you have to use one of the positioning procs to set the file position.  
If he were programming in COBOL, then what you suggest could be happening, but he said he was programming in TAL.  Do you know of a way that could happen in TAL?  Please explain further if you do.  I don't remember anything like that, but maybe I have forgotten something.

I haven't used Relative files in a while. But I think there is a
Relative Key value that comes in play somewhere.

sjay,

Are you using any of these before reading?
FILE_SETPOSITION_
FILE_SETKEY_
If you do, then do check the values used to position the file pointer.

[Keith Dick]

Post by dimandja

Post by Keith Dick
Are you sure you are remembering this correctly? I do not remember there being any way to specify a file position as part of an Enscribe READ call. As far as I know, you have to use one of the positioning procs to set the file position.
If he were programming in COBOL, then what you suggest could be happening, but he said he was programming in TAL. Do you know of a way that could happen in TAL? Please explain further if you do. I don't remember anything like that, but maybe I have forgotten something.

I haven't used Relative files in a while. But I think there is a
Relative Key value that comes in play somewhere.
sjay,
Are you using any of these before reading?
FILE_SETPOSITION_
FILE_SETKEY_
If you do, then do check the values used to position the file pointer.

Oh, there definitely is a record number that you use to position to a particular record (there can be alternate keys, too, of course). The point in question is whether there is any automatic positioning that occurs as part of the READ call. In COBOL, yes, but in TAL, I don't remember anything like that (and don't see any hint of it in a quit look at the manuals). One must use one of the positioning procs -- the ones you named, or the old POSITION or KEYPOSITION.

The way sjay worded his post, it sounds to me that he did a READ immediately after closing the file and opening it again, and found that the first READ after the reopen did not read the first record in the file, but at the position it had been at before the close and reopen. I notice now that he does not actually mention doing a READ, but just says that the file position is not at the beginning. I just assumed that he did a READ and did not get the first record.

So sjay, if my earlier suggestion did not help you solve the problem, what is it that you see that tells you that the file did not get positioned to the beginning of the file after the reopen? Did you do a READ and not get the first record? If not that, then what?

[dimandja]

Post by Keith Dick
In COBOL, yes, but in TAL, I don't remember anything like that (and don't see any hint of it in a quit look at the manuals)

Actually, I think both COBOL and TAL are doing essentially the same
thing.

While COBOL will require a defined Key Value in the file section and
Working Storage, in TAL the Key value is explicitly set during one of
the two PROC calls. There is no other substantial difference between
the behavior of the actual "read" statements.

[Keith Dick]

Post by dimandja

Post by Keith Dick
In COBOL, yes, but in TAL, I don't remember anything like that (and don't see any hint of it in a quit look at the manuals)

Actually, I think both COBOL and TAL are doing essentially the same
thing.
While COBOL will require a defined Key Value in the file section and
Working Storage, in TAL the Key value is explicitly set during one of
the two PROC calls. There is no other substantial difference between
the behavior of the actual "read" statements.

Yes, the COBOL library uses the Enscribe proc calls. No question of that, but that isn't what I was asking about.

What I was asking about is that in your first post, your wording seemed to imply that you thought there was some way that a READ, by itself, could position to a key value that you thought sjay's program was not reinitializing when it reopened the file. If that is not what you meant, sorry for the misinterpretation, but that is what it seemed you were saying. I thought you were mixing up the COBOL behavior with the Enscribe procs behaviour, but wanted to see whether it was I who was forgetting something about Enscribe procs behaviour.

[dimandja]

Post by Keith Dick
If that is not what you meant, sorry for the misinterpretation, but that is what it seemed you were saying.

You're right Keith. I wasn't clear at all in that first posting. I
was in the middle of building a Dune Buggy when I wrote it. (That's
my other job besides divining lines of code. And it pays the same...
Actually more.)

[ozbear]

I am trying to close the file and then reopen it thereafter. I want the file pointer to point it at the 1st record but the pointer is pointing to the record which was last read by the file. File type used in Relative and I am using TAL for writing the program. Also, is it possible that the file is getting pointed at the 1st record when the file is opened after closing it when I am debugging the program and unlike this otherwise.
Please suggest.

I suggest you have a bug in your program.

Oz

[Newbie]

Thanks for your replies.!

I have closed the file and then the program reopens it. And yes, I am
using position GPC to point to the 1st record position using 0d as the
position. I am reading the file using readlock GPC but the record it
reads is the one on which the file was closed.

Also, is it possible to read the file in reverse order in TAL?


-Sjay

[wbreidbach]

Post by Newbie
Thanks for your replies.!
I have closed the file and then the program reopens it. And yes, I am
using position GPC to point to the 1st record position using 0d as the
position. I am reading the file using readlock GPC but the record it
reads is the one on which the file was closed.
Also, is it possible to read the file in reverse order in TAL?
-Sjay

Now the big question ist what procedure are you using:
If you are using FILE_SETPOSITION_ you will have to use a fixed
variable (0F), using 0d can produce unpredictable results.
If you are using the old POSITION (your should not do this!) 0D would
be correct.
After opening the file there is no need to do a FILE_SETPOSITION_, the
current record pointer is 0f.
Usually there is no need to close and open the file just to set the
record pointer.

As far as I know there is no way simple way to read a relative file in
reverse, this is only supported for key-sequential files, the
FILE_SETKEY_ procedure can enable reverse reading.
A way to read the file in reverse in to use FILE_SETPOSITION_ and a
following read in descending order.
But please remind that the read for a deleted record of a relative
file succeeds, it just returns 0 bytes!

[Keith Dick]

Post by Newbie
Thanks for your replies.!
I have closed the file and then the program reopens it. And yes, I am
using position GPC to point to the 1st record position using 0d as the
position. I am reading the file using readlock GPC but the record it
reads is the one on which the file was closed.
Also, is it possible to read the file in reverse order in TAL?
-Sjay

What you describe the program as doing is what it should do to make the first read after the reopen get the first record. Actually, you do not need to make a positioning call, but explicitly setting the position to record 0 should not hurt. The program probably has an error in it which is making it not do what you are describing that it does. If after looking at the program carefully and/or examining its execution in the debugger, you cannot find the problem, you probably will have to show us the code.

If the program is large or if confidentiality prevents you from showing the code of the real program, you ought to be able to build a test program by extracting just the relevant procedure calls into a new source program, then filling in just enough variable declarations and initializations to permit it to compile and run. The relevant procedure calls, assuming I understand the program correctly from your descriptions, would be:

the first open of the file
any position and/or read calls
the close of the file
the reopen of the file
the position of the file to record 0
the read of the file

Get that test program to compile, run, and be sure it demonstrates the problem, then post it for us to examine.

Also, please explain how you know that the record that the last read gets is not the true first record of the file.

As for your new question: Yes, it is possible to read in reverse order. You must use the KEYPOSITION or FILE_SETKEY_ procedure to do so, since the option does not exist in the POSITION or FILE_SETPOSITION_ procedures. It is possible to position a relative file using KEYPOSTION and FILE_SETKEY_.

Reverse read is requested by setting bit 1 of the positioning-mode parameter to KEYPOSITION or bit 1 of the options parameter to FILE_SETKEY_. For either procedure, you would specify 0 for the keyspecifier parameter. For KEYPOSITION, you would specify a key-value parameter of four bytes each containing 0, with 4 specified in the lengh-word parameter. For FILE_SETKEY_ you would specify a key-value parameter of eight bytes each containing 0, with 8 specified in the key-value-len parameter. Read the full description of the procedure you choose to use from the Guardian Procedure Calls Reference Manual to be sure you understand all the parameters and considerations. If you have questions about how to use it, we will be happy to answer them here.

[wbreidbach]

Post by Newbie
Thanks for your replies.!
I have closed the file and then the program reopens it. And yes, I am
using position GPC to point to the 1st record position using 0d as the
position. I am reading the file using readlock GPC but the record it
reads is the one on which the file was closed.
Also, is it possible to read the file in reverse order in TAL?
-Sjay

What you describe the program as doing is what it should do to make the first read after the reopen get the first record.  Actually, you do not need to make a positioning call, but explicitly setting the position to record 0 should not hurt.  The program probably has an error in it which is making it not do what you are describing that it does.  If after looking at the program carefully and/or examining its execution in the debugger, you cannot find the problem, you probably will have to show us the code.  
  the first open of the file
  any position and/or read calls
  the close of the file
  the reopen of the file
  the position of the file to record 0
  the read of the file
Get that test program to compile, run, and be sure it demonstrates the problem, then post it for us to examine.
Also, please explain how you know that the record that the last read gets is not the true first record of the file.
As for your new question: Yes, it is possible to read in reverse order.  You must use the KEYPOSITION or FILE_SETKEY_ procedure to do so, since the option does not exist in the POSITION or FILE_SETPOSITION_ procedures.  It is possible to position a relative file using KEYPOSTION and FILE_SETKEY_.  
Reverse read is requested by setting bit 1 of the positioning-mode parameter to KEYPOSITION or bit 1 of the options parameter to FILE_SETKEY_.  For either procedure, you would specify 0 for the keyspecifier parameter.  For KEYPOSITION, you would specify a key-value parameter of four bytes each containing 0, with 4 specified in the lengh-word parameter.  For FILE_SETKEY_ you would specify a key-value parameter of eight bytes each containing 0, with 8 specified in the key-value-len parameter.  Read the full description of the procedure you choose to use from the Guardian Procedure Calls Reference Manual to be sure you understand all the parameters and considerations.  If you have questions about how to use it, we will be happy to answer them here.

Yes, Keith, you are right, you can use FILE_SETKEY_ for relative
files, the above comment was written from memory without consulting
the manual. I never used FILE_SETKEY_ (or KEYPOSITION) for relative
files. But you should be careful, FILE_SETKEY_ contains a bit
specifying if the record with the given key or the next one should be
read.

[Keith Dick]

Post by Newbie
Thanks for your replies.!
I have closed the file and then the program reopens it. And yes, I am
using position GPC to point to the 1st record position using 0d as the
position. I am reading the file using readlock GPC but the record it
reads is the one on which the file was closed.
Also, is it possible to read the file in reverse order in TAL?
-Sjay

Take a look at the posts on a very similar problem started by Gaurav titled "Relative file Pointer Error".

In his case the relative file is audited, some records were deleted from the file, the transaction was aborted, and the program is attempting to insure that all the records in the file get deleted, including the ones that the rollback will put back into the file.

If that is similar to what you are doing, some of the suggestions I made there might help with your problem.