Administrator's Guide: PC section

This chapter contains information for the Administrator for the PC/Windows versions of the software.

Like the administrator's Guide; the information here is only needed in special situations where your needs require further customization of EDA.

The EDA command line

The command line used to invoke EDA may take a number of forms, namely; the example below uses the 16 bit DOS name of the program, i.e. EDA; however the same applies to EDA32 and EDAWIN.

   (1)   EDA

   (2)   EDA ?

   (3)   EDA option1 option2

   (3)   EDA /p<prof>

(1) The first call is the usual way to invoke EDA for standard operation. All other uses are reserved for special situations or perform a single, spezialized function.

(2) EDA ?, is intented as a way to tell the user about EDA or, if needed at your site, to inform the user what to do in order to use EDA correctly. Basically EDA ? checks the EDALIB directory for the presence of a file named edahelp.ini and, if found, displays its contents on the screen. If it cannot be found, the user is told that no information exists. EDA ? displays the file and returns to DOS, i.e. the EDA program is not called.

(3) The EDA command line, in addition to calling the EDA program may be used to communicate information from outside to the EDA program. The command line invoking EDA less the program name is available within EDA as Z$, i.e. you may analyze Z$ and use it for your own purposes in an EDA profile, macro or init file. Please note that Z$ is a result variable for many commands, therefore save it or use it before entering a command producing a new Z$.

Portions of the command line may be used in a profile file for any purpose. When typing:

EDA param1 param2 ... param9

You can refer to param1 with the $$1 symbol, param2 using $$2 up to $$9. Each parameter is a separate 'word' (separated by blanks or commas). There are quite a number of things you could do with this:

Use an eda.bat file to build up a suitable environment for your needs, including user access control (see the USR$ directive in the Administrator's Guide.
Set up different projects, using different profiles.
Executing specific commands using the XQT$ directive, e.g. you could set up something like XQT$$$1. Then when you call EDA by typing EDA TOOLBOX you would go directly into the EDA toolbox.
There are no limits to your imagination... See the Administrator's Guide for additional details.

EDA /P

The EDA command line may contain a different profile file root (the name must always be profile.eda) as a last option starting with /P, therefore EDA /PA: will look for profile.eda on floppy A. With this feature you could construct a .bat file to call EDA, which first asks the name of a user or the type of data (s)he wants to analyse and then calls EDA with the appropriate profile. See below for additional information and alternative ways of dealing with profiles.

If EDA /p is isssued without a path name following the switch, all profiles will be bypassed, i.e. no profile file will be processed whatsoever.

EDA /i

(This option is no longer available; use /P to indicate a profile and make a .bat file or a shortcut for this).

Profiles

The Administrator's Guide contains a number of features (and examples) illustrating how you might set up your PC, especially for use in teaching environments, where many different people use the program, sharing a number of files etc.

As EDA may be used in a number of quite different settings, EDA offers a number of ways of specifying profiles. Note that this section deals only with a single problem, how to find the first profile, or more specifically the first profile.eda file (if a sequence of profiles are in use, e.g. system - group - user, the only problem is to find the first, as the first profile determines what further profile is to be processed.

Version 2.0 and 2.1 of the EDA program expected to find that profile in the c:\edalib\ directory, and with the exception of the /p switch on the command line there was not really an alternative to this.

With version 2.2 things are much more flexible, i.e. the location of that file can be installed or determined via a DOS variable. (Note that if you update from an earlier version, EDA will simply install c:\edalib\ as the profile directory root). The general rules for profiles are now as follows, i.e. EDA attempts to locate the profile file the following way:

If the /p switch is found on the EDA command line, the profile root specified is used (this takes precedence on all other rules in all cases). If the profile file does not exist, EDA does not look for further profile files (see above for more details on the /p switch).
If no /p switch is present, but if a directory root has been installed with the EDA /i option, EDA looks only in that directory for the profile.eda file.
If neither a /p switch is present nor a directory path installed, EDA checks whether a DOS variable EDALIB is defined, e.g. if a SET EDALIB=d:\soft\config\eda\ has been issued EDA will read the profile.eda file from that directory.
If no EDALIB variable is defined, or there is no profile.eda file in that directory, EDA checks whether it can find a profile.eda file in the directory where the EDA program and its overlays are located.
If it cannot be found there, EDA will look into the LIB directory just below the EDA program directory.
If it did not find a profile.eda file up to now EDA will finally check whether the current directory contains a profile.eda file. If none can be found, EDA gives up and decides that no profiles are to be processed.

Note that the EDA library name is available as $$L symbol in profiles, i.e. you may use it to build directory names which include the edalib path name, e.g. to store specific information in a directory below the directory where the profile is located.

The EDALIB name is also available as string variable D$. EDA also generates a ELB= record stored as the first line in the session profile.

The EDAWORK DOS variable

In many situations it is quite convenient to run EDA always from the same directory, e.g. in order to keep EDA related rawdata, print files etc in the same place. You can of course write a batch file EDA.BAT changing to that directory before calling EDA, but EDA can do that for you: Define a DOS variable EDAWORK containing the directory to which you want to change before calling EDA, e.g. SET EDAWORK=d:\workdir\. (Note that EDA will also change the current drive, if needed).

Whenever an EDAWORK variable is found EDA defines the $$R tag for the profiles, as well as string variable E$.

EDA archive files and directory files

The EDA archive files (saved by PUT) are made read-only and are locked/unlocked by EDA as needs arise. The same is true for the directory files (where the information on files is stored, i.e. the file designated by the DIR= directive in the profile). If you need to repair/patch etc. one of those files you must remove the read-only attribute first (ATTRIB command or similar).

Network version

Please read the additional document supplied with the network version of EDA.