FDTSYM FDTSYM is a program which constructs symbol tables from FORTRAN (that is, F4+) listing and taskbuilder maps. Its outputs may be used in FDT (a FORTRAN debugger) or in DDT if the symbol table file is output. The command file format is FDT FDTFIL,STLFIL,GSDFIL=LISTFILE1,LISTFILE2,...LISTFILEN/MAPFILE where the FDTFIL file (a tree structured symbol table) must be present, and the STL (symbol table printable) file must be present if the GSD file is to be created. The GSD file is a pseudo .STB file for use by DDT. DDT may open this file and all FORTRAN symbols will be defined. To make symbol names legal, FORTRAN source statement numbers are changed to the form .nnnnn where nnnnn=the FORTRAN statement number. Internal sequence numbers are changed to form L$nnnn where nnnn is the ISN used. Note that these numbers may be replicated several times per program so DDT will find the first generally and these numbers are not always useful. However, all named arrays will be available by name and named commons, entry points, and other symbols will be available. Also, the letters chosen in the sequence numbers (compiler line numbers) are unique to the program, which will usually allow the correct program to be selected. The stl file must be consulted to see which sequence numbers are available; generally only executable statement numbers are. For use with FDT, the first 2 output files are all one needs and the GSD file (default extension is .GSD) may be omitted. Note further that the /LI:3 option of F4P is needed for the listfiles. Since internal sequence numbers (ISN's) are usually 4 digits or less, it is possible to identify modules with them. Therefore, FDTSYM associates a letter with each entry name, beginning with A for the first routine encountered (the main program) and proceeding through Z, then back to A. Then, internal sequence numbers are included in the .GSD file in the form "l$nnnn", where "l" would be in the range (A...Z) and "nnnn" is the FORTRAN line number (from the compiler, not the number you use to number a line). Thus, the fourth FORTRAN line of code in the main program would have a symbolic name of A$4 and the 150th would have a symbolic name of A$150, and so on. Numbered FORTRAN lines are not treated this way since there are no ways to prevent conflicts with user symbols or be unique without possibly throwing out some numbers. However, IF the FORTRAN statement number is less than 5 digits long, the module's characteristic letter will be placed after the statement number to help DDT disambiguate them. (By modifying NMUNG.MAC you can change these rules.) Thus, FORTRAN statement number 1234 in the main routine would become global symbol .1234A, and FORTRAN statement number 1234 in the first subroutine would become .1234B, and so on. However, FORTRAN statement number 25000 would become global symbol .25000 regardless of which routine it was in. (There isn't much one can do about that except to use the letter instead of the initial "." which might conflict with named variables.) No attempt to disambiguate named variables is made for the GSD file. If that fails to suit, find a method that pleases you and change NMUNG to produce a string of acceptable RAD50 that is unique. A method that might help would be to tack on $ (with := the letter for the module currently being handled) to the end of symbol names. However, that requires symbol names to be 4 characters long or less. Direct appending of the module letter is discouraged since it will very likely lead to conflicts with user-defined names and cause screwups. The .STL file printout will show the letters used, though, and ISNs may be used to access the desired locations. To handle overlays correctly, you should put a breakpoint in the overlay code ($ALBP2) and assemble DDT with X$OVL defined and store the overlay code breakpoint address in OVRBPT. This will cause DDT to refrain from putting instructions in the overlays on that breakpoint, so you can remove breaks and enter new ones at that point. The main reason for this feature is that it permits you to have breakpoints elsewhere and prevent DDT from damaging your program at an overlay load. If you use the OVRBRK feature, be careful not to remove any breakpoints in the root until you pass the break there (i.e., at $ALBP2). If you remove only breakpoints in the overlays and insert new ones, DDT will remember the instructions at the root correctly and re-insert them at the next break.