Hi All

You know how the customer does a big port of the arev application from a novell server to an NT box, and goes home at 4:30pm without testing it? Well it's broken.

We get FS102 fatal error writing REV12345.LK pathname\CL_TABLE read only table.

Could this be down to user permissions in NT? I was able to create a new folder, copy files into it, delete stuff off the parent folder then copy files back (which did not fix the problem). I didn't check execute or update. I can't check the SYSTEM user access but I asked the LAN guy to do that.

I checked the REV dos file properties, and it is not a read only table there. And neither is the .OV file.

I think they've installed the new linear hash service. NLM Stats says there are no linear hash files attached but I guess thats cos it is a Novell not NT thing. WHO says All networks and a arev serial number etc. I can't remember how to check the linear hash is working from AREV.

I hope they've applied the NPP bit to the arev.exe. As I recall it wouldn't work at all without that. From TCL: NTSERIAL is an unrecognised command (bad feelings about this).

The lanpack says only nine users and I suspect they are supposed to have more users than that.

Any ideas on how to check what is going on would be appreciated.

Scott.

Hi Scott,

Try, exiting AREV, at the DOS prompt

ATTRIB -R *.*

in each AREV volume. Then restart AREV.

Otherwise, it's security permissions not enabling Read Write Modify Create and Delete of files in the Revelation volumes.

Let us guess - another great server configuration triumph. Is it true that EDS and MINDA are the same organization in S.A. ?

The Sprezzatura Group

World Leaders in all things RevSoft

Hi Sprezz

Hmm, I suspect that MINDA is better organised than EDS. The rest of what I want to say in here is edited because EDS is bigger than me. But in this case I doubt the cause is EDS. More likely country town syndrome.

So meanwhile back at the bat cave, they're fairly sure that the SYSTEM has the right file permissions and that the user group that the users belong to has full control as well…

And I still think it is the file permissions. Like they missed a folder or something.

Scott

Hi Sprezz and all

I went through the folders with a dos

dir /AR /S

The only file that came up as read only was arev.exe and it hadn't been changed since 1995 (if I remember right after a fire drill). So I was wondering if the application of the Network Performance Pack had taken properly.

Again I ask - should NTSERIAL work from TCL (AREV 3.12)? Cos it doesn't.

By the way I was able to create a file from DOS in the Data folder (the one where the tables are that we get the FS102 for), I edited it, saved it, and then deleted it, did everything except execute it.

No problems although the first time I tried to delete it, it said it didn't exist.

I've asked the lan tech guy to back up the arev.exe, then set it to not read only and then run the NPP install again.

That's my straw.

Next straw is phoning the local rev' rep…

Scott

Scott,

The deletion issues are due to write caching. Call Sprezzatura's Australian Office tomorrow a.m. and we'll try to assist further.

We have seen instances where the NPP install fails, especially if run from an unusual directory path. In such instances the REV*.* files are not updated properly, but the All networks driver loads.

After install you should have a new file in your REVBOOT directory: LH2.DLL . It is an overlay file to work with the non-networking driver. You'll also need to set the REVPARAM file in each path that contains a REVMEDIA.LK - it can be edited and contains one line only -

SERVERONLY=1

Further, you should ensure they have actually started the NT service on the server. You'll need to ensure they installed it under Administrator logon privileges.

AREV.EXE should *not* be marked read-only for use on Microsoft networks. If it is read-only, then your user licence upgrade process would have been affected.

The Sprezzatura Group

World Leaders in all things RevSoft

Problem solvered.

I told tech guy to roll back to their old Novell server until the thing was working on NT. I thought if we built the NT from the bottom up we wouldn't have any discrepancies in the file permissions.

tech guy obviously took to reading the install instructions, and there was some stuff he didn't tell me, like about the REVPARAM file.

His story was that if he had

ServerOnly=1

then the app worked on Novell and didn't work on NT

when he changed it to

SERVERONLY=1

then the app worked on NT

So he's pissed at me for not telling him about the uppercase but happy that the thing is working now.

