#1) Open a disk file called INPUT.DAT for reading, halt with an error
# message if the file is not found or for some reason won't open.

!include FILE_IO.INC

FOPEN file O_RDONLY "input.dat"

if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if

#2) Open a disk file called OUTPUT.DAT for writing, creating the file
# if it doesn't exist, truncate it if it does exist. If it can't be
# opened/created, a) close the input file opened in step 1, b) print
# an error message, c) halt.

FOPEN file O_CREAT|O_TRUNC "output.dat"

if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"
fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if

end


... DOS never says "EXCELLENT command or filename"...
--- MultiMail/MS-DOS v0.40
■ Synchronet ■ Bits-N-Bytes BBS - One Hellova BBS -- telnet://bnb.dtdns.net

RE: HW 100.2
BY: Finnigann to All on Tue Oct 23 2001 10:20 pm

!include FILE_IO.INC

FOPEN file O_RDONLY "input.dat"

if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if

### Everything is fine until the next line. There, you try to open a second ### file with the same <filehandle> "file" as the input file. You should try ### to use unique filehandles, especially if you need to open mulitple files.

FOPEN file O_CREAT|O_TRUNC "output.dat"

if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"

### There is also an error on the next line. You are trying to close a
### filename, and not the <filehandle> (ie. file) as fclose function requires.

fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if

Not Bad, "B" :)

PG

---
■ Synchronet ■ WasteLand BBS ■ telnet://wasteland-bbs.com

RE: HW 100.2
BY: Finnigann to All on Tue Oct 23 2001 10:20 pm

!include FILE_IO.INC

FOPEN file O_RDONLY "input.dat"

if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if

This is cool, except I think you should declare the file handle (as an integer first. So, before the FOPEN you need something like

INT file

FOPEN file O_CREAT|O_TRUNC "output.dat"

This would work fine too, but there is a "gotcha" in there. You are using back the same file-handle, so you no longer have access to the INPUT file. Better declare separate file-handles:

INT infh outfh
FOPEN infh O_RDONLY "input.dat"
. . .
FOPEN outfh O_CREAT|O_TRUNC "output.dat"

From now on, you make all references to the INPUT file by way of the input file-handle "infh" and reference the OUTPUT file via the output file-handle "outfh". BTW, you can use any old name for the handles as you see fit. "in" and "out", "ifh" and "ofh", "input_file_handle" and "output_file_handle" or whatever, so long as it doesn't CLASH with the rest of the language, or anything else in your program.

if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"
fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if
end

Okay, two things here.

Firstly, once you have opened a file, you refer to it by the file-handle, not the name. So it should be

FCLOSE infh

(assuming the change in file-handles recommended above.)

Secondly, your code executes a RETURN which is followed by a PRINT. The PRINT is what is called "unreachable code". You never get to do the PRINT because you always RETURN just before you get to the PRINT. Some compilers will warn you about "unreachable code", but I don't know if BAJA.EXE does.

What you need to do is put the PRINT first and _then_ the RETURN.

Keep it up! Work on the other steps now...

PistolGrip wrote to Finnigann <=-

RE: HW 100.2
BY: Finnigann to All on Tue Oct 23 2001 10:20 pm

!include FILE_IO.INC

FOPEN file O_RDONLY "input.dat"

^^^^
OK

if_false
print "\r\n\r\nnError Loading Configuration File - Input.Dat"
return
end_if

### Everything is fine until the next line. There, you try to open a second ### file with the same <filehandle> "file" as the input file.
You should try ### to use unique filehandles, especially if you need to open mulitple files.

FOPEN file O_CREAT|O_TRUNC "output.dat"

if_false
print "\r\n\r\nnError Loading Configuration File - Output.Dat"

### There is also an error on the next line. You are trying to close a ### filename, and not the <filehandle> (ie. file) as fclose function requires.

fclose Input.dat"
return
print "\r\n\r\nnDue to file error(s) All files closed at this time."
end_if

Not Bad, "B" :)

Actually it's YOUR B as I cut and pasted heavily from your example.

So the 'file' is the handle that BAJA see it as... A varible, assigned in
the act of opening the input.dat. I need to refer to THAT varible when manipulating INPUT.DAT ('file' was prolly a bad choice in that case).
Maybe something descriptive would have been a better choice. Like
'Player_list' or 'Game_scores'

Ditto for output.dat.

A gray sliver of light...


... RAM DISK is NOT an installation procedure!
--- MultiMail/MS-DOS v0.40
■ Synchronet ■ Bits-N-Bytes BBS - One Hellova BBS -- telnet://bnb.dtdns.net

