Why 3 different methods to pass the connnect parameters?

Actually, there are 4 (that I know of, there are probably more).

Brief History

My first attempt at writing GnuCOBOL/DB2 programs was on Windows and I followed the instructions found in László Erdős's contrib.

It worked.

I learned a lot and Thank You to László Erdős for creating that.

1 - The method it used was a ScreenIO pgm to prompt the user for the parameters and passed them to the program through the Linkage Section. It works but I wanted something "leaner".

2 - Then I looked at IBM's examples and that is where I saw the "ACCEPT" from the command line prompt method. It works, it was "leaner", but still required interaction with the user.

3 - Then I thought, use a CALLed program with the parameters embedded in it. CALL it and pass the parameters to the program to then pass those to the DB. GETDBID was created. It works without user interaction.

Then, per the "About" of this site and repository, I want to create GnuCOBOL/DB2 programs on Linux. I needed some help, got it, then posted a link to this site and the repository in the GnuCOBOL discussion area.

Simon Sobisch, who was very helpful fixing the problems I was having getting started, looked at the code I pushed to the repository.

One repeated "suggestion" (more like: Umm... I think you can do better.): Use a .env file.

I've done that before with Python but had no idea how to do that with COBOL. But, he also dropped some hints.

4 - Create a .env file, add code to the run script to export the parameters to environment variables, replace the "CALL 'GETDBID'" with "ACCEPT FROM ENVIRONMENT".

Which method to use from now on?

If the program doesn't require User Interaction, #4.

If the program needs User Interaction, #1 or #2 depending on the situation or maybe something completely different.

Method 3 was a good exercise to learn how to CALL programs but I am "retiring" GETDBID.

What about that code in the run script, why that?

There are many ways to Set environment variables in Bash.

Of all the methods listed there, it is a clean, readable method.

The .env file only contains 3 parameters of very short length and no spaces.

So it doesn't need to be anything too complicated.

• It is mostly understandable by people not that familiar with scripting.
• It only adds the parameters from the .env file.
• It doesn't require installing another application (shdotenv).

Some methods suggest to add "export" to each line in the .env file and source it.

To me, the .env file should be "just parameters, no commands", but if in the future it is required, there are other versions that would work.

A unset method is also listed but it is not needed.

The script is run in it's own child shell.

A child shell can't export variables back up to the parent shell, so the exported variables will disappear as soon as the script finishes and exits the child shell.