Up one level (RSS page) Up two levels (Moto index) Back to Home

An overview of a common problem in the Radio Service Software (RSS)

Editors note: The article "Background Information II" mentions the RSS "read-only" problem in passing, and without much detail.
This article expands on that...

From an email to repeater-builder....

Recently another mailing list had a comment thread that ended up being a read-only file permissions problem.
Here's the gist of it:

The original posting:

I have a Radius mobile radio with the following model number: D43LRA77A5BK, I can't read
the radio with any of the Radius RSS I have. The BK at the end of the model number is
throwing me for a loop all other Radius radios I have ever seen usually end in AK.
Any suggestions on the proper RSS for this radio?

- - - - - -

A few comments on the above:

• While the problem mentioned above was with a high band Radius LRA series (essentally a MaxTrac in Radius clothing and with Radius firmware), and the person that resolved the issue had a identical UHF radio, this problem is relevant to almost all the RSS lines. Many variations of such "file not found" messages have been seen, sometimes with the exact file name (or a suggestion thereof) mentioned.
  
  
• The original poster correctly pointed out that all the model numbers in the MDF file were version "A", i.e. the last two letters were all "AK" and there were no "BK" versions to be found, so he assumed, incorrectly, that the error he was getting was due to the exact model number not being found in the file.
  (A side note: Some of the RSS is written to use an underscore ( _ ) as a "don't care" marker character in the MDF files so that the RSS won't care about that particular character in the model number. This is most commonly seen in the hardware revision descriptor but it could be used anywhere. In the particular RSS mentioned above the the MDF in RADMBL has actual "A" letters present in that spot in all entries and the executable code is specifically written to ignore that character.)
  
  
• Eventually the poster reported that his exact error message was "Model definition file not found". Someone replied with a few reasons / suggestions as to why this might happen. He responded that the MDF file had been marked READ-ONLY and fixing that allowed his RSS to properly read the radio. Since RSS could not open the MDF file in read / write mode, it incorrectly reported that the file was not found.
  
  
• The base cause of this problem is the original RSS programmer that wrote the program to open the MDF file in the read / write mode instead of in the read-only mode. Due to the shoddy programming in most RSS, ALL of the RSS files need read / write privileges, even though it makes no sense to have most of them that way.
  
  Certainly the ARCHIVE and BACKUP directories (and the files in them) need to be writeable, as does the CFG file, but the executable program files (EXE and OVL) and help (HLP) files really should be able to exist as read-only files.
  
  Yes, some versions of RSS have a function to update the MDF file, so in that case the file might need to have read / write privileges in the file system, and to be opened with write privileges during the update process only, and at no other times. A proper install method would have set the file as read-only, then the update routine would have set it to read / write, updated it and restored it to read-only. Personally, I've never had to update an MDF file, basically because all the programs I use are for essentially unsupported equipment that has been discontinued and no one sends out new model entries to the file any more; they would just send out an entirely new program instead.
  
  
• From one point of view the "File Not Found" error message is correct for a file that can't be opened in the desired mode, whether it's there or not. However, a properly written program would first see if the file exists (and if not, report it in a useful format, something like "Cannot find FOO.MDF in C:\MRSS\MAXTRAC\"), get its current privileges information (i.e. read-only, or read-write), and then determine if and how it can be opened, thus producing a correct and useful error message. And of course all properly written programs would report the file name that fails to open the way they want - none of this "file not found" crap that does not include the file path\file name information that many vendors (including Microsoft) resort to). If you are going to insist on opening a program data file in read / write mode (like when updating it), then an error message something like "MDF file cannot be opened in read-write mode" would be much more useful.