Guidelines for Posting to the Gams Mailing List

The Gams mailing list can be very helpful. There are a lot of people who are willing to use their free time to answer your questions. My advice: subscribe to the mailing list at ( and even if you don’t post to it, you can learn a lot of the questions and answers by others. If you post: don’t be afraid to ask a stupid question. The worst thing that can happen is that you get an answer like I once got. I asked a really stupid answer and got the answer: “Think”!

Tom Rutherford posted some nice guidelines for writing to the Gams mailing list. They might be useful for any mailing list you use. Here are the guidelines:

You will get more mileage out of the GAMS list if you adhere to a few guidelines (nothing official here, only my unsolicited advice):

1. Always take time to compose a clear statement of the problem from first principles.. Often times, the process of clearly explaining the problem is sufficient impetus for finding your own logical error.

2. If you have a problem specifically related to GAMS syntax or execution, write down the minimal operational GAMS program which illustrates your problem. Minimize the number of symbols you use in this program, but leave no descriptive field blank. Add comments to the program to the extent that they are needed to explain what you are doing.

3. If you are working on something more complex, write up the mathematics in a PDF document which explains what you are trying to accomplish.

4. If possible, upload a zip file containing the GAMS code and documentation to a web site (these are freely available everywhere these days my daughters tell me), and send a nice short message to the GAMS list, briefly indicating your field/problem type and an operational link to your zip file. (My policy, whenever posting a zip file, is to be sure that I am able to download and unzip the file on my own machine before asking someone else to try).

The advantage of using a zip file is that you can include all of the data files and perhaps a restart file which can save someone lots of time. The idea here is to provide the support staff with a “smoking gun”. We need to see precisely where the error occurs, and we need to be able to reproduce it on our own platform if there is to be a high probability of providing assistance.