chad@csd4.csd.uwm.edu (D. Chadwick Gibbons) (12/04/89)
I had recently loaded SimulTask, version 2.0, I believe, onto my AT&T System V 3.2 386. It appears to work well enough, but my attempts to use an existing LAN in DOS mode did not work, as I assumed. I believe it would be possible to take advantage of the network since the ability to use tcp/ip with the same hardware exists. However, I assume my problems are because of the nonexistance of a device driver for the network communication board, which happens to be a standard microsystems ARCNet communications board, attached to a Novell NetWare SFT 2.15 file server. I've contacted sms about doing something along these lines, and they say it is possible, although I was given little more information. Has anyone ever attempted to use a networking facility under SimulTask, and have had any success?
fmcgee@cuuxb.ATT.COM (~XT6561110~Frank McGee~C23~L25~6326~) (12/17/89)
In article <1315@uwm.edu> chad@csd4.csd.uwm.edu (D. Chadwick Gibbons) writes: > > I had recently loaded SimulTask, version 2.0, I believe, >onto my AT&T System V 3.2 386. It appears to work well enough, >but my attempts to use an existing LAN in DOS mode did not work, >as I assumed. I believe it would be possible to take advantage of >the network since the ability to use tcp/ip with the same hardware >exists. However, I assume my problems are because of the nonexistance >of a device driver for the network communication board, which >happens to be a standard microsystems ARCNet communications board, >attached to a Novell NetWare SFT 2.15 file server. I've contacted >sms about doing something along these lines, and they say it is >possible, although I was given little more information. Has anyone >ever attempted to use a networking facility under SimulTask, and >have had any success? I believe someone else tried to set this up through a DDA device (Direct Device Access) and got it to work but gots lots of corrupted packets (like 50% of the packets were corrupted). There are a few other (albeit limited) options; I believe HP and Novell have announced a port of Netware to Unix Sys V Rel. 4.0. Presumably it will become available when HP gets their port of 4.0 done which should be sometime next year. I'm pretty sure it was HP; it might have been another large OEM. Presumably since it will run on Unix Sys V 4.0 it will run on most (if not all) vendor's implementations of 4.0. In addition, If you are running StarGROUP software over StarLAN networking cards, there is an item known as the "Simultask NETBIOS Client Interface Program." It provides an Installable Emulation Module (IEM) that will allow the normal, MSDOS-based StarGROUP client driver to talk to the Unix-based StarGROUP driver so that you can talk to NETBIOS networks over the StarLAN card. Over the same card, you can be running the MSDOS server, RFS, CU, etc. There is a limitation though; it only supports up to 8 clients running at once maximum, and most of those would have to be over console virtual terminals. For directly attached terminals, we only recommend that you have two people at a time running Simultask with the NETBIOS program running (ie, two people on terminals and one on the console). You can really feel it performance wise when it's running too; we had it set up on a 6386/25 (25 Mhz 386 platform) with about 6 or 8 users coming into the machine - performance was pretty bad. But if you stick to the guideline of 2 terminals plus the console, it works okay. From the client program, you can connect to any StarGROUP server on your network. For instance, from a console virtual terminal I can sysadmin an MSDOS server in the next room. It also provides file and record locking to Simultask applications if you've been looking for that. Presumably, you'd have to link to an MSDOS server to share the disk areas, but it could be made available to Simultask users through the NETBIOS program. Pre-requisites - o 1 or 10 Mb StarLAN card o Starlan Network Program (Unix device driver for the card) o Simultask o MSDOS 3.2 or 3.3 (no official support of MSDOS 4.0) o Simultask NETBIOS Client Interface Program o StarGROUP Unix-based or MSDOS-based Server Program The only thing you need the MSDOS Server Program for is for the client software installation diskettes. You don't need to actually install the Server Software. But if I were setting up the system, for flexibility I'd install a Unix-based MSDOS Server too. For those that don't understand the distinction between StarLAN and StarGROUP, StarLAN refers to the hardware portion of the product, and StarGROUP refers to the software products that run over the hardware. But the StarLAN/GROUP products probably don't help you since you mentioned NetWare. You can only run the StarGROUP product with StarGROUP protocols. Hope this gives you a few ideas, -- Frank McGee, AT&T Tier 3 Complementary Channel Sales Support attmail!fmcgee
les@chinet.chi.il.us (Leslie Mikesell) (12/17/89)
In article <4373@cuuxb.ATT.COM> fmcgee@cuuxb.UUCP (Frank W. McGee) writes: >In addition, If you are running StarGROUP software over >StarLAN networking cards, there is an item known as the >"Simultask NETBIOS Client Interface Program." [...] >It also provides file and record locking to Simultask >applications if you've been looking for that. Presumably, you'd >have to link to an MSDOS server to share the disk areas, but >it could be made available to Simultask users through the >NETBIOS program. Do you know if this will fix the problems encountered when trying to run WP5.0 (or other network-aware programs) under VP/ix? If so, does it work locally or do you actually have to have a DOS network link to another machine? Also, does it allow print jobs to be automatically despooled when the printer device is closed or do you still have to pop up the stupid VP/ix menu? For the record, I'm in an office with 3B2 and 386 (unix) machines running the Starlan DOS server program. Most of the users have PC's with the client software. I use a 386 (unix) for development and a console for administration. I keep most of the other machines RFS mounted into mine and usually have several remote logins using the virtual terminals. All this works just fine, but I'd like to also be able to access the files via DOS under VP/ix on the same machine. Currently, there are enough quirks in VP/ix that I have to keep a second machine in my office just to run an occasional DOS program and know that it will work the same as when someone else runs it. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (12/27/89)
In article <4382@cuuxb.ATT.COM> fmcgee@cuuxb.UUCP (Frank W. McGee) writes: >[ various things about the AT&T NETBIOS interface to Simultask ] >Yes, this allows you to run "network aware" programs under Simutask. >It allows you all the NETBIOS services except for terminal emulation >over the network (this is planned to be fixed). How about things like netbios access to a mainframe gateway? I couldn't get this to work using REMOTE PC. >For instance, now you could run the LAN pack available for Dbase III >under Simultask. At the moment, I'm mostly interested in running the network version of WP 5.0 which seems to get some kind of error when running in the unix filesystem. It must have something to do with opening files with sharing allowed. >As I understand the printer problem you are are referring to, it >happens on applications that DON'T close the printer port after they >finish using it; this can be demonstrated by quiting the application >(ie, a forced close of the printer port). Can't imagine what the "FIX" >would be; app_mind_read (2) ? No, I haven't seen anything come out of the VP/ix spooler by itself unless you also exit from VP/ix. Perhaps you run your dos applications directly from unix so that when you exit the application you also exit VP/ix. >The problem you refer to also appears under every networking operating >system I've ever heard of, including StarGROUP software. But the starlan dos server will print when you close the printer port. For example "copy file lpt1:" works just fine under dos server, but doesn't come out under VP/ix. Likewise WP 5.0 printouts. Am I doing something wrong? I really can't imagine anyone getting useful work done when they have to pop up the VP/ix menu or exit their application for every printout. >If it's that much of a hassle, you can always just access the device >directly under Simultask and don't use the unix spooler. But then you >lose the ability to share the device. Ummm... most of my print jobs are uux'ed to another machine since I just have an ugly dot matrix locally. I don't think direct access will help much there. >Hope this answers your questions, Partly, thanks, but the real question is whether VP/ix itself is going to be fixed. I'm only marginally interested in being able to access other DOS servers. What I really want to see is netbios support under VP/ix alone. Connecting it to the DOS server is a nice touch but it should be an extension of the native support. Les Mikesell
georgemartin@hodgenet.UUCP (George H. Martin) (01/09/90)
In article <4420@cuuxb.ATT.COM> fmcgee@cuuxb.UUCP (Frank W. McGee) writes: > >>But the starlan dos server will print when you close the printer port. >>For example "copy file lpt1:" works just fine under dos server, but >>doesn't come out under VP/ix. Likewise WP 5.0 printouts. >>Am I doing something wrong? I really can't imagine anyone getting >>useful work done when they have to pop up the VP/ix menu or exit >>their application for every printout. > >Oops, spoke too soon. I tried what you said and you're correct. From >the MSDOS prompt, it looks like you have to a printer buffer flush to >get anything to print (by pressing ALT-SYSREQ M P). I'll look into >it, and see what I can find out. ... This is correct, per the "as delivered" Simultask arrangement. An alternative MAY BE to define a new LPT 0,1 or 2 device, which would require a parallel port that is not also being used by the UNIX lp demon (at least not at the same time). You would do this using the Simultask DDA facility. Now, that isn't directly doable by way of the "ddainstall" command, because the parallel ports are "fixed", by way of their entries in the DDA "control" file (my terminology), "/usr/vpix/etc/vpixdevs". If you view this file, you see the entries "PLEL0", "PLEL1" and "PLEL2". You'll also notice the interrupt vectors (only for PLEL0, which is the "MDA-display-card-resident printer port), and the start and end address, in addition to the "fixed" designation, and other fields for buffer addresses, etc. Enough background? What you would need to do to try this is: 1. Edit the vpixdevs file, to remove the existing parallel port entry for the port you want to use (port of the same address - conflicts between entries will not be permitted by "ddainstall" if the existing entry is for a "fixed" device). 2. Make a new DDA entry, using a new device name for the printer port, as you want to identify it (for the moment, let's call it "DOSLP"). Do this using the "ddainstall" command, not manually, because "ddainstall" also creates a virtual device in the "/dev" directory, using your chosen name (e.g., "/dev/doslp"). 3. Modify the vpix.cnf file for your Simultask session, to change the typical "LPT1 /usr/bin/lp 2>/dev/null" entry to be: "LPT1 /dev/(your dda name)" (e.g., "LPT1 /dev/doslp" ) NOTE: "LPT1" assumes that is what your software looks for. Use whatever name is expected by your apps (DOS). Your apps (and DOS, etc.) should be able to directly address the parallel port without any support from UNIX, which is what DDA is all about. Caveat: This is based on my memory of my own twiddlings of 3 months ago, and I wasn't actually replacing printer devices, but I was redefining one of my parallel ports for a COVOX voice synthesizer. The output of that device under Simultask was chopped up, when compared to its smoothness (voice quality) on my DOS Tandy 3000HD. So I undid my mods to vpixdevs, etc. and moved it back to the Tandy. This is not a reflection on ANY of the hardware. Rather, in some respects, the Simultask environment (specifically, the virtual 8086 mode) may not offer the same "real-time" responsiveness as the dedicated "real" mode (as under DOS on my Tandy). I SPECULATE that its due to either the fact that in the Simultask environment, interrupts are emulated, or that the virtual 8086 mode (386/25) is not as fast in "realtime" as my 286/8.(?) If any of this seems to be critical of Simultask or the virtual 8086 mode, you mistake my intent; I use this mode often for several DOS apps, and I'm well satisified. I would appreciate knowing whether this works for you (I didn't want to get into it on my machine right now). Also, if anyone can enlighten my as to the correct answer to the less-satisfactory performance of the COVOX stuff under Simultask, or can confirm either of my suspicions as to the reason, email>me). -- George H. Martin uunet!hodgenet!georgemartin Homer Dodge Network Systems, Inc. +1 201 454 3333