A Guide for the SAS/C Compiler Consultant, Release 6.50

SAS/C Technical Support Service

The SAS/C Compiler Research and Development Division provides technical support for the compiler products. We strongly believe that h aving technical support integrated within the Compiler R&D division ensures that our customers receive support of the highest quality in the industry. SAS/C Technical Support services are provided free of charge to licensed customers.

When contacting the SAS Technical Support Division by phone, identify the question or problem as related to the SAS/C Compiler. SAS/C Technical Support consultants are available weekdays between 9:00 AM and 5: 00 PM., eastern standard time.

Guidelines for reporting problems and for gathering information that may be requested by a SAS/C Software consultant follow.

When to Call Technical Support

Some problem types and their symptoms are listed below.

Compiler-related problems. The compiler:
- generates an unexpected warning or error for correct source code.
- fails to accurately diagnose incorrect source code.
- generates incorrect object code.
- detects an internal error condition and exits with a CXERR.
- terminates abnormally, with or without an ABEND code.

COOL or LKED-related problems. The linker:
- reports unresolved references.
- terminates abnormally, with or without an ABEND code.
Run-time problems. A library or function:
- does not produce correct results.
- fails to diagnose erroneous conditions.
- produces unexpected warning or error messages.
- generates 12xx ABEND (abnormal termination) that is unexplained: for example, not the result of a call to abort() or a storage overlay.
- generates an unexplained ABEND.
- after upgrading to a new library version, an existing program fails to execute properly.

Contact the local Software Consultant prior to contacting SAS/C Technical Support. The Software Consultant may be able to quickly resolve a problem. But where assistance is required, the Software Consultant may contact SAS/C Technical Support.

Information Needed by Technical Support

Provide the following information to the Software Consultant before he or she calls to report a SAS/C problem:

your eight-digit site number. This number can be found on the first page of a compiler listing, and on cover letters accompanying your SAS/C product media. Th e number also appears on the Institute Program Products Master License agreement.
the product and version number. For example: SAS/C 6.50C, SAS/C++ 6.0 0C. The version is printed on the first page of the compiler listing and is included on cover letters received with the product. The version of the library can be obtained by using the =version run-time option. The version number is of the form n.nnx, where n is a digit and x is an alphabetic suffix.
operating system and version.
a phone or fax number or e-mail address, including any special contact instructions such as shift schedules.
a clear description of the problem, including its external symptoms, the results of your investigation, and the problem type (related to the compiler, the linker, or run time).
a clear description of the application structure, for example, single or mixed language, all-resident, multitasking, client/server, and so on.
diagnostic information, including:
- the exact text of any diagnostic messages. Many diagnostic messages contain dynamic substitution of parameters, based upon the existing conditions. It is imperative that we have the complete diagnostic message. This includes messages produced by SAS/C and the operating system.
- a library traceback if the problem involves an ABEND. "Reading a SAS/C Traceback" shows a sample traceback and explains how to interpret it.
- if it can be re-created, a code segment demonstrating the problem in a form that may be transmitted to SAS/C Technical Support.

Collecting Diagnostic Information

There are many diagnostic features within the compiler and run-time library to assist in the isolation of problems, and having this information handy saves time during consulta tions with Technical Support. The sections below tell you how to enable compiler, linker, and run-time diagnostics.

Isolating Code Generation or Compiler Problems

Ensure that the compiler option Warn (e nabled by default) is not disabled.
Enable the Hlist , Ilist , and Mlist options. These options cause the compiler to print, to the listing file, the complete header and macros processed by the preprocessor.
For code generation problems, enable the OMD (Object Module Dissambler).
If your site uses the SAS/C Cross-Platform compiler, use the -v (verbose) option to force full message output.
Provide a complete list of compiler options in effect when the problem occurs, for example, EXTNAME RENT OPTIMIZE DEFINE (any_user_defines). Options affect compiler behavior, and occasionally it is possible to circumvent a proble m by specifying different options.
Provide any traceback generated by the compiler, including the CXERR (Compiler Internal Error) message showing the line number and errcode of the error.

Isolating Link Problems

Unresolved external references are the most common problems related to the COOL, ILCLINK, or LKED programs. For all link problems, the following information is required:

input JCL or Command line syntax
COOL, ILCLINK, and LKED linkage editor control statements
expanded JCL or LOG for the command, with any generated error messages and listings
for COOL, the output generated with the ENXREF option enabled.

Problems reported as link errors sometimes result from source code or compiler details. You should have a detailed knowledge of the source code that generated the input OBJECTS or LOAD MODULEs, and be prepared to discuss the source code and its comp ilation with a SAS/C Software Consultant.

Isolating Run-time Problems