My story is, he never told me there were any revparam files let alone that he'd been messing with them. I didn't see any in the folders I looked at although I wasn't exactly looking for them. I didn't expect to see any because I'm the only person that has ever set them up around here and I didn't set up any for that site.

I guess we were both guilty of thinking it wasn't important enough. Next time I will know to check for revparam files.

My experience with revparam files and the case thing is that "true" and "false" don't work ("1" and "0" do) and spaces around the "= sign are ok but that it's never been case sensitive before.

In fact my stuff has below in it.

ServerOnly=1

and when it isn't right I cannot start the app at all. Where as this problem was they could do everything except update. Go figure.

Or maybe thats a difference between the NLM 1.5 and the NT/Win2K service 2.1. Hmm, but my client at the other site with the NT member server has the revparam files how I set them up. They ported from Novell to NT unchanged. So I still feel like I'm missing some pieces of this story.

Scott

Hi All

Just in case anyone is still out there… I'm getting a 400km trip north starting before sparrow * on Monday.

]

We thought the system was working, it was even, until the "data" got copied across from the live novell system to NT again. After some assorted reinstalling stuff, it was found to be broken again. Of course half the revparam stuff had disappeared again.

BTW

The northern revparam looked like

SERVERONLY=TRUE

my southern revparam that I know is working around the corner is

ServerOnly=1

so there you go.

I now get a road trip to figure out how to make it go properly.

Scott

Hi Scott;

You might try this scenario: Get the system back to where it is working like before. Then

Get everyone off the system

Stop the LH services

Rename or remove the REVPARAM files

Copy the system

Rename or replace the REVPARAM files

Start the LH services.

I hope this helps

Joe Doscher

Rev Tech. Support

800-262-4747

Hi All

Summary:

It works now, try installing the NPP again.

There is a question about how to verify LH is working properly at the bottom.

Detail:

What they had was an NT server with a large hard disk with two shares on it, one called APPS and the other called DATA and these were mapped to two separate network drives on the users login scripts. I gave SYSTEM full control to the parent hard disk, which precipitated all the way down. I gave "everyone" full control to both the shares. In fact "everyone" already had full control to the apps. I figure they can remove the "everyone"s later. They had some weird domain group access as well, and I went through and made sure that the domain groups like administrators had full control. There was a bit of a problem where the customers are divided up into two groups and only one group actually had access to the data folders. I don't think this made much difference either as I was getting the FS102 error while logged in as administrator before and after messing with the permissions.

Step 1: I wrote a couple of bat files to place or remove the revparam files.

I set up the seed revparam file to contain

ServerOnly=1

By the time I got to the site yesterday, the LAN tech guy had set up a mixture of revparams with

SERVERONLY=TRUE

SERVERONLY=1

SERVERONLY=TRUE

ServerOnly=1

etc. I'm sure this made no difference.

Step 2: I ran the bat file to remove all the revparam files and checked the result by doing a dos command dir revp*.* /s from the top of each network drive (apps and data).

Step 2.1 I backed up the arev folder on the NT system by making a copy in another folder. Just in case. I didn't need this in the end.

Step 3: I then got the linear hash service turned off.

Step 4: Then I got everyone off the novell server arev system

Step 5: I set the arev on novell to non networking (arev lanpack)

Step 6: and then copied across the arev directory (apps) from the Novell system to the NT system.

Step 7: I set the arev on the novel back to ipx after but we never let the customers back in to novell

Note I never did step 5 for a different client site migration, but I was combining Joe's instructions with the NT LH install instructions and some migration instructions from the knowledge base network how to

here

Step 8: Then I put the revparam files back while the linear hash service was still off.

Step 9: Then I got the linear hash service turned back on because I figured thats the order I did things at the other client site - linear hash on server first, NPP on arev.exe second.

Step 10: Then I installed the NPP using the AREV.EXE on the NT system. Eg arev lanpack etc.

Step 11: I set the network to all networks (not all networks thunk).

Step 12: I ran a test to see if this had worked. Yippee its working.

