Please click the link below for your operating system to download the TSG SysInfo Utility. Click on "Save File" then double-click the file to run it. Copy and paste the report in your initial post. Windows 7 and later (downloads a file named tsginfo.exe) | Windows XP (downloads a file named SysInfo.exe)

ICL DRS300 dos system problem

3278 Views 35 Replies 3 Participants Last post by JohnWill, Jan 15, 2007

deanmorgan

Discussion Starter · Jan 9, 2007

Hi Guys, I am a bit if a beginner here and have a problem with my old DRS300 ICL dos based system. I am in the middle of replacing this with a pc system but unfortunately in the midst of changing the DRS300 has packed up.

When I say packed up I mean one of the drives.

I have already sent the hard drive (a miniscribe 8425 mfm) for data recovery but to no avail. They have said that it was corrupted and had bad media. This drive held the boot up and operating system. The other drive which hold the data in the DRS300 is ok but i cannot access the info to do anything with it. I can access the files using a floppy disc that has a type command in it but can only view the info.

Is there any way of interfacing a pc with this type of miniscribe drive to access the files and tranfer the data to a word or excel so I can at least print the data and have hard copies. All the files held on the drive are text files.

Any help would be greatly appreciated.

Thanks

Status: Not open for further replies.

21 - 36 of 36 Posts

JohnWill

· #21 · Jan 12, 2007

You need to bring the file over as a binary file, not a text file. Obviously, in spite of the assurances, some of the files are "not" text files. I see a bunch of hex "FF" characters in this file.

Try transferring the file with kermit as a binary file.

deanmorgan

Discussion Starter · #22 · Jan 12, 2007

I am probably sounding a bit stupid now but do you set the pc kermit part as binary somehow ? The only command I can use to send the file from my icl drs300 is the copy command or pip command.

JohnWill

· #23 · Jan 12, 2007

It's been many years since I used Kermit, but I know I transferred many binary files with it. There has to be a FAQ on the download site, right?

deanmorgan

Discussion Starter · #24 · Jan 12, 2007

Will have a look and see what I can find...... thanks for your help once again Jonh.

JohnWill

· #25 · Jan 12, 2007

Good luck, let us know if you get a binary file across. I'd like to take a look at that one, maybe we can figure out what format the file is actually in.

johnpost

· #26 · Jan 12, 2007

try this at the prompt to set binary transfer

REMOTE SET FILE TYPE BINARY

SET FILE BINARY

typing those two lines sets the receiving computer to accept binary
and the sending computer to send it, then do your transfer commands

since it's been lots of years since using kermit that isn't a fresh
recall

if the files don't go through as binary then also along with the
above two lines type

PARITY EVEN

that will keep the 8th bit from being stripped off if parity is set to none

See less See more

deanmorgan

Discussion Starter · #27 · Jan 12, 2007

Thanks John, I will give it a go..:up:

deanmorgan

Discussion Starter · #28 · Jan 12, 2007

Hmmm. Have tried the above but seems to make no difference. Have looked into the file transfer settings etc and they were already set to binary. Have tried changing it and various other combinations ie SET PARITY NONE (a kermit solution) but they seem to make no difference. Whichever combination I use I get the same file transfer information.

Could be the terminal I am trying to send it from I guess....not sure though. As I have said earlier I have only one command from my old ICL DRS300 which is the copy command. I don't know if I should be trying to send it someway different for KERMIT to recognize it differently. Am hoping to try and get hold of a guy that worked on our system a long time ago and see if I can jog his memory.

Am feeling I may not have much joy though.

johnpost

· #29 · Jan 12, 2007

deanmorgan said:
Hmmm. Have tried the above but seems to make no difference. Have looked into the file transfer settings etc and they were already set to binary. Have tried changing it and various other combinations ie SET PARITY NONE (a kermit solution) but they seem to make no difference. Whichever combination I use I get the same file transfer information.

Am feeling I may not have much joy though.

SET PARITY NONE

strips the 8th bit off and ruins the binary transfer

to transfer binary have parity set to any setting other than NONE

johnpost

· #30 · Jan 12, 2007

deanmorgan said:
Could be the terminal I am trying to send it from I guess....not sure though. As I have said earlier I have only one command from my old ICL DRS300 which is the copy command. I don't know if I should be trying to send it someway different for KERMIT to recognize it differently. Am hoping to try and get hold of a guy that worked on our system a long time ago and see if I can jog his memory.

Am feeling I may not have much joy though.

i'm confused about the above statement that the only command
you have on the old machine is copy.

with the kernit program running on both machines you
should have lots of commands available.

describe a bit more of what you are doing on each machine after
you have a command prompt.

deanmorgan

Discussion Starter · #31 · Jan 15, 2007

My laptop which I am using to trasnfer the info from has the kermit program running.

The old DRS300 mainframe ICL CPM-86 CDOS system is basically in-operative. The main drive has got corrupted which had the bespoke programs and operating system on. The mainfarme also had another hard dive which was used to store the data. This is still ok.

My only way of operating the system is by using a floppy drive that loads the config program onto the system. I am assuming this holds the config in its RAM. I can then use various other floppy discs that I have to access my other drive and view the files. These floppys would usually be used when building the system from scratch (they are standard ICL load discs (About 7 of them).

Therefore once I am into the system after loading the config file, I can type F:user 1 which will change the command prompt to 1F:. I can then type COPY or PIP or LOOK followed by the file name to access the data files. However the system operates all the commands from the A: floppy to be able to run.

I am hoping that makes some sense........

Shall try and expaling how I am running kermit.

PC has kermit running (Baud rate set at 75) capture text enabled. Connect pc to DRS300 monitor using a 25 way to 9 way lead. Type the COPY (file name) lst:

This then send the data to pc in a list format and into a notebook.

Then save the notebook to pc.

See less See more

johnpost

· #32 · Jan 15, 2007

kermit has to be running on both machines to do a transfer.

run kermit off of floppy in the cpm machine.

deanmorgan

Discussion Starter · #33 · Jan 15, 2007

I am probably sounding quite stupid now but do you know what version of kermit I would have to download. Once downloaded I will have to find a 5 1/4 floppy drive to copy it onto..That should be an experience in itself.

johnpost

· #34 · Jan 15, 2007

kermit can be found at

http://www.columbia.edu/kermit/index.html

cpm info is at

http://www.columbia.edu/kermit/cpm.html

good luck

JohnWill

· #35 · Jan 15, 2007

johnpost said:
kermit can be found at

http://www.columbia.edu/kermit/index.html

cpm info is at

http://www.columbia.edu/kermit/cpm.html

good luck

If you read post #9, you can see that all these links have already been posted. It helps to read the whole thread if you're going to post, so you'll avoid covering ground we're already covered.

JohnWill

· #36 · Jan 15, 2007

A commercial option is something like Laplink. In versions from serveral years ago, it was capable of uploading it's client to MS-DOS with no software on the DOS machine. It simply used the MODE and COPY commands to copy a bootstrap up to the MS-DOS machine, then you could transfer files. You might contact Laplink and see if that capbility is still in the product.

21 - 36 of 36 Posts

Status: Not open for further replies.