8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CAT5MSGS.ARC / CAT5.2MSGS930520 < prev next >

Wrap

Text File | 2019-04-13 | 31.3 KB | 903 lines

************ Topic 24 Sun Sep 06, 1992 B.VRIELING1 (Forwarded) Sub: Upload: CS-DOS Extra Utilties Pack V2.0 I have uploaded file #10024, CS-EXTRA2.0.ARC to library #2. (See following message for details). 4 message(s) total. ************ ------------ Category 5, Topic 24 Message 1 Sun Sep 06, 1992 B.VRIELING1 (Forwarded) New Upload: CS-EXTRA2.0.ARC, file #10024 This new archive replaces V1.0 of the CS-DOS Extra Utilities Pack, released by me around Feb '92. This one contains all the CMD directory related commands of the original pack (RD, MD, CD, and CP) plus two new ones: 1) WPVIEW - view WordPerfect documents. It has been tested with documents from both 5.1 and 4.2 IBM versions of WordPerfect, and should work with the Amiga versions as well. 2) ZIPVIEW - view directories (only! - no decompression done!) of IBM ZIP files. All of the above mentioned files ONLY run under CS-DOS. Complete documentation is included in the archive. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 24 Message 2 Tue Sep 08, 1992 C128.JBEE [* Sysop *] (Forwarded) Nice little package :) ------------ Category 5, Topic 24 Message 3 Wed Sep 23, 1992 JBEE at 17:36 EDT ------------ ************ Topic 25 Sun Oct 04, 1992 B.VRIELING1 at 21:49 EDT Sub: New Upload: CS-XTRA3.SFX Version 3.0 of the CS-DOS Extra Utilities Pack, CS-XTRA3.SFX, has been uploaded to library #9. 73 message(s) total. ************ ------------ Category 5, Topic 25 Message 1 Sun Oct 04, 1992 B.VRIELING1 at 21:49 EDT The Pack is a collection of utilities that run under CS-DOS which enhance the CS-DOS environment. Existing commands in the archive: CD, RD, MD, CP, WPVIEW, ZIPVIEW. New commands: 1) IDIR displays directories of IBM format diskettes. It currently works with 360K 5 1/4" and 720K 3 1/2" disks. This command is a precursor to ICOPY, due out at a later date. 2) SEARCH hunts a given list of files for a specified text string. 3) SETRAM is a modification to an existing CS-DOS command which allows placement of the ramdisk anywhere in an expanded REU. The 512K barrier is gone! I currently place my ramdisk in the area from 512K to 1 meg, and use the first 8 banks of the REU for LHA storage. 4) RDIR (same reasons as SETRAM) Note that Parsec owns copyright on the last two commands mentioned above. I wrote neither the original code nor the included documentation. I merely modified the existing modules. This is also explicitly stated in the included documentation. If you have any comments, suggestions for new modules, or bug reports, please let me know. (Note that it may take a day or two before this upload becomes 'live'.) Enjoy! GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 2 Mon Oct 05, 1992 C128.JBEE [* Sysop *] at 01:49 EDT Sounds interesting :) Can't wait to try them out, especially IDIR! ------------ Category 5, Topic 25 Message 3 Mon Oct 05, 1992 R.KNOP1 [Rob Knop] at 09:36 EDT I like the SETRAM! Since everything else uses the first 512K of the REU, probably it would be possible to bootup CS-DOS, and then be able to keep your RAM disk intact while doing other things (e.g. Dialogue128). If you don't turn off the computer, then you could rapidly go back into CS-DOS. -Rob ------------ Category 5, Topic 25 Message 4 Mon Oct 05, 1992 B.VRIELING1 at 20:59 EDT Rob, That's exactly what I do with my setup. Most software that make use of the REU blindly trample the first 512K. By putting my CS-DOS ramdisk between 512K and 1 meg, I leave the first 512K free. I use it for LHA storage in CS-DOS, and when I am not using CS-DOS, other programs may trample at will. Rebooting and reloading the ramdisk was getting tiresome. My ramdisk contains well over 120K of files... ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 5 Sun Oct 11, 1992 S.CRAIK [Steve] at 03:17 EDT Hi Bruce, Just thought, I'd let you know.. about some of my findings (though not entirely conclusive) ..but wtr to RAMLink and partitions I haven't got my RAMLink setup in a way that there would be a 1581 sub within a NATIVE partition ..so I don't know an answer to that occurance. But, since I have several partitions as 1581 parts. I just make sure that I ASSIGN them. Just like HOWIE's SETTIMEDAY (different default number ..though) anyway, I've been able to MOVE COPY, and pretty sure ARC128 to and from various partitions. BTW... I did have a bit o' trouble with IDIR on a 5.25 IBM disk. BBR was able to read the disk. ?? But, sadly I didn't have another disk to check IDIR on the internal 1571 (Jiffy-Dos ROM). I didn't have that problem with the 3.5 disks that I tried. ALL of the disks had been created on a CLONE with the specified amount of Kbtyes that those drives can handle. Steve Craik ------------ Category 5, Topic 25 Message 6 Sun Oct 11, 1992 B.VRIELING1 at 08:18 EDT Steve, First of all, thanks for the feedback. You're the first.... :) Re: your suggestions with the RAMLINK I also have a RAMLINK, and have found success with ASSIGNing drive letters to different partitions. CS-DOS seems to co-exist with a RAMLINK quite nicely. One area where compatibility IS a problem, however, is concerning subdirectories. Most CS-DOS commands do NOT accept PATH information within the filename. For example, COPY E:\PATH\FILENAME E:\ALT-PATH\FILENAME ... doesn't work. I have tried all variations of the above as well (including RL-DOS syntax, of course) and COPY simply won't do it. After examining the source/object code to COPY, it is obvious that the fault does not lie with COPY. COPY simply passes the parameter to the CS-DOS shell to open the file. The shell is the component with the problem. The solution, of course, is to update the shell. However, John likely has a few other priorities right about now like the GEOS ARC program, and the menu driven ARC program he was talking about... and likely a couple more as well. If the shell can't be updated, then I'm going to try to update COPY. In other words, parse the passed filename MYSELF, change to the directory, and THEN open the file through the shell. This should not be hard. Re: your other comments concerning IDIR IDIR sort of 'hangs by a thread' when determining the type of drive to be searched. The 1581 has the sides exactly FLIPPED compared to the 1571, so it was important to determine the drive type from the returned STATUS BYTE. The problem occurs with drives that return a slightly different STATUS BYTE. JiffyDos might do this. The one bit I'm depending on is listed as being undefined. ;) By the next release, I hope to have this problem straightened out. In the meantime, I may upload a program to test the status information being returned from the 'problem' drives... ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 7 Mon Oct 12, 1992 CMD-DOUG at 11:16 EDT Are you sure you had the subdirectory syntax correct? What you listed in your response was NOT correct RL-DOS syntax...you had the colon after the drive number, and I know that that is what CS-DOS needs, but RAMLink needs one before the filename after the last slash in the path. ------------ Category 5, Topic 25 Message 8 Tue Oct 13, 1992 B.VRIELING1 at 19:57 EDT Doug, I tried everything. You're right in that the syntax I listed is NOT RL-DOS syntax. However, the other varieties don't work either, as far as I can tell. Have you found otherwise? ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 9 Wed Oct 14, 1992 S.CRAIK [Steve] at 04:33 EDT Hi Bruce, I believe I may have been incorrect in stating that I could use ARC128 across some partitions, while in/on a RAMLink partition What I can to ..is when on a (1581 lets say, as default) is .. create an ARCHIVE on the 1581 and then call on various partitions (assigned,of course) from RAMLink for various files to be included. What I thought I could to but ..seems I couldn't, after several *failed* attempts was.. create an archive in D: which happens to be partition 12 (actually D: could be any partition in the RL). Hmm? I couldn't ASSIGN partition 12 directly. I have to use RLCP (I re- named, your CP to RLCP) so RLCP 12 sets up 12 as default or the assigned letter D: (assign D to 11,0) the rest of the partitions used 6,7,8 correspond to E to 11,6 F to 11,7 G to 11,8. Now, in D: I tried to create an archive there from files in F: couldn't do it.. well, it started to but got the *RED ERROR LIGHT* on RAMLink. (just a little note: I have partition 12 as NATIVE, sorta a WORK DISK with lots o' room. I do my file transfers there as well as archiving ..etc.). Hmm? I could have swore I could.. perhaps it was another ARCHIVER, but ARC128 didn't want to work. DRAT! (btw ARC128 = ARC, I've renamed it and installed as ARC). ..and so it goes But, I still continue, I guess I'm stubborn, I still say that I could. Hmm? BTW.. since you've created ZIPVIEW! (you know the question, next) Will there be a ZIP'per and or UNZIP'per for CS-DOS and 128 native mode. (I say NATIVE, meaning that someone is working on a CP/M ZIP- per.. and there already exists a UNZIP.) ??? Steve Craik ------------ Category 5, Topic 25 Message 10 Wed Oct 14, 1992 C128.JBEE [* Sysop *] at 07:45 EDT Since archiving is being mentioned here I just thought I would point out that arc doesn't compress files correctly on the HDs, or least it doesn't extract properly the files it compressed ;) This will be taken care of in a near update. ------------ Category 5, Topic 25 Message 11 Thu Oct 15, 1992 HOWIE-CBM at 02:30 EDT Steve, I also recall that some of the compressing programs had a prob accessing several ASSIGNed drives if on one command line. However, for everyday type activity it is very convenient having partitions assigned a drive designation. By the time I get to SFX anything, most of the things have already found their way into one partition. JBEE, Extracting errors on the HD? That is strange since there aren't any on RL. Quess there are some subtle DOS differences. :) Howie ------------ Category 5, Topic 25 Message 12 Thu Oct 15, 1992 C128.JBEE [* Sysop *] at 11:17 EDT Try ARCing a relative file over 500 blocks or so, it won't work properly in a native mode partition with either Ramlink or the HD. ------------ Category 5, Topic 25 Message 13 Fri Oct 16, 1992 HOWIE-CBM at 01:11 EDT JBEE, A relative file? I never tried arcing one of those. Let's see, I have one here that's about 400+ blocks (but <500). Would arcing this bring up the prob? Howie ------------ Category 5, Topic 25 Message 14 Fri Oct 16, 1992 C128.JBEE [* Sysop *] at 02:26 EDT Actually, deARCing it will bring out the problem :) Stuff it in a native mode partition, ARC it, and then try deARCing it. No go. ------------ Category 5, Topic 25 Message 15 Fri Oct 16, 1992 CBM-ED [e.g.bell] at 08:37 EDT I *may* be able to shed some light o this believe it or not. I don't have the hardware you are having the problem with, but I have worked extensively w/Chris' code and I know how he does the dissolves. He compresses the file portions of the REL file only, and dissolves it only. The side sectors are created during de-compression. I would suspect that this is the problem. I don't remember all of the specifics of the code, but since you only mention REL files, I bet this is where the problem lies, since direct access and sector tracing are done, and very possibly also validity checking for them. I remember this because I had to figure a way to identify a 1581 from a 1541 and act accordingly. Does this sound like it might make sense? ------------ Category 5, Topic 25 Message 16 Fri Oct 16, 1992 C128.JBEE [* Sysop *] at 13:25 EDT Yes ------------ Category 5, Topic 25 Message 17 Fri Oct 16, 1992 B.VRIELING1 at 21:23 EDT Steve: While I won't say that you WON'T see UNZIP for the C128 under CS- DOS, I will say that you won't see it soon (from me at least :D). My first project for the Pack originally was an UNZIP, but I got sidetracked. The 'start' I made turned into ZIPVIEW. Right now, I have a number of other things going, and don't know when I'll have time to dedicate to a time consuming project like UNZIP. We'll see. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 18 Sat Oct 17, 1992 CMD-DOUG at 00:11 EDT Well, if Direct Access commands are attempted to another partition, then that could cause a bit of a problem. Our DOS requires that you at least physically enter the partition to OPEN the direct access channel. You can leave after that and any commands sent to the associated channel will go to that partition, but trying to OPEN a direct access channel for one partition while located in another will definately cause a problem. Not sure if that is what is going on or not? ------------ Category 5, Topic 25 Message 19 Sat Oct 17, 1992 B.VRIELING1 at 17:11 EDT Doug, When you say "physically enter the partition to OPEN the access channel", if you mean changing to it using the CP command before an OPEN, then no, CS-DOS does not do this. It is Rx-DOS "unaware", and the native version does not send any CMD style commands at all. I'm losing a lot of respect for ARC128's REL file handling, the more I hear about it. "Direct access" commands to build the side sectors? That doesn't sound very generic. Does it know about the 1581 super side-sectors? (Ed?) What about RAMDOS's way of handling REL files, and the fact it does not allow "direct access" commands? I think I'll run a few tests. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 20 Sat Oct 17, 1992 CBM-ED [e.g.bell] at 18:11 EDT CS-DOS predates the 1581, doesn't it? One way or the other, I didn't work w/CS-DOS, but rather ARC 2.30/2.50 and its REL file handling. However, I don't think there were that many changes involved in that particular module, tho I could be wrong. And I can't answer wrt the REU either, but Chris wasn't doing many upgrades by the time the REU etc. hit the scene. He supported it, I know, but there were not that many versions of CS-DOS. I do remember getting baptized into REL files writing the ARC module for BellTerm, and that is the way it is done, namely disolving the file as a normal file... oops! You know what... before I get my foot any farther in my mouth, Bruce, I better check the code. It *may* be that I am remembering wrong about some of the details. The file would *have* to be opened as a REL file for the type to stay the same. I think what it is is that the file is opened as a REL file allowing DOS to build the side sectors, then the side sectors are traced to build the pointers. Bet that is it... because I distinctly remember the included calculations to determine record size... guess I will have to look at my source code now and see, but I think I'm very close not... I didn't mean to put CS-DOS down in that regard. Just shed light on why this dissolve problem may be happening in a particular situation on CMD hardware. ------------ Category 5, Topic 25 Message 21 Sat Oct 17, 1992 C128.JBEE [* Sysop *] at 23:00 EDT Either way there will be newer versions of ARC128 in the near future :) that support all the new devices and flexible enough for unforseen items. ------------ Category 5, Topic 25 Message 22 Sun Oct 18, 1992 HOWIE-CBM at 16:34 EDT JBEE, I did as suggested, and ARC128 had no prob with *my* REL file. It along with others were arc'ed, the originals erased, and then the arc dearced, all within RL's partition 9, a 2 Meg native partition. Interestingly the REL file was (and is) 344 blocks. The ARC shrunk it down to an amazing 17. When I first saw that with a List, I figured something went wrong. However a Verify was OK, and the REL exploded back into 344 blocks, when the ARC got extracted. As I said.... I don't recall any prob with ARC and RAMLink. :) Howie ------------ Category 5, Topic 25 Message 23 Mon Oct 19, 1992 C128.JBEE [* Sysop *] at 00:07 EDT Maybe the file isn't big enough. I know there is a problem expanding large files because I tried to use it instead of just file copying them to a disk. Better to use a 1541 than (5) 1581s to back up a database :) ------------ Category 5, Topic 25 Message 24 Tue Oct 20, 1992 B.VRIELING1 at 21:21 EDT John/Ed/Howie, Maybe the problem only occurs when you get into super side sectors... at what point will DOS use them? The cut-off point slips my mind at the moment. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 25 Wed Oct 21, 1992 CMD-DOUG at 00:21 EDT Super-Side-Sectors are ALWAYS used on 1581 and CMD Native. Size makes no difference, though the benefit of them is to allow for more records. ------------ Category 5, Topic 25 Message 26 Wed Oct 21, 1992 HOWIE-CBM at 00:39 EDT Bruce, I am not exactly sure (translation: I do not know) how they work. However, the progran I have lets me expand the REL file to several times the size that I have it at now. I quess I could make it larger and try it again. Only prob, is it would be pretty empty. Even the one I use now must be pretty empty if 344 blocks collapsed down to 17 or whatever for the arc. Howie ------------ Category 5, Topic 25 Message 27 Wed Oct 21, 1992 C128.JBEE [* Sysop *] at 03:08 EDT It cuts out at 400 blocks or so (no channel error and/or illegal blk) if I remember right. ------------ Category 5, Topic 25 Message 28 Wed Oct 21, 1992 HOWIE-CBM at 13:41 EDT JBEE, Here's another test I ran on the RAMLink: [All activity was done within a 2 meg native mode partition] [1] Had the program expand its REL file, so that what had been 344 cbm blocks, was/is now 1,252 cbm blocks. [2] Continued to run the program, accessing the REL file, and all seemed okey. [3] Ran ARC128 on the REL file, including a few others into the ARC as well. [4] Curiously a verify of the ARC, while reporting everything as OK, displayed that the original REL was 1,240 blocks, and not the 1,252 that a DIR showed. [5] Erased all the original files from the partition. [6] Unarced the ARC. The REL file re-showed itself in the directory at its original size, 1,252 cbm blocks. [7] Ran the program that accesses the REL file, and all seemed to be okey. Two things to note, however: [A] Although the REL was expanded to 1,252 blocks, I did not bother to add more data into the file, so for all practical purposes it was an empty shell. Do not know how (or if) this had any effect on this test. [B] During the unarcing of the REL file, RAMLink's error light lit, and then went out. I do not know why. Does not seem to have done any harm. So, as I've said, I do not believe there is a prob with arcing REL files under RAMLink's RL/DOS. Howie P.S. All the files that went into the ARC correctly picked up today's date, as their arcing date, and I didn't do a thing! :) ------------ Category 5, Topic 25 Message 29 Wed Oct 21, 1992 CBM-ED [e.g.bell] at 18:06 EDT WRT the phenomonenal compression, Howie, remember much of a REL file is pad characters to make for uniform length. Part of the ARChive compression is RLE, which can do some dramatic compression under that circumstance. ------------ Category 5, Topic 25 Message 30 Sat Oct 24, 1992 S.CRAIK [Steve] at 13:30 EDT Hi Bruce, I'm wanting to set up SETRAM from CS-XTRA3.SFX. I am a little confused.. by this: setram 16,1 poke 4864,0:poke 4865,0 stash 2,4864,bank,0 I want to have the rdir at setram 43,3 and poke in the related pokes for various files up in the second 512k such that if I use some other program that happens to use the REU.. such as Desterm, Dialogue, Zed128. Anyway, I'm hoping that both can co- exist in the REU without either getting corrupt. You know..but listing again.. I have ..128D Ramlink (2)1581s Swiftlink. RAMLink has the REU as a 2048 DACC currently. The REU is only a 1.5meg'r I overlapped for some reason (something to do with the way RAMLink was doing something and wipeing out the entire RAMLink and setting it to its DEFAULT setup.) Anywho.. let me know what you think/know. Steve Craik ------------ Category 5, Topic 25 Message 31 Sun Oct 25, 1992 B.VRIELING1 at 14:54 EST Steve, Re: How to set up SETRAM. My AUTOEXEC is set up slightly differently. First of all, I did read in the docs somewhere about those "two pokes and the stash" which you listed. They are there to initialize the ramdisk to EMPTY. They create a (0,0) link in memory, and then stash this to the start of the ramdisk. My AUTOEXEC does not use them, and I have never had any troubles. Try yanking them, and see what happens. Other than that, simply add the SETRAM 43,3 to your AUTOEXEC, and you should be flying. Don't forget to put the SETRAM program on your *CS-DOS BOOT DISK*. That's where CS-DOS looks for it upon bootup. One thing I am concerned about... you mention that you want the "RDIR" at 43,3 and you want to "poke in the related poked for various files in the second 512K". I'm not sure what you are up to. Here's what I do: I have a 2 meg REU. I let CS-DOS use the second 512K in the REU, which starts at bank 24 (16 inside C128 + 8 to skip the first 8 banks in the REU). To do this, I use a SETRAM 24,X (X is number of banks I want to use). Now, the first 512K is freed up for use by other programs. Desterm and BBR for example, use the first 512K and leave the CS-DOS ramdisk alone. It exists peacefully between 512K and 1 meg. Did I answer your questions? ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 32 Mon Oct 26, 1992 HOWIE-CBM at 17:35 EST Bruce, That is one terrif way for using the custom expanded REU!! I wonder if you also have its 2nd Meg reserved for a specific use? (The closest I get to the way you have things setup, is having CS/DOS use the upper banks of a regular 512k REU. Unlike yours, however, this often gets overwritten.) Howie ------------ Category 5, Topic 25 Message 33 Mon Oct 26, 1992 B.VRIELING1 at 19:56 EST Howie, Re: Using the 2nd meg in the reu Actually, it doesn't get much use. :) I keep another CS-DOS Ramdisk up there, for testing purposes. But I have found few uses for it. Note that when I used a SSV cartridge, I used the extra memory a lot for copying diskettes. But I haven't seen 64 mode in months now... I stay exclusively with the 128 (and, ahem... the IBM). ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu ------------ Category 5, Topic 25 Message 34 Tue Oct 27, 1992 HOWIE-CBM at 16:36 EST Thanks Bruce! Howie ------------ Category 5, Topic 25 Message 35 Wed Nov 11, 1992 S.CRAIK [Steve] at 01:42 EST Hi All, Do you remember? I was asking about CSARC1750 & CSARC and why I couldn't I list the directory by using ARC128/L command when looking at a CSARC1750 created archive. (I could list an *.ARC directory of a CSARC created arc.) Well, I looked at a HEX DUMP of two IBM.ARCs I created one w/CSARC- 1750 and one w/CSARC. Both just archiving the same file. It turns out that I only found a difference within the first 32 positions of the HEX dump. (actually several within those 32) first the CSARC1750 created *.ARC always inserts a "$41" in position 3. CSARC doesn't have that. Later on within that first 32 position at position $17 (CSARC) and $18 (CSARC1750, this would be position $17 also except CSARC1750 inserted that "$41" earlier thus pushing the rest of the bytes up one) anyway, there is a difference between the two files at that point. It turns out that position $18 (CSARC) & $19 (CSARC1750) are (for this particular archive) different as well. Checking things a little further.. I created two more files archiving the another file (lesser size than the first attempt) but, The "$41" is there.. but the $17 needn't compare with $18 of CSARC- 1750 (like before) but this time $18 was the same as $19 of CSARC1750. Any ideas why the $41 char/byte creeps in there w/ the 1750 version. Or why there are differences at position $17 and $18 of the other ver. also the sometimes additional differences at the next byte. Both seem to have their files extracted by an IBM DE-ARC'r ..OK! Just that on the CBM side of things ..why can't I look at the directory of one and NOT the other? Steve Craik ------------ Category 5, Topic 25 Message 36 Wed Nov 11, 1992 C128.JBEE [* Sysop *] at 23:16 EST Beats me! Probably won't be able to get an answer since Chris is out of it. Sometime in 93 we will be redoing all the modules and taking care of the little buglets that have popped up. Most likely just a programming error. ------------ Category 5, Topic 25 Message 37 Sun Nov 22, 1992 B.VRIELING1 at 17:33 EST This topic has sort of turned into a "general CS-DOS" topic, so I thought it would be a good place to ask the following programming question. I'm working on a new CS-DOS program (whose function will remain hush hush for now ;D) whose program code is too large to fit into memory after I've allocated buffers and stuff. So, I've broken down its components into modules, each a separate program performing a specific task. For example, the first one named MASTER opens the input file, and then shells out to SLAVE which "does its thing" on a portion of the input file (reading in some input along the way), and when it is done its section, returns to MASTER. After examining the next little piece of input from the file, MASTER shells out to MISTRESS (I'm making these up as I go along....) which reads in 12 bytes from the input file, "does her thing", then returns to MASTER. The "shelling out" is a simple dynamic keyboard load ie. I print a line on the screen like: e:mistress ... and dump a chr$(13) into the keyboard buffer to execute the line. This works perfectly. The problem comes with keeping the input file OPEN. There are 2 things to contend with here: 1) When you RUN a program, BASIC closes all open files (or, more accurately, sets the count of open files to zero). I can overcome this by simply poking a "1" into the open files count (in BASIC), as BASIC never actually CLOSES the file on disk. I can then continue to read from it. 2) CS-DOS closes all files upon termination of a CS-DOS program. Sigh. This one is the pig. The closing is not a simple "set open files to zero". It is actually a systematic closing of the open files on disk. In other words, it is closed. Period. What I'm looking for are suggestions on how to keep a disk file open "secretly". CS-DOS is either going through its list of open files and closing them, or is doing an OPEN15,X,15;CLOSE15 on each drive. I need a way to OPEN a file, and not have a CLOSE have an effect on it. And, I don't want it drive specific. Hmmm.. If I have explained myself clearly enough, and you see a possible solution, I would really appreciate a note. Thanks! ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 38 Sun Nov 22, 1992 CBM-ED [e.g.bell] at 20:08 EST Bruce: BV> What I'm looking for are suggestions on how to keep a disk BV> file open "secretly". CS-DOS is either going through its list BV> of open files and closing them, or is doing an BV> OPEN15,X,15;CLOSE15 on each drive. I need a way to OPEN a BV> file, and not have a CLOSE have an effect on it. And, I don't BV> want it drive specific. Hmmm.. I am not that familiar w/the inner workings of CS-DOS, but I do know that the CLSE routine is vectored at 796/797. Maybe you could intercept that and disable it during the time that your routines are running, restoring it at the end? I haven't given this a lot of thought, but maybe the best way to avoid the undesirable effect is to just prevent it? ------------ Category 5, Topic 25 Message 39 Mon Nov 23, 1992 B.VRIELING1 at 22:20 EST Ed, Bingo! That's exactly the type of inspiration that I was looking for. If I would have thought of that this weekend, I would have saved about 3 unsuccessful hours writing a SPAWN procedure for CS- DOS... sheesh. Thanks! :) GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 40 Tue Nov 24, 1992 R.KNOP1 [Rob Knop] at 02:16 EST Do the various secondary programs (e.g. "mistress") have an independent function? In other words, would the user have a reason to run mistress independently of master? Or, will mistress only be run as an overlay for master? If the latter, perhaps it would be simpler just to use real overlays. I.e., make master a "resident module" (do you detect my GEOS VLIR vocabulary here?), and have slave and mistress load to a different address. Master can load the other files directly when needed, and you never have to deal with the issue of closing the input file. -Rob ------------ Category 5, Topic 25 Message 41 Tue Nov 24, 1992 CBM-ED [e.g.bell] at 08:30 EST Bruce: BV> would have thought of that this weekend, I would have saved BV> about 3 unsuccessful hours writing a SPAWN procedure for CS- BV> DOS... sheesh. Everyone once in awhile even a blind squirrel comes up with an acorn. I would have bet you had already done that, but I know from experience that is not always the case. Now you have everyone wondering what it is you are doing. ------------ Category 5, Topic 25 Message 42 Tue Nov 24, 1992 CBM-MARK at 21:47 EST Master, slave , mistress??? You guys been in the 'Rose Garden' too often! ▐▐Mark▐▐ ;D ------------ Category 5, Topic 25 Message 43 Fri Nov 27, 1992 B.VRIELING1 at 19:10 EST Rob, "Mistress" would never have been run separately. "Master" is always the first program to be run. However, Master and Mistress are each VERY large programs (well, their own data sets are anyway :D), and can't co-exist in memory at the same time. So, therefore the need for the shelling. Ed, Thanks for the tip. And no, I'm not telling what I'm up to yet. ;) Mark, I thought the terminology accurately described what I was up to. Something would have been missing had I simply called them A, B, and C. :)) ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15