Amcleod wrote to Finnigann <=-

- - - The other items were addressed in a message to Pistolgrip. - - -

Secondly, your code executes a RETURN which is followed by a PRINT.
The PRINT is what is called "unreachable code". You never get to do
the PRINT because you always RETURN just before you get to the PRINT.
Some compilers will warn you about "unreachable code", but I don't know
if BAJA.EXE does.

What you need to do is put the PRINT first and _then_ the RETURN.

Keep it up! Work on the other steps now...

OK and thanks to you and PG. I know this has gotta bite, But I learn
fairly fast.

Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either
slash mark or an astricks or question mark or out of bounds too?


... As a matter of FACT I DO own the road!
--- MultiMail/MS-DOS v0.40
■ Synchronet ■ Bits-N-Bytes BBS - One Hellova BBS -- telnet://bnb.dtdns.net

RE: HW 100.2
BY: Finnigann to Amcleod on Wed Oct 24 2001 02:46 pm

Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?

Answer (from http://synchro.net/docs/baja.html#Variables):

Variable names are not case sensitive and must begin with an alphabetic
character or an underscore (_). Variable names can be any length and
may contain alpha, numeric, and underscore characters only. The
variable name "str" is reserved to represent the current command string
and should not be used as a user defined variable name.

-Rob

RE: HW 100.2
BY: Finnigann to PistolGrip on Wed Oct 24 2001 02:40 pm

So the 'file' is the handle that BAJA see it as... A varible, assigned in the act of opening the input.dat. I need to refer to THAT varible when manipulating INPUT.DAT ('file' was prolly a bad choice in that case).
Maybe something descriptive would have been a better choice. Like 'Player_list' or 'Game_scores'

You've got the gist of it. The file handle is a variable (in BAJA it is an INT) that you use to refer to the file. The FOPEN command assocuates a file on disk, by name, with the file handle. Then, everything else you do to that file, you specify the file handle, rather than the name.

If writing a relatively simple program, you can name file handles like "in" and "out" etc, but you _could_ open MANY files and refer to them at different times. In that case it is wise to name the handles something that will make using them easier. You might have CfgHnd, UsrHnd, LogHnd, InHnd, OutHnd, and so forth, all open at once. In languages that allow them, you could have an ARRAY of handles, or even write file handles to a file and read them back later (!) for arcane reasons.

The main thing to do is avoid mixing them up. You don't want to accidentally try weriting log-file entries to the read-only configuration file, just because you called them 'abc' and 'xyz' and then got them mixed up in your mind!

RE: HW 100.2
BY: Finnigann to Amcleod on Wed Oct 24 2001 02:46 pm

Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?

In BAJA the file handle is just a common integer, so the naming conventions are exactly the same as for integers.

Don't try doing arithmetic with file handles! :) The arithmetic will work fine, but the files themselves are likely to go to hell very shortly thereafter!

RE: HW 100.2
BY: Finnigann to PistolGrip on Wed Oct 24 2001 02:40 pm

Not Bad, "B" :)

Actually it's YOUR B as I cut and pasted heavily from your example.

Well, I don't believe my example included duplicate filehandles :)

So the 'file' is the handle that BAJA see it as... A varible, assigned in the act of opening the input.dat. I need to refer to THAT varible when manipulating INPUT.DAT ('file' was prolly a bad choice in that case).
Maybe something descriptive would have been a better choice. Like 'Player_list' or 'Game_scores'

Yes, technically I guess the <filehandle> is a variable of type integer that points to the file. This is how you keep track of which file you are working on. Otherwise, it would/could be tedious to do with the filename. There's more to it than that, but you need a way to reference a file.

A gray sliver of light...

:=0

PG

---
■ Synchronet ■ WasteLand BBS ■ telnet://wasteland-bbs.com

Digital Man wrote to Finnigann <=-

RE: HW 100.2
BY: Finnigann to Amcleod on Wed Oct 24 2001 02:46 pm

Question: On naming internal file handles, is there a character limit?
ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?