For a run-time failure that does not generate a traceback, enable the library run-time options =btrace and =warning. This will force the library to print all tracebacks and suppressed warnings, assuming the problem has not corrupted library control blocks.
If a dump is needed and the library is only producing a warning message, use the =quit , =warning , and =fdump run-time options. This will force the library to abnormally terminate after generating the warning message. You can then use the SAS/C Debugger to v erify that there are no logic errors within the source code.
For storage overlays or heap management problems, enable the library run-time option =storage to print a storage analysis report at program terminat ion. Then use the SAS/C Debugger, which is very effective at isolating storage problems. For details, see the "storage" command in the SAS/C Debugger User's G uide and Reference.
Ensure you have complete SAS/C or operating system diagnostic messages. SAS/C diagnostic messages are written to stderr</ code>, whose exact location is dependent on the operating system and environment: SYSTERM DD (MVS batch), Terminal (VM, TSO), SASE (CICS).
Messages are explained in SAS/C Software Diagnostic Messages, Release 6.50. A message consists of an ID and text. The format of a message ID is LSCxnnn, where x is C for compiler, D for debugger, G for GENCSEG, I for ILCLINK, L for CLINK, P for the CICS preprocessor, T for the C++ translator, X for the library, or Z for APPLYZAP; nnn is the message number. The message number is followed by text. Library messages (prefixed by LSCX) generally have th ree levels: the first is a severity code; the second is the location of the error; and the third is an explanation. APPLYZAP diagnostic messages are documented in Appendix 1 of this manual.
For operating system problems, the diagnostic message may be one of many types of IBM error messages. Under MVS, these generally start with the letter I. Under VM/SP and VM/XA, the messages may start with DMK (CP) or DMS (VM).
There are some occasions where a message is issued without a number. In these cases, it is even more important to get the entire text of the message. If you are running under VM, check to see if messages are turned on by using the CP command QUERY SET. Turn messages on with the command SET EMSG ON. Under TSO, ensure you are running with PROFILE WTPMSG on.
Diagnostic messages can be output to many places. Places to look are:
- MVS job log (MVS batch)
- SYSTERM DD file (MVS batch)
- terminal (VM, TSO)
- program output file.

Reading a SAS/C Library Traceback

The traceback feature is extremely helpful for isolating the location of an ABEND. Often the traceback contains the exact line that caused the abnormal behavior. Additionally, the traceback shows the calling sequence of active functions, line numbers, and offsets, at the time of the error conditions. A typical ABEND traceback is shown below, with line numbers added for purposes of reference.

Calling trace: Function Line Offset Context 12 LSCABTM(LSCABTM) -- 000124 11 SIGROUT(LSCZRTE) -- 000228 Raising signal SIGABRT 10 SIGLDR(LSCZLDR) -- 00007A 9 RAISE(LSCZGEN) -- 00008E 8 ABORT(LSCABRT) -- 000052 7 CXERR(FILE1) 865 000152 6 REPDEL(TASN) 974 0000B2 5 TREF(TASN) 297 00006C 4 RVFQ(TASN) 214 0001EE 3 WTHDR(WTHDR) 149 0003A4 2 DYNAMN(MAIN1) 366 0009D2 1 MAIN(LC1370S) 68 000128

Line 1 indicates that function main() of the C MAIN program, in source file lc1370s , executed a call to function wthdr() at line number 68 and offset 000128. The function call forced SAS/C dynamic loading to occur and subsequently a call to wthdr() .

Line 2 indicates that a function dynamn() in source file main1 , at line 366 and offset 0009d2, called the function wthdr().

Lines 3-5 illustrate the calling sequence for functions on the stack. The line numbers and offsets show where function calls were made.

Line 6 indicates that an error probably occured at line 974 of function repdel() in source file tasn . r epdel() called cxerr() to generate an ABEND and subsequent compiler messages for a CXERR condition.

Lines 7-12 show the sequence of SAS/C Library functions that get invoked when the function abort() is called within a C program.

Submitting Diagnostic Information to SAS/C Technical Support

The previous sections have explained how to obtain detailed descriptive information about a SAS/C problem. Sometimes this is not sufficien t. If you contact SAS/C Technical Support, the consultant may request additional information about your problem. Additional information that is often requested and how to obtain it are described below.

Source code showing function calls, parameter lists, and so on.
Compiler and linkedit listings and maps.
Logs of program execution generated with the =warning and =b trace run-time options enabled. Commands for capturing execution logs are
- MVS BATCH: enable MSGLEVEL=(1,1).
- MVS TSO: enable Session Manager, execute the program with the problem, and issue the command SMCOPY TODATASET(your.dataset). Session Manager will then copy the entire contents of the Session Manager window to yourid.your.dataset.
- VM CMS: issue the command SPOOL CONSOLE * STAR, execute the program with the problem, then issue the command SPOOL CONSOLE * STOP CLOSE. The log will be sent to your reader.
A system ABEND traceback dump.
On MVS BATCH, issue //SYSDUMP DD or //SYSMDUMP DD.
Note: If Abend-AID (a dump formatting utility) is installed at your site, turn it off for this job by adding the following statement to your execution JCL:
//ABNLIGNR DD DUMMY
But first, check with your systems programmer to ensure that your site does not use a different mechanism for turning off Abend-AID. < /para>
On MVS TSO, allocate a SYSUDUMP or SYSABEND data set, then execute the program with the problem.
On VM CMS, obtain dumps for program exceptions or library-produced abends by doing the following:
- Issue the commands SET RUN OFF and TRACE PROG before invoking your program. This causes CP to transfer control to you when the exception occurs.
- Issue the command DUMP T to send the dump to the printer.
- When the dump is complete, issue the BEGIN command. The abend will resume, and a traceback from the library will be produced.
- To turn off PROG tracing, issue the TRACE END command.
- After a library-produced ABEND (such as an ABEND U1207), spool your console to your reader, then enter the DEBUG command. This will produce a register map and other information. Next, close the console log and then obtain a dump in the same way as for a program exception.
  Note that a dump from a 2M machine can generate 25K lines to the printer. Make your machine size as small as possible before generating a dump. If you want to send the dump on tape, you can spool your printer to your reader (SPOOL PRINT *). Then yo u can use the VM MOVEFILE command to copy the dump to tape. Make sure the input DDname has a blocksize of 133 bytes. Tapes produced by a VM command including VMFPLC2, TAPE, and SPTAPE are acceptable.

See "Electronic Support Services" for instructions on how to get requested information to SAS/C Technical Support.

Chapter Contents
Previous
Next
Top of Page