Step 13: I copied the data folder from the Novell System to the NT system into a backup folder. From the backup folder I copied the most recently updated rev files ie the ones changed since we first set up the NT copy of live, into the NT Data folder. And tested record updates again, still working… I progressively went through and retrieved all the recently updated rev files on Novell and pasted them into their respective folders on NTon the NT. I was very careful not to overwrite anything from the arev.exe folder again.

System is now working on NT.

Step 14: went around all the workstations and pointed them at the NT system.

Step 15: Got a problem on one workstation running DOS, enabled extra memory in autoexec.bat or config.sys (I forget)

DEVICE=C:\DOS\EMM386.ESE RAM 4096

I have a feeling that the all networks being used the first time around may have come from the originally installed arev.exe on their system and not the new NPP that should have been installed. When I asked the lan guy to re-install the NPP the first time, this must have fixed the system the first time, then I think he promptly broke it by copying across the Novell system again (to get the latest live files) overwriting everything in the NT folder with and including arev.exe and the LH files. And not re-installing the NPP again at this stage. It is possible that all he did was change the network type. And the old all networking would not have matched the LH service that was installed on the NT server.

I think that the symptom of the LH/NPP not working was that we could update the arev tables that were on the same network drive as the arev.exe but we could not update the arev tables that were on the other network drive (FS102). This felt like NT permissions but infact was probably all-networks NPP 2.1 not installed. I have written this great long essay because I still might be wrong about what actually fixed the problem. I didn't have problems like these at the other client site. Then again their whole system apps and data was on the same network drive.

Is there a TCL command to test whether the LH/All networks is functioning properly? Like NT_STATS? Note this didn't work when we had the error and I forgot to test it after the system was working. Likewise NTSERIAL as a TCL command. I forgot to try variations too like NTSTATS and NT_SERIAL. I figure that we wouldn't get FFFFFs in the SYSTABLES records either. I was able to check at the other client site using Open Insight. I'd be quite happy to setup our own code/program/TCL command to test if you/revelation would kindly post what to check.

Thanks

Scott, LMS

Hi all

Dos problem fix:

should be EMM386.EXE, not what wobble fingers typed.

I got one other weird problem when restoring data. Based on my selection by date modified, in one folder I copied REVMEDIA.LK without its friend *.OV - even though only one of them had been changed. got an error like FS107 with REVMEDIA and a helpful message, so I copied its partner across and all was working again.

Scott

Scott,

Are you certain it's working properly now?

The Sprezzatura Group

World Leaders in all things RevSoft

Hi Sprezz-mu

Nothing's certain but death and taxes.

We did hang around for a bit to see if it keeled over with everyone in. They haven't called for help today.

There are opportunities to bust it when we start cleaning up the permissions. And I noticed that the bat file that starts up the arev doesn't have /XM4096 in it. So we can break it when we fix that too. I had fixed it, and then overwrote it when I was starting over with the arev folder files. Then forgot to put the XM back in. So I know how the Lan tech does it.

And the lan tech is still there.

Maybe they've had a power failure.

Scott

I am currently running an Reelation 2.1 application on a windows NT 4.0 server. Trying to move the application to a Windows 2003 server.

I copied the AREV directory, Installed Liner Hash service, installed NPP 1.4. When exiting out of the application I get an error FS102.

Fatal Error writting COMMAND.STACK*COLOR.USER in file LISTS

Error while writing data

REV21046.LK is a read only file ( I checked, it is not )

Also getting similar messages when trying to run a RLIST

Does anyone have any ideas what is causing this?

Thank you.

Hi all

Got the FS102 on another site, and fixed by re-installing the all networks driver (v2.1) directly on the console.

With the network admin protesting all the way that he'd done this already - I kept saying lets do it again.

Full instructions.

1. Stop and set to disable LH service (through the services menu)

2. reboot server - LH service does not start up.

3. run the LH remove thingy in the C:\revsoft\NTservice folder from DOS (net admin told me about that thing).

4. rename revsoft folder (or delete it)

5. re-install LH Service but don't check the boxes to start it.

6. restart computer - LH service starts automatically.

Now we can log into our system

View this thread on the forum...