#: 17777 S1/General Interest 22-Mar-93 19:11:11 Sb: #17761-#How come? Fm: Carl Kreider 71076,76 To: Ken Flanagan 75460,2514 (X) It got pushed down the interrupt stack. I am trying to get to it again. There is 1 Reply. #: 17780 S1/General Interest 23-Mar-93 03:35:52 Sb: #17777-#How come? Fm: Ken Flanagan 75460,2514 To: Carl Kreider 71076,76 (X) Have you made any decisions on it. Ie. default compression, what the max bit compression will be, keeping attributes, etc? There is 1 Reply. #: 17831 S1/General Interest 30-Mar-93 19:12:49 Sb: #17780-How come? Fm: Carl Kreider 71076,76 To: Ken Flanagan 75460,2514 Yep. Keeping attributes, 13 bits max, still lzw compression. No point in changing that.... it wouldn't be ar anymore. #: 17778 S1/General Interest 22-Mar-93 19:12:04 Sb: #17764-How come? Fm: Carl Kreider 71076,76 To: Pete Lyall 76703,4230 (X) Ah..... CTRL O.... I'll try to burn that in. I can't look it up in time ;) #: 17787 S1/General Interest 23-Mar-93 20:35:44 Sb: #message 13904 Fm: fred kohlhepp 72300,3553 To: sysop (X) Your welcome message talks about archival software; refers to message 13904. This message can't be located in the message strings. What's up? Fred There are 2 Replies. #: 17788 S1/General Interest 24-Mar-93 06:53:06 Sb: #17787-message 13904 Fm: Dan Robins 70007,3264 To: fred kohlhepp 72300,3553 (X) Fred, CompuServe gives each forum a certain number of 'message slots', and in this particular case....enough messages have been entered since that particular message was posted that it was replaced by newer ones. Maybe it's possible that one of our forum users saves these messages and can repost it....but there's no guarentee of that. Sorry it isn't around to refer to! Dan #: 17790 S1/General Interest 24-Mar-93 07:25:25 Sb: #17787-message 13904 Fm: Steve Wegert 76703,4255 To: fred kohlhepp 72300,3553 (X) Fred, Sorry for the confusion. 13904 has hit the bit bucket. In short, it attempted to put to rest a rather long winded discussion on the use of a 'unofficial' version of the AR archive utility. The author of AR asks that folks continue to use the official 1.2 version (found here in our libraries) until such time that he releases an update. Hope this clears up the mud .... Steve #: 17830 S1/General Interest 30-Mar-93 17:46:37 Sb: Rsdoscopy Version 1.00 Fm: PHILLIP TAYLOR 72067,3430 To: All A new program I uploaded today Rsdoscopy Version 1.00. This is utility that fully menu driven, and will allow users to copy files from Rsdos to Os9 and files from Os9 to Rsdos. Its located in File Area #10. Also for those users who are looking for Bulletin Boards running on a Trs-80 Color Computer, you call the Big Dipper at 703-573-5606, or The Fido Exchange at 703-573-2246 running on a Ibm 386sx with Remote Access. I am the author of Rsdoscopy Version one, and the file name is Rcopy1.Ar Phillip Taylor #: 17798 S3/Languages 25-Mar-93 14:59:05 Sb: #C++ compiler available Fm: bye 70324,261 To: all Does anyone know if there is a C++ compiler available for OS-9000 now? We will be starting a major software project shortly and I would like to start with a C++ compiler. Thanks in advance -- Thad There is 1 Reply. #: 17803 S3/Languages 26-Mar-93 09:46:31 Sb: #17798-#C++ compiler available Fm: Pete Lyall 76703,4230 To: bye 70324,261 (X) I believe the GNU compiler supports C++, but we're not using it at the moment. Pete There is 1 Reply. #: 17822 S3/Languages 29-Mar-93 08:48:20 Sb: #17803-#C++ compiler available Fm: bye 70324,261 To: Pete Lyall 76703,4230 (X) We are just looking into OS-9000, can you tell me what GNU stands for? Who markets it? Thanks for the info! -- Thad There is 1 Reply. #: 17823 S3/Languages 29-Mar-93 09:15:52 Sb: #17822-#C++ compiler available Fm: Pete Lyall 76703,4230 To: bye 70324,261 (X) GNU is a sort of humorous, recursive acronym standing for: GNU is Not Unix It is distributed by the free software foundation, and it is freeware. Pete There is 1 Reply. #: 17826 S3/Languages 29-Mar-93 16:50:52 Sb: #17823-C++ compiler available Fm: bye 70324,261 To: Pete Lyall 76703,4230 (X) Thanks, you have just enlightened one of the ignorant. -Thad #: 17832 S6/Applications 31-Mar-93 04:51:23 Sb: Attachment to IBM system Fm: Hugo Rytz 100116,3720 To: All I'm involved in a project, were we need to attach an OS9 system to a IBM system with token ring and the IBM SNA network protokoll. The OS9 system should maintain a LU6.2 session with peer to peer comm unication with the host. Does somebody have experience with connecting an OS9 system to an IBM host or know a supplier of SNA network software and/or hardware for the OS9 system? #: 17818 S7/Telecommunications 28-Mar-93 08:29:43 Sb: #17564-#terminal help Fm: Kevin Pease 70516,1633 To: Bill Dickhaus 70325,523 (X) Bill I have a hack that will eliminate the keyboar problems. It is two jumpers. It connects the keyboard handshake line There is 1 Reply. #: 17819 S7/Telecommunications 28-Mar-93 13:16:48 Sb: #17818-terminal help Fm: Bill Dickhaus 70325,523 To: Kevin Pease 70516,1633 Kevin, Is this a problem with specific keyboards? I'm planning on replacing my keyboard soon, is there a chance it will work OK? Could you tell us what the hack is? Thanks. -Bill- #: 17802 S9/Utilities 26-Mar-93 04:31:07 Sb: #Disk Fragmentation Fm: Mcgennity-M 100136,3276 To: ALL Does anybody know of an efficient RBF disk de-fragmentation utility? I am an engineer working with OS9 for CDI production. I am constantly having to backup-format-restore my SCSI drives because some of the files that I have to manipulate must use contiguous disk space (for emulation etc). The files are in the order of 650 Meg and so backing up to tape is very time consuming as you can appreciate. Any help with this would be much appreciated. Malcolm. Futuremedia Interactive. United Kingdom. tel: 0243 555000 fax: 0243 555020 There are 2 Replies. #: 17816 S9/Utilities 27-Mar-93 16:51:16 Sb: #17802-Disk Fragmentation Fm: Bob van der Poel 76510,2203 To: Mcgennity-M 100136,3276 (X) Malcolm, I'm sure that Ole Hansen will let you know about a program I believe he sells...however, you might be better off just avoiding file fragmentation if you can. A could of suggestions: 1. Pre-extend the file allocation for what you believe the file's max. size will be when you create the file. As long as when you close the file you are not at the EOF, the extra sectors allocated will not be returned to the system. 2. If you have a fragmented file and you have contiguos disk space for it, just copy that file. If I recall correctly, COPY will do a pre-allocation. After the copy, just delete the old and do a rename. I wrote a utility awhile ago for 6809 which did that. It is avail in lib10 as 'unfrag.ar'. #: 17825 S9/Utilities 29-Mar-93 16:33:15 Sb: #17802-Disk Fragmentation Fm: ole hansen 100016,3417 To: Mcgennity-M 100136,3276 (X) Hello Malcolm Try to contact 'Galactic Indutrial' Mr. Paul Dayan. He is selling a program called DiskSqueezer from 'Ark System USA'. That program will reorganize your disk and collect files so they get contigous(if possible). If you are using that big files, why don't you increase the allocation-size so you don't get that many small segments ?? Here is the phone-number to Paul: (+44) 913848343 regards ole@anelec.dk #: 17776 S10/OS9/6809 (CoCo) 22-Mar-93 13:23:52 Sb: WD1773 COCO disk chip Fm: Timothy J. Martin 71541,3611 To: all If anyone is looking to replace the WD1773 controller chip in their COCO Disk controller Cartridge, they are available through a chip broker in California named "Jerome Industries". Phone number is 805-527-5893, ask for Susan Laughler (sp?). They sell only to businesses, and need a $50 dollar miniumum. The sell the WD1773-PH for $17.50 each. #: 17782 S12/OS9/68000 (OSK) 23-Mar-93 08:08:17 Sb: #17736-#PCF Fm: Bert Schneider 70244,427 To: Bob van der Poel 76510,2203 (X) Bob, Are those DMODE options used with you PCF drivers/descriptors or with the OSK ones? I have been trying to assemble the files myself but to no avail! Thanks! Bert There is 1 Reply. #: 17786 S12/OS9/68000 (OSK) 23-Mar-93 18:28:35 Sb: #17782-#PCF Fm: Bob van der Poel 76510,2203 To: Bert Schneider 70244,427 (X) The dmode I posted here is just a dmode of the pcf driver which came with the update stuff (I think I got the update stuff here?). Remember, when you access PCDOS disks you do a "dir /pc1" or "list /pc1/foo"...just forget about the OSK desc. at this point. There is 1 Reply. #: 17793 S12/OS9/68000 (OSK) 24-Mar-93 21:33:00 Sb: #17786-#PCF Fm: Bert Schneider 70244,427 To: Bob van der Poel 76510,2203 (X) I didn't get the object code for pc1, just the source. So far I have been unable to get it to work. I assemble and link the file(s) but I can't iniz pc1. Do you have a working pc1 file for 5.25" 40 track DD drives? If so, could you email yours? I don't think it will take too long! Thanks! Bert Schneider (o) (o) U \___/ There is 1 Reply. #: 17801 S12/OS9/68000 (OSK) 25-Mar-93 22:40:23 Sb: #17793-PCF Fm: Bob van der Poel 76510,2203 To: Bert Schneider 70244,427 Okay, they are in your mailbox. #: 17781 S12/OS9/68000 (OSK) 23-Mar-93 08:04:14 Sb: #17721-PCF Fm: Bert Schneider 70244,427 To: Mark Griffith 76070,41 (X) Mark, Could I get your descriptor values (or file) for the 3.5" drives? I could probably change mine for 5.25" drivers. Thanks! Bert #: 17783 S12/OS9/68000 (OSK) 23-Mar-93 13:32:55 Sb: #17767-#Subroutine modules Fm: Graham Trott 100115,1075 To: Bob van der Poel 76510,2203 (X) Bob -- >>> At this point, however, it looks like it'll be easier for all (including the folks who will end up writing there own interfaces) to have this done via a front-end which interprets mouse data, etc. and inserts it into the keyboard stream for ved. <<< Another possibility is to have the mouse interface written as a separate stand-alone process with a defined data module interface. All the editor needs to know is the name of the mouse module (could be in an environment variable) so it can fork it. Advantages of this approach are 1) there are no side-effects mixing mouse info with keyboard input and 2) the data module can contain fields that time-stamp mouse events, allowing double-click or inactivity detection, mouse acceleration and so on. The editor is relieved of the need to handle all this real-time junk. Timing gets a bit imprecise when everything has to feed through stdin. -- GT There is 1 Reply. #: 17792 S12/OS9/68000 (OSK) 24-Mar-93 19:31:36 Sb: #17783-Subroutine modules Fm: Bob van der Poel 76510,2203 To: Graham Trott 100115,1075 (X) Yes...data modules and standalone co-routines are a good idea. Guess that's what's so neat about OS9...so many ways to do so many things. Pity we can't convert the rest of the world. #: 17775 S12/OS9/68000 (OSK) 21-Mar-93 18:40:59 Sb: #17774-#MM/1 boot ROM Fm: Bob van der Poel 76510,2203 To: Mark Griffith 76070,41 (X) Well...yes I did the obvious . But to make sure I'll check again. First off, I have the file OS9BOOT on HD0. To make sure it is okay I just did an ident. All is okay. Next, I fired up DED and examined LSN0. At $15 it shows $01 $24 $9c. So, the boot is registered. I not that the size of the bootfile is listed as 00 00. But, that is true on the floppy too...so I assume that the size is ignored. Hmmm, it'd have to be since the boot is 108K and there are only 2 bytes for the size. A dir -e shows that the the 'sector' for os9boot is 1249c. So, things appear okay in this department. BTW, when attempting to boot the drive light for HD0 does not show any activity. Also, it makes no difference if this is a cold boot or if I just hit RESET. I've left it for a few minutes thinking that maybe it is waiting for the drive to come up to speed, but no difference. So, what do I test next? There is 1 Reply. #: 17779 S12/OS9/68000 (OSK) 23-Mar-93 02:56:15 Sb: #17775-#MM/1 boot ROM Fm: Mark Griffith 76070,41 To: Bob van der Poel 76510,2203 (X) Bob, > So, what do I test next? You might try going into the init module with moded and increase the cold start retry count. Run moded on the bootfile and step down through until you see an entry called "coldstart 'chd' retry count" and increase the number there. Mine is set to 50, but you may need to make it higher than that. If that doesn't work, I'm at a loss for what to try next. Perhaps someone else here with one of those ROMs will be able to help more. /************* /\/\ark ************/ There is 1 Reply. #: 17785 S12/OS9/68000 (OSK) 23-Mar-93 18:28:32 Sb: #17779-MM/1 boot ROM Fm: Bob van der Poel 76510,2203 To: Mark Griffith 76070,41 (X) I'm starting to think that the ROMs might be broke. I don't think it is a retry problem in init. From what I can see the drives just never get accessed...I assume that the ROM routine would cause the LED on the HD to at least blink. I swapped the ID numbers on my harddrives (I have a Quantum LP105S and a Maxtor 7120SCS) but the same result. Any thoughts on this will be appreciated. If someone happens to know of some ROM offsets I can have a look at... #: 17784 S12/OS9/68000 (OSK) 23-Mar-93 13:36:47 Sb: Bridging ARCNET LANs Fm: David Briggs 100113,1203 To: ALL I have a customer running OS-9/NET on ARCNET at two sites, one on each side of a river. They would like to connect them together... Can anyone suggest a good way to bridge the LANs, perhaps over a leased line? What problems should I look out for? Thanks for any assistance. David Briggs Vector Networks (UK) +44 827 67333 #: 17791 S12/OS9/68000 (OSK) 24-Mar-93 13:54:13 Sb: #NFM Serial Line Driver Fm: David Briggs [Vector] 100113,1203 To: ALL Does anyone know of a serial line driver that can be used with the NFM to connect two OS-9/NET networks over a leased line? I am trying to find a way of linking two networks that are separate, but connected by a twisted pair cable with lots of spare pairs. Any ideas? Thanks for any information. David Briggs Vector Networks (UK) +44 827 67333 There is 1 Reply. #: 17799 S12/OS9/68000 (OSK) 25-Mar-93 18:46:01 Sb: #17791-#NFM Serial Line Driver Fm: ole hansen 100016,3417 To: David Briggs [Vector] 100113,1203 (X) hello David. What type of uart are you using for the serial NFM?? There is available serial NFM-drivers for MC6850,MC68681 and Z8530. You could contact Mr Paul Dayan at Galactic Industrial Phone: (+44) 913848343. He might help you. regards ole@danelec.dk There is 1 Reply. #: 17815 S12/OS9/68000 (OSK) 27-Mar-93 15:26:30 Sb: #17799-#NFM Serial Line Driver Fm: David Briggs [Vector] 100113,1203 To: ole hansen 100016,3417 (X) Ole, Thanks for the reference. I don't know the type of UART. I will have to find out! Do the drivers you mention come from Paul Dayan, or are they from somewhere else? Thanks again. David Briggs Vector Networks (UK) +44 827 67333 There is 1 Reply. #: 17824 S12/OS9/68000 (OSK) 29-Mar-93 16:22:22 Sb: #17815-NFM Serial Line Driver Fm: ole hansen 100016,3417 To: David Briggs [Vector] 100113,1203 (X) Hello David. They are in the NFM-portpak we have recieved from Microware. regards ole #: 17800 S12/OS9/68000 (OSK) 25-Mar-93 21:28:45 Sb: #Bigger read/write buffer Fm: William F. McGill/CA 73177,3433 To: All Can anyone tell me how to increase the size of the system buffer associated with the read() and write() commands in C 3.2? I need to copy a large file, and it seems the system buffer size is rather small. It takes about 4 times as long to copy the file using a read() followed by a write() than it does when I just use the OS9 copy command, specifying " -b=64k ". I've read all the manuals, and OS-0 Insights implies that it is possible to increase the system buffer size, but I haven't found any way to do it. Any ideas? Bill There are 3 Replies. #: 17804 S12/OS9/68000 (OSK) 26-Mar-93 09:49:07 Sb: #17800-#Bigger read/write buffer Fm: Pete Lyall 76703,4230 To: William F. McGill/CA 73177,3433 (X) In any case (copy included), the system buffers (actually driver buffers) are usually fixed. Copy is using the same mechanism (i.e. read(), write()). Try maintaining a large buffer in your application data space, and reading large chunks until you fill it. Then do a single write(). Pete There is 1 Reply. #: 17805 S12/OS9/68000 (OSK) 26-Mar-93 10:16:14 Sb: #17804-#Bigger read/write buffer Fm: William F. McGill/CA 73177,3433 To: Pete Lyall 76703,4230 (X) Pete- Thanks for the reply. My application program is doing what you suggest; the input buffer is about 125k bytes and does a single read() to fill it. When the read() command returns, the program does a single write(). But this simple read() - write() loop takes several times longer to copy a file than when I use OS9's copy, with -b=64K (or larger). I hoped perhaps there way to specify this option in C. You say the buffer is actually a driver buffer. Is there a way to modify the driver to get it to use a larger buffer? Thanks again, Bill There are 2 Replies. #: 17808 S12/OS9/68000 (OSK) 26-Mar-93 18:17:15 Sb: #17805-Bigger read/write buffer Fm: Pete Lyall 76703,4230 To: William F. McGill/CA 73177,3433 (X) Only if you have sources, which is usually not the case. Pete #: 17811 S12/OS9/68000 (OSK) 27-Mar-93 05:15:23 Sb: #17805-#Bigger read/write buffer Fm: Mark Griffith 76070,41 To: William F. McGill/CA 73177,3433 (X) Bill, > Thanks for the reply. My application program is doing what you suggest; > input buffer is about 125k bytes and does a single read() to fill it. You may have to play with the buffer size to get the most efficient copy speed. I have found that much smaller buffer sizes, like 32k or so, are faster than larger buffers. I have done a couple copy utilities that are faster than the Microware on. /************* /\/\ark ************/ There is 1 Reply. #: 17814 S12/OS9/68000 (OSK) 27-Mar-93 10:52:19 Sb: #17811-Bigger read/write buffer Fm: William F. McGill/CA 73177,3433 To: Mark Griffith 76070,41 (X) Mark, Thanks for the advice on buffer selection. I did play around with various sizes, and it appears that in this instance the larger the buffer the better. With a buffer of 1 Meg, copying proceeds at least as fast as the OS-9 copy command. The problem turned out to be interference from a higher-priority task, which was interrupting the data transfer and stealing significant amounts of time. By suspending the higher-priority task while copying, I was able to get a vast improvement in copying speed. Thanks for your help! Bill #: 17809 S12/OS9/68000 (OSK) 26-Mar-93 21:28:45 Sb: #17800-#Bigger read/write buffer Fm: Bob van der Poel 76510,2203 To: William F. McGill/CA 73177,3433 (X) WIlliam, I don;t think it is a buffer size problem. In read you just specify the buffer size as the 3rd. param. However, utilities like copy pre-extend the file to the full size...this means that only one file allocation system call is done...if you want to do the same use the create() call with the optional size specifier. There is 1 Reply. #: 17813 S12/OS9/68000 (OSK) 27-Mar-93 10:52:10 Sb: #17809-Bigger read/write buffer Fm: William F. McGill/CA 73177,3433 To: Bob van der Poel 76510,2203 (X) Bob, You are right, it wasn't a buffer size problem after all. A SCSI-bus analyzer revealed large gaps during which no transfers were taking place, even though the drive was ready to accept more data. The program is running in a multi-tasking environment; the problem is that a task with higher priority was also running, and the time allocated to that task accounted for the gaps in the data transfer. Setting D_MinPty to 2 and temporarily reducing the higher-priority task to priority 0 (to suspend it while copying) solved the problem. The program can now copy as fast as the OS-9 copy command. Thanks for your helpful suggestions. Bill #: 17810 S12/OS9/68000 (OSK) 27-Mar-93 02:56:16 Sb: #17800-Bigger read/write buffer Fm: Mark Griffith 76070,41 To: William F. McGill/CA 73177,3433 (X) Bill, > Can anyone tell me how to increase the size of the system buffer associated > with the read() and write() commands in C 3.2? You must be talking about fread() and fwrite(). There is no internal buffering on read() and write() since they are low-level functions: read (path, buffer, count) should explain it. You can make the buffer in your code any size you want. Actually, 32768 is the largest you can predefine. You need to use malloc() or something like that to make a larger buffer. Hope this helps. /************* /\/\ark ************/ #: 17806 S12/OS9/68000 (OSK) 26-Mar-93 12:47:42 Sb: #MM1 problem Fm: Hugo Bueno 71211,3662 To: All I've posted this to the Coco list, but thought I'd try here too... I finally got my MM1 this week. I ordered a 1 meg unit with IO board and 1 floppy drive. When the machine arrived, I booted it up and it worked fine. Today, I installed 2 more megs of ram and 2 floppy drives. I shorted both sets of pins on P7 (parallel to minibus) . Upon trying to boot the machine, it wouldn't. The screen was blue with OS9 68K Boostrap at the top. It then very quickly flashed a message on the screen. I think it said "boot failed, error status $0100". What does this mean? A bad boot disk? Unfortunately, I only got one floppy disk. I'm going to copy the full set from another local MM1 owner. I brought the machine back to it's original state and it gave the same error. Any help/ideas would be greatly appreciated. I hope this isn't a hardware problem. There is 1 Reply. #: 17812 S12/OS9/68000 (OSK) 27-Mar-93 05:32:41 Sb: #17806-#MM1 problem Fm: Steve Wegert 76703,4255 To: Hugo Bueno 71211,3662 (X) Hugo, I'm probably stating the obvious, but all cables checked for proper connection and pin 1 positioning? New drives strapped properly? Steve *- Steve -* There is 1 Reply. #: 17820 S12/OS9/68000 (OSK) 28-Mar-93 19:06:50 Sb: #17812-#MM1 problem Fm: Hugo Bueno 71211,3662 To: Steve Wegert 76703,4255 (X) Well, at this point I'd still like to figure out proper jumper settings for pad P7. I've been told on the COco list that the instructions in the IMS manual are incorrect. Are the jumpers supposed to be parallel or perpendicular to the minibus? Next, on the floppy drives. I guess that'll have to wait until I have a working bootable floppy. Hugo There are 2 Replies. #: 17821 S12/OS9/68000 (OSK) 29-Mar-93 05:50:51 Sb: #17820-MM1 problem Fm: Mark Griffith 76070,41 To: Hugo Bueno 71211,3662 (X) Hugo, > Well, at this point I'd still like to figure out proper jumper settings for > pad P7. I've been told on the COco list that the instructions in the IMS > manual are incorrect. Are the jumpers supposed to be parallel or > perpendicular to the minibus? The instructions are correct, you place the two jumpers parallel to the mini-bus. /************* /\/\ark ************/ #: 17828 S12/OS9/68000 (OSK) 30-Mar-93 05:32:33 Sb: #17820-MM1 problem Fm: Steve Wegert 76703,4255 To: Hugo Bueno 71211,3662 (X) Hugo, I see Mark has jumpped in on the jumper positions for you. On the floppy straps, it should be pretty easy. If you got the MM/1 with one floppy in it and it worked fine, then that one must have been strapped for drive 0. The other two need to be different. Also, make sure you're using the 3meg init module. That could be adding to your troubles. *- Steve -* #: 17817 S12/OS9/68000 (OSK) 27-Mar-93 16:51:22 Sb: Televideo 965 Fm: Bob van der Poel 76510,2203 To: All Does anyone know where I get a manual for a Televideo 965 tube? A phone number for televideo would be helpful. Even better...can I borrow a manual for a few days? #: 17827 S12/OS9/68000 (OSK) 29-Mar-93 19:24:33 Sb: Blarslib fixes Fm: Bob van der Poel 76510,2203 To: Steve Wegert 76703,4255 (X) Steve, seeing MH's fix for the link() function in blarslib.l reminded me that I had to make a fix to utime() awhile ago to get it to operate in the manner expected by a program I was porting from unix. I'm not sure which is the correct method...so I'll just post my revised source here in this message. Guess if the program doesn't work one way...one could try this. I don't have access to the proper docs, so I'm just guessing. #include #include #include #define NULL 0 int utime(file, timep) char *file; time_t timep[2]; { register int p; register struct tm *when; struct fildes fd; if((when = gmtime(&timep[1])) == NULL) return -1; /* changed S_IREAD to S_IWRITE bvdp 92/12/17 */ if((p = open(file, S_IWRITE)) < 0 && (p = open(file, S_IWRITE|S_IFDIR)) < 0) { return -1; } if(_gs_gfd(p, &fd, sizeof fd) < 0) { close(p); return -1; } fd.fd_date[0] = when->tm_year; fd.fd_date[1] = when->tm_mon + 1; fd.fd_date[2] = when->tm_mday; fd.fd_date[3] = when->tm_hour; fd.fd_date[4] = when->tm_min; if(_ss_pfd(p, &fd) < 0) { close(p); return -1; } return(close(p)<0) ? -1 : 0; /* changed!!! bvdp */ } #: 17829 S12/OS9/68000 (OSK) 30-Mar-93 14:06:47 Sb: NFM Serial Line Driver Fm: Graham Trott 100115,1075 To: David Briggs [Vector] 100113,1203 David -- You could contact Windrush Micro Systems at 0692 404086 - they are one of the few companies left in the UK with any dealings with ArcNet, and they provide custom solutions for OS-9 applications. To connect two ArcNet systems together transparently requires careful engineering and is probably not available in a standard off-the-peg product. -- GT Press !>