Answer (from http://synchro.net/docs/baja.html#Variables):

Variable names are not case sensitive and must begin with an alphabetic
character or an underscore (_). Variable names can be any
length and
may contain alpha, numeric, and underscore characters only. The
variable name "str" is reserved to represent the current
command string
and should not be used as a user defined variable name.

Thanks - and bookmarked.


... SBBS: The Best BBS in the World - But no where else.
--- MultiMail/MS-DOS v0.40
■ Synchronet ■ Bits-N-Bytes BBS - One Hellova BBS -- telnet://bnb.dtdns.net

RE: HW 100.2
BY: Amcleod to Finnigann on Wed Oct 24 2001 17:54:00

RE: HW 100.2
BY: Finnigann to Amcleod on Wed Oct 24 2001 02:46 pm

Question: On naming internal file handles, is there a character limit? ie: no spaces or other characters forbidden. I guess periods and either slash mark or an astricks or question mark or out of bounds too?

In BAJA the file handle is just a common integer, so the naming conventions exactly the same as for integers.

Don't try doing arithmetic with file handles! :) The arithmetic will work fine, but the files themselves are likely to go to hell very shortly thereafter!

What, exactly, _WOULD_ happen if you _did_ do arithmetic with file handles?


---
■ Synchronet ■ Viva, le U FAK A P AS Way Type Q! - Remember 9-11

RE: HW 100.2
BY: Prime to Amcleod on Tue Sep 19 2000 07:31 am

Don't try doing arithmetic with file handles! :) The arithmetic will wo fine, but the files themselves are likely to go to hell very shortly thereafter!

What, exactly, _WOULD_ happen if you _did_ do arithmetic with file handles?

Well, handles are just integers, and they can be just about anything. for instance they may represent integer indexes into a table of file-control-blocks so if you added your third and fifth handles you would get the handle of some file furthur up the table -- possibkly one never opened -- and the results of accessing that file would be (most likely) a dismal failure with interesting side-effects. Possibly the the handle is the actuall _address_ of the FCB and so monkeying with them could give a pointer into some random part of memory which would again, give interesting and unpredictable side effects if you tried to use it.

You can probably experiment safely with _writing_ the file handle to the console. Open three or four files and print the file handles as integers. You may get a series of integers like 3, 4, 5, 6 for the four filehandles. SO you add two to the first file handle and it suddenly becomes the third filehandle...
\/s

RE: HW 100.2
BY: Amcleod to Prime on Thu Dec 06 2001 16:04:00

RE: HW 100.2
BY: Prime to Amcleod on Tue Sep 19 2000 07:31 am

Don't try doing arithmetic with file handles! :) The arithmetic will fine, but the files themselves are likely to go to hell very shortly thereafter!

What, exactly, _WOULD_ happen if you _did_ do arithmetic with file handle

Well, handles are just integers, and they can be just about anything. for instance they may represent integer indexes into a table of file-control-blo so if you added your third and fifth handles you would get the handle of som file furthur up the table -- possibkly one never opened -- and the results accessing that file would be (most likely) a dismal failure with interesting side-effects. Possibly the the handle is the actuall _address_ of the FCB a so monkeying with them could give a pointer into some random part of memory which would again, give interesting and unpredictable side effects if you tr to use it.

You can probably experiment safely with _writing_ the file handle to the console. Open three or four files and print the file handles as integers. may get a series of integers like 3, 4, 5, 6 for the four filehandles. SO y add two to the first file handle and it suddenly becomes the third filehandle...
\/s

Just a thought, but shouldn't there be some mechinism to prevent the accidental adding of file handles?


---
■ Synchronet ■ Viva, le U FAK A P AS Way Type Q! - Remember 9-11

RE: HW 100.2
BY: Prime to Amcleod on Sat Dec 08 2001 02:20 pm

Just a thought, but shouldn't there be some mechinism to prevent the acciden adding of file handles?

Well, that would require the declaration of a new basic type, so that the compiler could distinguish between handles and integers and prevent certain operatyions on handles that itn otherwise allows on integers.

There are different file I/O models that don't use file handles per se. You could use some sort of stream-based I/O like the C/C++ fopen() mechanism that opens a stream and returns a pointer to a file-object.

But there are _occasionally_ reasons that might cause you to legitimately do arithmetic to a file handle. Say you wanted to open six files and send data to each of them in turn in a round-robin scheme (for whatever reason). Then *_IF_* your file handles are simple numeric integers, you could do something that outputs to the handle and adds one to it (to point to the next file) so that each output went to the next file. You would have to check that you were at file #6 and reset to #1, but in theory you could do handle-arithmetic. Not a wise move, though, unless you are very intimate with the internal workings of your compiler and your OS. Dangerous and non-portable. Microsoftian, even!

RE: HW 100.2
BY: Prime to Amcleod on Sat Dec 08 2001 02:20 pm

Just a thought, but shouldn't there be some mechinism to prevent the acciden adding of file handles?

Oh well not for Perl. Who knows, maybe somebody WANTS to do that.So the Perl methodology continues to pervade our virgin minds.

Yes, I'm learning perl at work now. Yes, I wrote a script with an 80+ character regular expression. Yes, it felt good.