What Causes Load Error 198?
Modified Date: 6/7/2019
Load error: file "SYCONSEL"
error code: 198, pc=0, call=15, seq=0
or
Load error: file "SYACTCHK"
error code: 198, pc=4737, call=29, seq=0
A - From our experience, the most likely cause is a network problem. In the past, when we explained this to our users, we sometimes got a negative reaction from our users, thinking that we are just trying finger point and pass the buck. It turns out, as far as for the support cases that we were able to follow through, every single case of the "random" error 198 has been caused by a network error. We can confirm that because those random error 198 disappear after certain network components was replace. We are going to explain a little bit more about the nature of error 198, so you know why we have come to this conclusion.
What Is Error 198?
By design, a multi-user Elliott system has its programs installed on a network drive (e.g. M:\Elliott7). This includes both Elliott programs and data. Because there are so many Elliott programs written for various function (i.e. maintenance, inquiry, processing, report, setup..etc.) and Elliott programs are so large, our system dynamically loads the needed programs from a share drive as it goes. This avoid consuming unnecessary memory so Elliott can run in a efficient manner. To do so, it involves our system dynamically reading the program files (which reside in the *.LBR files) from the network share on the server.
In the above example, our program is trying to read the program SYACTCHK from one of the LBR files on the network share (i.e. under M:\Elliott7 folder and sub-folder). The server sends the program file through the network wire to the workstation. Before Elliott executes that program on the workstation side, our system will perform a checksum verification to see if the transferred program received is valid. If the checksum fails, then you will receive error 198 which means the received program file is corrupted and systems refuse to execute it. So the question is what causes the corruption?
Can a Corrupt Program File on The Server Cause Error 198?
Yes, it could. However, in that case, you will receive error 198 consistently when you go to certain areas in Elliott, instead of randomly. Furthermore, all workstations should receive error 198, instead of just one or a few computers. If that is not the case, then it disprove the corrupted program files on server share scenario.
For "random" error 198, our theory is the corruption take place from the point where the server send the program file on the share drive to the point where the workstation receive the program file. That is to say, the corruption took place during the network communication.
What Characteristic Points to Error 198 as a Network Error?
When you receive error 198 and it has the following characteristics, then it is a strong indication that this is caused by a network error:
- Error 198 only happens to one or a few workstations
- Error 198 happens randomly
- When you run Elliott on the server directly, error 198 never happens
As far as we know, error 198 can be caused by the following network components:
- A network switch (hub) - If the problem only happens to one workstation, try plugging the network cable for this computer into a different port on the switch. If this problem happens to all workstations on the switch, try changing the network switch..
- A network card - It could be the network card in the workstation or the server. If it is the network card in the server, then this problem would happen to all workstations, except it won't happen when you run Elliott on the server directly. Since most of the network card nowadays are builtin to computer motherboard, you may need to purchase a separate network card to install in the computer and disable the original one.
- Type of network cable - Try changing the network cable. For example, if you are running a Gigabit Ethernet, then you should use a Cat 6 cable. Are you using a Cat 6 or Cat 5 cable? This includes both the cables in the wall and patch cables between the plug and your computers. A Cat 6 cable has more twist per foot than Cat 5 cable result in lower resistance. As a result, Cat 6 cable is thicker and less flexible than Cat 5 and is more expensive. A Cat 5 cable is certified for 100M Ethernet, but not for Gigabit Ethernet. Some people use Cat 5 for a Gigabit Ethernet because it appears to be working. But it could lead to random network errors.
- Distance of network cable - What is the distance of your cables from end to end? For higher network speed (Gigabits), the maximum distance is 55 meters with 33 meters can be in high cross talk conditions. For lower network speed (100M), the maximum distance is 100 meter.
http://support.elliott.com/knowledgebase/articles/1186348-ping-test-to-isolate-inconsistent-load-error-198
How the Network Drive Is Mapped Can Cause Error 198
According to an Elliott user who experienced Error 198 on an RDS (Remote Desktop server), by mapping the drive using the FQDN or "Fully Qualify Domain Name" instead of the host name, Error 198 will be resolved. Here is the message for your reference:
We experienced a rash of consistent Load Error 198s on our RDS server. It would only occur when doing certain tasks, but it would occur consistently. Similar tasks that you would presume would throw the same error, didn’t.
Log out, log back in (i.e., establish a new, clean session) – continued to receive the same error when performing the same task.
We did one simple thing that seemed to have resolved it (it could be entirely coincidental, but with each passing day it’s looking more and more like a legitimate resolution).
Our drive mapping utilized by Elliott: We switched if from \\host\share to \\FQDN\share.
i.e.,
Net use N: \\SUS076\Programs
to
Net use N: \\SUS076.agta-record.com\Programs
When experiencing the “Load Error 198,” we would see immediate resolution simply by closing Elliott, shelling to a DOS prompt, issuing a NET USE N: \DELETE and then remapping using NET USE N: \\SUS076.agta-record.com\Programs. Relaunch Elliott (now running against drive mapped using FQDN), launching same task – no “Load Error 198.”
We’ve since updated our login scripts to reflect FQDN as opposed to just the host name – and so far no more 198s.
EMK