LSCX Run-time Messages

The SAS/C run-time library generates messages for unusual conditions
detected during program execution. Some of these conditions represent
programmer errors, such as attempting to take the square root of a
negative number, while others represent unusual conditions beyond the
programmer's control, such as running out of memory or a
system service failure.

The library does not diagnose every failure of every function because some
failures are expected. Rather,
it is the application's responsibility to detect these conditions and
inform the user when necessary. For example, the library will not
diagnose a failure to retrieve an environment variable that is not
defined because the caller of getenv should
be prepared for this possibility and usually will not consider it
to be an error.

If the library produces diagnostics that are not desirable for your
application, you can use

the quiet function to suppress these
messages, as described in SAS/C Library Reference, Volume 1

the =warning run-time option to force
library diagnostics to be displayed, even if suppressed by quiet

the =btrace run-time
option to get a list of the active functions (a traceback) at
the time a diagnostic is generated.

describes a condition that permits program execution to continue but
which is not communicated to the caller of the routine. The
errno variable is usually not set.

WARNING

describes a condition that permits program execution to continue;
however, the routine that detected the condition returns an error
indication to its caller. When a library warning is issued, the
errno variable is set and usually an error code is returned
from the function that detected the condition. (Most library messages
are warnings.)

ERROR

describes a condition that forces program
termination, usually with an ABEND.

Run-time library messages are normally written to the stderr
file, except for ABEND messages, which are written to the terminal,
the JES2 job log or to an OS/390 SYSOUT file. (See message 064
for more information about ABEND messages in batch.) If stderr
is not open or not usable, library messages will be sent to the
terminal or to the JES2 job log in OS/390 batch.

Note:
Messages numbered from 000-099 are issued under special circumstances
and are not usually in the format described above; they never modify
the errno variable. Some of these messages are also system dependent.
Messages numbered between 500 and 999 often refer to
system-specific conditions, and the same number may be used by
different systems in different ways. When this occurs, the same
message number will be listed several times, once for each system
where it has a unique meaning.

For additional assistance with any diagnostic, call Technical Support at
SAS Institute. In preparation for your call, read Technical Report
C-114, A Guide for the SAS/C Compiler Consultant and have ready the
required information.

During return from a function, the library detected that stack
storage for the returning function was inconsistent or corrupted.
This is probably caused by the program storing data using an invalid
pointer, a bad subscript, or an incorrect string length.

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
returning function for uninitialized pointers, out-of-bounds array
references, and other similar errors.

During a function call, the library detected that stack
data areas were inconsistent or corrupted. This is probably caused by
the program storing data using an invalid pointer, a bad subscript, or
an incorrect string length.

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
calling function for uninitialized pointers, out-of-bounds array
references and other similar errors.

During program termination, the library discovered that the end of the
stack had been overlaid. This error can occur only when a program
runs with the =minimal run-time option. Note that stack
overflow is not detected when it occurs but only at program
termination. However, if stack overflow is detected, then all the
program's results should be regarded as possibly incorrect.

Run the program again without specifying =minimal, and use the
=usage run-time option to obtain an accurate estimate of the
amount of stack space required by the program. Then adjust the initial
stack space requested accordingly, adding some extra space for error
handling and other unusual situations.

During program termination, the library discovered that stack management
data areas were inconsistent or corrupted. This is probably caused by
the program storing data using an invalid pointer, a bad subscript, or
an incorrect string length. Note that even though this error is
detected during termination, it may have occurred much earlier, and
all the program's results should be regarded as possibly incorrect.

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
program for uninitialized pointers, out-of-bounds array
references and other similar errors.

During a call to longjmp, the library was unable to locate the
function to which control was to be returned. This may be caused by
overlaying a jmp_buf. It may also be caused by calling
longjmp for a jmp_buf set by a call to setjmp in
a routine that has already returned to its caller.

During execution of the malloc function, the library detected
that library free storage control blocks had been overlaid. This is
probably caused by the program storing data using an invalid pointer,
a bad subscript, or an incorrect string length. Note that the overlay
may have occurred much earlier in the program's execution, and may
have nothing to do with the code executing at the time of the ABEND.

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
program for uninitialized pointers, out-of-bounds array
references and other similar errors.

During execution of the malloc or free function, the
library detected library free storage control blocks had been
overlaid. This is probably caused by the program storing data using
an invalid pointer, a bad subscript, or an incorrect string length.
Note that the overlay may have occurred much earlier in the program's
execution, and may have nothing to do with the code executing at the
time of the ABEND.

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
program for uninitialized pointers, out-of-bounds array
references and other similar errors.

During execution of the free function, the
library detected that library free storage control blocks had been
overlaid. This is probably caused by the program storing data using
an invalid pointer, a bad subscript, or an incorrect string length.
Note that the overlay may have occurred much earlier in the program's
execution, and may have nothing to do with the code executing at the

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
program for uninitialized pointers, out-of-bounds array
references and other similar errors.

The argument of a call to free did not appear to be the
address of storage previously allocated by malloc. One possible
explanation is that the 8-byte prefix that precedes
each block of storage allocated by malloc has been overlaid.
Note that the overlay may have occurred much earlier in the
program's execution and may have nothing to do with the code
executing at the time of the ABEND.

If the storage to be freed appears to have been correctly allocated
with malloc, run the program again using the =storage
run-time option, or run the program under the SAS/C debugger and use
the storage debugger command to locate the overlaid data areas.
Also, inspect the program for uninitialized pointers, out-of-bounds
array references and other similar errors.

During program termination, it was discovered that free storage
management data areas were inconsistent or corrupted. This is
probably caused by the program storing data using an invalid pointer,
a bad subscript, or an incorrect string length. Note that even though
this error is detected during termination, it may have occurred much
earlier, and all the program's results should be regarded as possibly
incorrect.

Run the program again using the =storage run-time option, or
run the program under the SAS/C debugger and use the storage
debugger command to locate the overlaid data areas. Also, inspect the
program for uninitialized pointers, out-of-bounds array
references and other similar errors.

Determine the reason that abort was called, and correct the
problem. Note that if this message occurs running the compiler or
a SAS/C utility, it indicates a programming error in the compiler
or utility and should be reported to SAS/C Technical Support.

The program called the unloadm function, but the argument
did not appear to be a pointer to a function in a load module
loaded by loadm. One possible cause of this message is an
overlay of the function pointer.

If the argument to unloadm appears to be a valid function
pointer into a module loaded by loadm, inspect the program for
uninitialized pointers, out-of-bounds array references and other
similar errors. Use of the debugger monitor command may also
be helpful in locating the overlay.

These messages indicate that required transient library modules could
not be loaded. The first message above is the most common case. This
message occurs during program initialization if the library's I/O and
error-handling routines could not be found. This most likely indicates
a problem with JCL, TSO allocations or CMS disk accesses, such that the
program is unable to access the transient library at all. The second
message is produced when certain transient modules (for instance,
signal handling) cannot be located after initialization is complete.
This form of the message most likely indicates an error installing the
transient library. The third form of the message occurs only when
the Generalized Operating System interface (GOS) is in use.

Confirm that the transient library is available. Contact your local
SAS/C support to determine the proper procedures for access to the
transient library at your site.

In OS/390 batch or TSO, the library startup code looks for the transient
library modules in one of the following places:

In the library allocated to the DDname CTRANS.

In any allocated task library. (For instance, under ISPF, the DDname
ISPLLIB will be searched.)

In STEPLIB or JOBLIB.

In the system linklist.

In the OS/390 link pack area (LPA).

If the library has not been installed into linklist or LPA, any SAS/C
job or session must have an appropriate DD statement defined as in
items 1 through 3 above.

Under CMS, the library startup code looks for the transient library
modules in one of the following places:

In a shared segment created when the product was installed.

In LSCRTL LOADLIB on an accessed minidisk.

If the library has not been installed into a segment or segments, you
must access the library minidisk before running a SAS/C program.

Under UNIX System Services OS/390, when a program is invoked by the
exec system call, the library startup code looks for the
transient library modules in one of the following places:

In the library named by the ddn_CTRANS environment variable.

In the list of libraries defined by the STEPLIB environment
variable.

In the system linklist.

In the OS/390 link pack area (LPA).

If the library has not been installed into linklist or LPA, any SAS/C
program run under UNIX Systems Services will require definition of one of the
environment variables listed above.

For a C program linked using a Generalized Operating System library,
where the library looks for transient modules is not defined by SAS/C.
In this case, consult the implementer of the GOS interface routines.

An attempt was made to run a SAS/C dynamically loadable module
as an independent program.
A SAS/C dynamically loadable module can only be used when loaded by
another SAS/C program using the loadm function.

The SAS/C library diagnostic support suffered multiple errors while
trying to write a diagnostic message. This is probably a SAS/C library
error, though it could be caused by program overlays of library
data areas.

The program was terminated due to use of the debugger
abort command. Also, this ABEND is issued if the debugger is
unable to respond to multiple attention interrupts and the user
chooses to terminate the application.

For some applications, allowing non-C calling routines to be terminated
by longjmp or exit is not a problem. For such
applications, you can modify L$UPREP to suppress this ABEND, as
described in Appendix 6, "Using the indep Option for Interlanguage Communication,"
in the SAS/C Compiler and Library User's Guide.

The program invoked a function that requires the presence of
UNIX Systems Services in the system, such as getpid, but UNIX Systems Services
was not installed or not running. The POSIX definition of the function
did not permit the function to fail.

Do not use functions that require UNIX Systems Services on systems where
UNIX Systems Services is not installed. If is normally running
on your system, contact your Systems Programming Staff for
assistance.

Call CFMWK before calling a C function from another language,
and verify that the CFMWK call was successful.
Refer to the SAS/C Compiler Interlanguage Communication Feature User's Guide for details on how to create a C framework.

During ABEND analysis, an unexpected program check was encountered
which made further recovery and analysis impossible.
This message is produced, the analysis is terminated, and if possible a
dump is taken. This error can be caused by program errors which cause
library object code to be overlaid.

If the ABEND code is a user code in the range 1200 to 1240,
(for instance U1235) then refer
to the SAS/C Library Reference for more details.

For a system ABEND, refer to the appropriate operating-system-dependent
listing of ABEND codes for details on the ABEND. (See MVS System Codes
for OS/390 or VM System Messages and Codes for CMS.)
User ABENDs not in the SAS/C range are generated by the SAS/C program
using the abend function, by assembler subroutines, or by
other products, such as FORTRAN, PL/I or IMS.

Two particularly common
user ABEND codes are 240, which is a FORTRAN ABEND code, and 4000,
which is a PL/I ABEND code. In general, the meaning of a user ABEND
code depends on the application and the other products or interfaces
it uses, and therefore you should consult with local expertise if you
receive a user ABEND code you do not recognize.

Library messages 000 through 041 are often accompanied by one or more
additional messages giving supplementary information about an ABEND.
These messages are not numbered. The messages and their meanings are
as follows:

C run-time storage has been overlaid by the program.

The ABEND analysis has found one or more library control blocks to be
in an inconsistent or corrupted state. Running the program
again with the =storage run-time option may produce information
about the overlay.

Runtime library failure, library storage may have been overlaid.

The ABEND occurred while a critical library routine was executing.
Often this means that library storage was overlaid before the failure.
Running the program again with the =storage option
may produce information about the overlay.

The ABEND occurred in another task or domain.

The ABEND occurred in non-C code not called directly from your
program. For example, you would get this message if the debugger
ABENDed while debugging your program, or if a CMS ABEND occurred while
a REXX function package was loaded but inactive.

A non-C or system routine was running at the time of ABEND.

The ABEND occurred in non-C code called from C, usually in a system
routine.

This ABEND could not be recovered due to environmental damage.

Corruption of library control blocks prevented the library from
converting this ABEND into a C signal.

Traceback terminated - save areas overlaid.

Due to corruption of stack information, a complete C calling trace
could not be produced. If you run the program again with the
=storage option, you can probably get more information about
the overlay.

Unable to determine location of failure.

ABEND analysis was unable to determine where the failure occurred.
This may be due to overlay of control blocks. It may also be generated
if the ABEND occurs during program termination after the C framework
has been partially destroyed. After this message, the ABEND handler
prints the ABEND PSW and registers, which may be useful in the
absence of a traceback.

This message was issued due to use of the =usage run-time
option. The library produces a report on the amount of stack and heap
used as well as the number of system allocate requests and frees. If
the program uses coprocesses, a stack report is given for both the
main coprocess, and for all coprocesses combined.

The library stops generating warning messages after
a maximum number of five have been printed if stderr is
unavailable, in order to avoid flooding OS/390 consoles with messages.
There is no message limit if stderr is
available.

If possible, correct any problems that prevent the use of stderr.
For instance, in OS/390 batch, make sure a valid SYSTERM DD statement is
defined. Alternately, consider use of the quiet function
to suppress these messages.

Refer to previous messages to determine the cause of
the ABEND or increase memory availability and rerun the program
to obtain a traceback and other diagnostic information. Note that
if, due to an error, a program loops consuming all available memory, it
may not be possible to bypass this condition by increasing the region
size.

When the C framework is created by the ILC routine CFMWK, or
when the entry point to a program is specified as $MAINO, the
caller provides an argument string containing any run-time options
to be passed to the program. This diagnostic is produced if any part
of this string cannot be recognized as a valid run-time option or
redirection.

Correct the calling program to specify a correct run-time options
string. See SAS/C Interlanguage Communication for
information on CFMWK.
For more details on passing run-time arguments using $MAINO see
the SAS/C Compiler and Library User's Guide, Chapter 10,
"Communication with Assembler Programs."

If the program is executing in the normal C environment make sure the
transient library is available and was installed correctly.
If the program is linked with a Generalized Operating System (GOS)
library, consult your local GOS implementer for information on
this condition.

Note that this message may be produced by an all-resident program if
a library diagnostic is required, but the program defined the symbol
NO_WARNING before including <resident.h>.

When the C run-time environment is first created a check is made
to confirm that the transient run-time library modules are at least as
recent as the resident libraries used at link time. If the resident
library is more recent then the transient library,
this message is produced as a warning that correct behavior cannot
be assured.

The second line of the message indicates the minimum transient library
level necessary to guarantee compatibility with the executing load
module.

Contact your local support for SAS/C for information on how to access
the most current version of the SAS/C transient library.
For more details on combining different release levels of the
resident and transient libraries, see
"Rules for Using Different Releases of the Compiler and Library"
in Chapter 1 of the SAS/C Library Reference, Volume 1.

This message is accompanied by message 043. An
abbreviation of a run-time option was specified, but the
abbreviation did not contain enough characters to identify
it uniquely. The option is ignored and execution continues.

A library message was generated and the =quit run-time option
was specified. The program is abnormally terminated, with a user
ABEND code matching the number of the generated message. (For example,
if message 502 was generated, then the ABEND code is user 502). This
message is generated to explain the reason for the ABEND.

This message is generated to identify the ABEND code and the language
when an ABEND occurs in a language other than C.
Some languages, such as FORTRAN, modify the ABEND code during
their processing, and the ABEND code printed by C
may be the modified rather than the original code.
language-name may also be CDEBUG for an ABEND that occurs
in the C debugger or CMS for an ABEND that occurs under CMS while a
REXX function package is idle.

This message may occur when an 0Cx ABEND occurs in a language
that does not define a handler for this particular ABEND.
The C framework manager assumes control
and determines whether or not the ABEND should proceed.

In some cases, it is not possible for the framework manager
to allow the ABEND to proceed without either changing the
ABEND code or the perceived location of the ABEND.
Because changing the location of the ABEND affects the accuracy
of the error message, the
framework manager instead changes the ABEND code. More exactly,
it loads the registers at the time of ABEND and branches to
an odd address within a byte of the original ABEND location.
Thus, information such as the number of the line that failed
should be correct.

The framework for another language
had begun to terminate and then attempted to call (or return to)
C. This can occur only if an interlanguage call or return is
attempted after the use of a language facility that allows
program termination to be intercepted, such as a PL/I FINISH ON-unit.

This message is issued when a C function is called from
another language but the C framework is already active.
The most likely cause of this error is a non-C routine
that was not declared with a keyword such as __cobol. In some
cases, a misdeclared routine of this sort may execute
successfully; however, if it calls another C function,
this error results.

This message occurs in a TSO SUBCOM application. The C program has
called execend to terminate SUBCOM processing, but while the
library was attempting to terminate an active TEXX EXEC, a subcommand
was addressed to the terminating program.

The REXX input line that caused this message fails and passes a return
code of -10 back to REXX.

This message occurs in a TSO SUBCOM application. It indicates that
while the C program was processing a REXX command, another
command was addressed to the same environment. This is likely to
happen only if the user is running several REXX EXECs as independent
subtasks, or if the C program calls the system function to
invoke another EXEC.

The REXX input line that generates this message fails and passes
a return code of -10 back to REXX.

A CMS SUBCOM application invoked another CMS processor. For instance,
it used the system function to invoke an EXEC. The invoked
processor then attempted to address the SUBCOM environment of the
original program. Recursive invocation of the SUBCOM interface in this
fashion is not permitted. A return code of -10 is passed back to
the program that attempted the recursive invocation.

This message indicates that for some reason the =storage
run-time option failed to produce a storage corruption report.
Typically this message is preceded by other library
messages describing the problem.

The library diagnostics associated with a program ABEND (including
the program traceback) were directed to the DDname indicated, either
SYSTERM or a SYSOUT file allocated by the library. This avoids increasing the
load on the OS/390 system console for C programming errors.

An UNIX Systems Services application attempted to dynamically allocate a
DDname needed by the library as specified by an environment
variable but the allocation failed. The DYNALLOC error code is
included in the message.

Look up the error code in the
IBM MVS/ESA Application Development Guide: Authorized Assembler Language Programs,
and take appropriate action. If the error code indicates a problem with
the file to be allocated (for instance, it does not exist), correct
the value of the environment variable and rerun.

This message is produced if you hit the attention key while a SAS/C
SUBCOM application is running a REXX EXEC. The message indicates that
you can communicate to REXX by entering any REXX immediate command, or
send an attention signal to the SAS/C debugger or library by entering
IC.

Provide a CTRANS DD statement or use the ddn_CTRANS
environment variable to define the location of a compatible version
of the transient library. Contact your SAS/C Support Representative
to determine the appropriate data set name.

This message indicates that an error occurred formatting the previous
library message, and that some of the message text was lost. This
condition should not occur and indicates a potential problem in the
run-time library.

This message is produced if you run an all-resident application under
the shell and the library needs to generate a diagnostic message, but
is unable to send the message because HFS I/O support was not linked
into the module. The original diagnostic message is sent to the MVS
console as an alternative.

Explanation

With Release 7.00, the command line must be 2,000 characters
or less if you are using MAIN as your entry
point.

Action

It is not possible to increase the command line length beyond
2,000 bytes for the MAIN entry point. You will
need to use either the $MAINC or the $MAINO entry point if you require a command line that is longer
that 2,000 bytes.

Action

This message indicates a physical I/O error processing a VSAM data set,
probably a hardware
problem. The rest of the text of the message contains details that may
be helpful in isolating the error. This message is sent to the
Operator's console in MVS.

This message is similar to message 098 except that it applies to BSAM rather
than VSAM files. This may indicate either a hardware problem, or
a program logic error. If the message is accompanied by an MVS
IOS000I message, it probably indicates a hardware problem.

If the message indicates WRNG.LEN.RECORD, the probable cause is
incorrect DCB information, possibly caused by incorrect concatenation
of DD statements. Another possible cause is a call to fseek or
fsetpos with a corrupted or uninitialized seek address.
Consult with your local system programming staff for help interpreting
this message and determining possible causes.

A C load module was linked with neither a main function nor a
_dynamn function. This message is issued by a dummy
main function contained within the library. This is usually
a link-edit error that caused part of the program to be omitted or
that specified the wrong entry point.

Unless the compiler option indep is in use, every C program
requires a main function. If indep is not in use,
ensure that the main function is included when the program is
linked. If indep is in use, ensure that the program entry
point is defined as the first function to be executed, not as MAIN.

During the execution of one of the scanf family of
functions, an incompatibility was detected between the data and the
format string. Up to eight characters of the format string are
displayed in the message.

If an actual % character is desired in the output,
specify two % characters (for instance, Interest rate %d%%).
Refer to the SAS/C Library Reference for more details on the
function being invoked and valid format strings.

The function indicated has been passed arguments
that address overlapping areas. The results are unpredictable.
Some of the functions that may cause this message to be
generated are: memcpy, memcpyp, and memfil.
This message may also be generated if the length passed to one of
these functions is extremely large, perhaps due to an uninitialized
variable.

If it is valid for the data areas to overlap, consider using
the memmove function. See the SAS/C Library Reference
for information on memmove.

This message can be generated within the library during program
startup if a SAS/C program is invoked with an invalid parameter list
pointer in register 1. If the program issuing the message was invoked
from another program (for instance, using the ATTACH macro), check the
invoking program to be sure it has constructed a correct parameter list.

This generally indicates that the program has attempted to use a
library feature which was not specified at the time that the
<resident.h> header file was included. This is permitted
only if ALLOW_TRANSIENT is specified and the transient library
is accessible. Refer to the SAS/C Compiler and Library User's Guide,
Chapter 9, "All Resident C Programs," for details.

The IBM 370 system clock has a year range of 1900-2041. If the
time value passed to the mktime function
falls outside of this range, the above message is
generated and mktime returns a error code to its caller.

A format item for a printf-like function specified a length
larger than the limit for this function. The limit is 512 characters
for functions other than sprintf and its variants (which have
no limit). Note, this limit does not apply to %s and
%V formats.

During an attempt to convert the specified string to the specified
base, the strtol function encountered an integer
overflow. The strtol function returns
LONG_MAX or LONG_MIN for
this condition. stroul can also generate this message, in
which case it returns ULONG_MAX.

The argument of a call to free did not appear to be the
address of storage previously allocated by malloc. One possible
explanation of this condition is that the 8-byte prefix which precedes
each block of storage allocated by malloc has been overlaid.
Note that the overlay may have occurred much earlier in the
program's execution and may have nothing to do with the code
executing at the time of the ABEND.

If the storage to be freed appears to have been correctly allocated
with malloc, run the program again using the =storage
run-time option, or run the program under the SAS/C debugger and use
the storage debugger command to locate the overlaid data areas.
Also, inspect the program for uninitialized pointers, out-of-bounds
array references, and other similar errors.

Ensure that the library passes valid signal names in calls to
signal-handling
functions. Integer constants should not be passed to signal
routines, since different systems often use different numbers for the
same signal. See Chapter 5, "Signal-Handling Functions" in
SAS/C Library Reference, Volume 2,
for information on valid signals.

The named signal cannot be handled because a run-time option was used.
The option =nohtsig inhibits handling of termination signals
SIGABRT and SIGABND. The option =nohcsig
inhibits handling of computational signals SIGFPE,
SIGSEGV and SIGILL.
The request to handle the signal is ignored.

See the SAS/C Compiler and Library User's Guide
for complete details on run-time library options and
"Signal-Handling Functions" in
SAS/C Library Reference, Volume 2 for general information
on signal-handling.

A handler attempted to return to the point of interruption, but this
was not allowed for this signal. The program is abnormally terminated,
using the ABEND code associated with the signal. (Signals for which
return is forbidden include SIGABRT, SIGABND, SIGSEGV and SIGILL.)

To recover from one of these signals,
the handler must use the longjmp function to resume
execution.
See "Signal-Handling Functions" in
SAS/C Library Reference, Volume 2 for general information on
signal handling.

If the argument to unloadm appears to be a valid function
pointer to a module loaded by loadm, inspect the program for
uninitialized pointers, out-of-bounds array references, and other
similar errors. Use of the debugger monitor command may also
be helpful in locating the overlay.

Reorganize the program so that this limit is not
reached. (Note that in most cases a program which attempts to
create the maximum number of coprocesses will run out of memory
first.) For complete details on coprocesses, see the SAS/C Library Reference,
Chapter 9, "Coprocessing Functions."

Increase the amount of memory available for the execution and make sure
that the program is freeing memory which it no longer requires.
Also, investigate whether the amount of stack space for each coprocess
can be reduced.

The costart_parms argument to the costart function
contains several reserved areas that must be set to zeros. This
condition probably occurred because the costart_parms argument
was not completely initialized.

A call to mktime specified a tm_isdst field of 1 in
the argument, indicating that daylight savings time was in effect.
But the value of the TZ environment variable did not include
a daylight savings time definition, so the call to mktime
failed.

A call to mktime specified a tm_isdst field of 1 or 0
in the argument, indicating that daylight savings time was or was not
in effect. Because the TZ environment variable was undefined
or invalid, the library has no daylight savings time information
available. The returned tm_isdst field is set to -1, and
mktime assumes an offset from GMT based on the hardware
time-of-day clock.

The argument to mktime specified a time which cannot occur in
the time zone defined by the TZ environment variable and
set the tm_isdst field of its argument to -1. For instance, if
standard time ends at 2:00 AM on March 30, and daylight time begins at
that moment at 3:00 AM, then 2:30 a.m. on March 30 is an impossible time.

The value of the TZ environment variable specified a time zone
that is inconsistent. For example, the end time for daylight
savings time
is later than the end time for standard time but less than the
start time for savings time. The inconsistent TZ value is
ignored, and the time zone implied by the hardware time-of-day clock
setting is used.

The value of the TZ environment variable does not conform
to the syntax specified by the POSIX standard. Note that the POSIX
standard allows an implementation to support additional TZ
formats beginning with a : but SAS/C supports no such formats.

The scope specified is invalid or not supported in the current
environment. See the "Environment Variables" chapter of the
SAS/C Library Reference for a discussion of the valid scopes.
If the errno variable is set to EFORBID, it indicates that the
program was created using the all-resident library and that
use of TSO environment variables was not requested at compile-time.
It also indicates that the program was running in TSO,
called getenv, and was unable to find a variable in the
program scope variable list.

For more information on environment variable scopes, see
Chapter 4, "Environment Variables," in the SAS/C Library Reference.
See the SAS/C Compiler and Library User's Guide for information
on using the all-resident library.

If the locale specified is intended to be a user-defined locale,
correct JCL allocations or disk accesses so the load module supporting
that locale is accessible. If the locale is intended to be a standard
locale, correct the specification. See "Localization Functions" in
the SAS/C Library Reference, Volume 2 for more information on
implementing user-defined locales.

An attempt was made to perform I/O in a program for which I/O
support was suppressed. I/O can be suppressed using the _NIO library
option or, in an all-resident program, by specifying NO_IO when
including <resident.h>.

The debugger is not supported for programs running in an
authorized environment. If this were
permitted, debugger facilities could
allow subversion of OS/390 integrity and security features by unauthorized
users.

It is not yet clear if this message will be possible with the
remote debugger.
The debugger is not supported for programs running with an effective
uid or gid different from the real uid or gid. If this were permitted,
debugger facilities could allow subversion of integrity
and security features by unauthorized users.UNIX Systems Services

Floating-point overflow or underflow (as indicated in the message)
occurred during computation of a mathematical function. The errno variable
is set to ERANGE and an appropriate value (+/-HUGE_VAL for overflow or 0.0 for underflow) is returned.

Floating-point overflow or underflow (as indicated in the message)
occurred during computation of a mathematical function. The errno variable
is set to ERANGE and an appropriate value (+/-HUGE_VAL for overflow or 0.0 for underflow) is returned.

The indicated value is a singularity of the indicated function; that
is, the function approaches infinity as the argument approaches the
singularity. The errno variable is set to ERANGE,
and an appropriate value (+/-HUGE_VAL)
is returned.

The function result is less accurate than the arguments. If the
message indicates total loss of significance, the result may be
completely inaccurate. If it indicates partial loss of significance,
the result is approximately correct, but considerably less precise
than its input arguments.

If possible, correct the program or the data. Output of this message
may indicate serious problems with the correctness of program results,
which should be evaluated carefully. The message can be suppressed
using the _matherr function, as described in the SAS/C Library Reference, Volume 1.

Floating-point overflow or underflow (as indicated by error-type)
occurred during computation of a mathematical function. The errno variable
is set to ERANGE and an appropriate value (+/-HUGE_VAL
for overflow or 0.0 for underflow) is returned.

The function result is less accurate than the arguments. If the
message indicates total loss of significance, the result may be
completely inaccurate. If it indicates partial loss of significance,
the result is approximately correct, but considerably less precise
than its input arguments.

If possible, correct the program or the data. Output of this message
may indicate serious problems with the correctness of program results,
which should be evaluated carefully. The message can be suppressed
using the _matherr function, as described in the SAS/C Library Reference, Volume 1.

Explanation

The C++ library found a condition during exception handling
that prevented continued execution.

Action

If the reason indicated is out of memory,
this is caused by a throw after memory in both the normal area and in the
area reserved for exception handling has been exhausted. Either a large object
(size greater than 1K bytes) has been thrown or multiple smaller objects have been thrown
after normal memory is exhausted. If a different reason is indicated, contact
SAS/C Technical Support.

Explanation

A C++ exception was thrown, and the run-time option =xtrace is in effect.
The exception-type value in the message text is a brief description of
the type of exception thrown.
For the exception types defined in the C++ standard library, the description
gives the actual type, such as class std::bad_alloc. For other types,
the text is either
non-standard class or non-standard type if the actual exception type is not
a class. In such cases, the exception type can generally be determined by
inspection of the throw statement in the program.

The message is followed by a traceback of functions active at the time
the exception was thrown.

Action

If the exception is unexpected, correct the program to not
throw the exception.

Explanation

A C++ exception of the type indicated was thrown, and it
was not caught by the program (or was rethrown after being caught). The C++
library is about to terminate the program by calling the std::terminate function. std::terminate
terminates the program with a user 1210 ABEND,
unless the default terminate handler is replaced by use of the set_terminate function.

The message is accompanied by a traceback of functions active at the
time the exception was first thrown. If the =btrace
run-time option was specified, there will also be a traceback of functions
active immediately before std::terminate is
called. In this case, the =btrace traceback
will appear first.

Action

Correct the program to catch the exception and/or to avoid
throwing the exception.

Explanation

If the reason is rethrow with no current exception,
then a C++ program used a throw statement to rethrow the current exception
in a situation where no current exception was defined. This is erroneous,
and the C++ library calls the std::terminate
function to terminate the program. Unless the default terminate handler is
replaced by a program call to set_terminate, std::terminate
aborts program execution with a user 1210 ABEND.

If the reason is an uncaught throw with pending catch, this indicates
that the exception handling mechanism was attempting to initialize a catch
handler variable but the initialization was aborted because of an uncaught
exception. If the reason is an uncaught throw while unwinding a stack, this
indicates that while unwinding the stack due to an exception, a destructor
was called which aborted because of an uncaught exception. In these cases
the exception handling mechanism handles the new exception by calling the
terminate handler that was in effect at the time of the uncaught throw.

Action

In the rethrow case, correct the code to rethrow the current
exception only when an exception has been caught by a handler that has not
exited. In the other cases, std::uncaught_exception()
can be used to detect when the exception handling mechanism is active in order
to avoid further throws. More generally, it is best to avoid destructors
that can throw or exception objects whose copy constructor can throw.

Correct the program by having only a single foreign language
active or by supplying a language token as needed.
Refer to the SAS/C Compiler Interlanguage Communication Feature User's Guide for more details.

An interlanguage call or return has occurred but the routine
making the call or return is not consistent with the chain of
routines that were active at the time of the last interlanguage
call or return. This could be caused by a storage overlay.

However, it is more likely that use of a GOTO-like control structure
in one language (such as the C setjmp) has terminated routines
in another language. This condition can usually only be detected
at the time of an interlanguage call or return; therefore, the
actual error may have occurred much earlier than the point
where the message was issued.

An argument was passed to dlfmwk that is not a valid language
token for any active language.
This may be the result of an uninitialized variable.
It can also occur if an attempt is made to delete a framework
more times that it has been created. dlfmwk returns a nonzero
value to indicate the call has failed.

A call dlfmwk or DCFMWK failed because the framework could
not be terminated. One or more routines in the named language
may have been still
executing. For example, this message is generated if a C
function called from FORTRAN uses dlfmwk to attempt to
delete the FORTRAN framework. A nonzero value will be returned to
indicate the call has failed.

An attempt was made to create a framework or call a routine in
another language in more than one coprocess. If the error
is detected by mkfmwk, the message is issued as a WARNING and a
zero token is returned to indicate that the framework could
not be created.

If the error is detected during a call to
another language, the message is issued as an ERROR and
a user 1235 ABEND is issued because there is no way to
communicate to the program that the call has failed.

An attempt was made to call a routine in another language when
its framework had not yet been successfully created.
A call to mkfmwk or CFMWK may have been omitted.

Alternately, perhaps mkfmwk or CFMWK failed and
the program neglected to check for failure, in which case
a previous message
should describe the reason for the failure.
After this message is printed, the SAS/C library
issues a user 1234 ABEND.

If program termination was not intended, correct the program. For
instance, perhaps a FORTRAN routine used a STOP statement when
RETURN was intended, or a COBOL program used a STOP RUN when
GOBACK was intended.

The C program had begun to terminate
and then attempted to call (or return to) another language.
This can occur only if an interlanguage call or return is attempted
after blkjmp or atexit is used to intercept program termination.
This message can also occur if an interlanguage call is attempted
during termination of a coprocess using blkjmp or atcoexit.

This message is generated after message 281 if the framework
that terminated unexpectedly is not the framework most recently
created. In this case, the unexpected termination interfered with
the SAS/C framework manager's error-handling code. This interference
is only temporary; if termination completes
successfully, there should be no residual effects of the
interference.

However, if an error or program check occurs
during termination of the other frameworks, this will likely provoke
a cascade of errors, with little reliable information
about cause or location.

Since the possibility of errors during framework termination
cannot be prevented, this message is
issued before anything else can go wrong because the chances
of issuing it after an error are slim.

An argument passed to a non-C routine is of a data type not supported
by the called language. For instance, a structure was passed to
FORTRAN. The SAS/C library passes the argument by reference,
unaltered.

The declared return value type for a non-C routine called from C
is not a type supported by the called language. For instance,
a PL/I routine cannot return a structure. The SAS/C library
allows the call to proceed but the handling of the return
value is unpredictable.

If the results are not satisfactory, rewrite the interface between
the languages to use a supported data type. The message can be
suppressed via the quiet function, as described in the
SAS/C Library Reference, Volume 1.

A library table used to contain framework information has
filled up and no more frameworks can be created. This table
is shared by all C programs in a virtual machine or under a
single OS/390 task. The table contains entries for 20 frameworks.
CFMWK stores a zero token value to indicate the failure.

A coprocess (other than the main
coprocess) that has created frameworks for additional languages
terminated without deleting these frameworks. These frameworks
are all deleted, but execution of the C program continues.

A language, whose framework was
created by a C coprocess other than the main coprocess,
terminated unexpectedly. All other non-C frameworks, and the
coprocess that created them, are terminated, but other
coprocesses continue to execute if there are no errors during
this termination. See message 281 for
a list of possible causes of unexpected framework termination.

An unexpected error occurred
during a call from C to a non-C routine. Previous message(s)
should describe this error more fully. The code value in the
message is the value stored in the errno variable by the previous error.
Usually this value will be ENOMEM, indicating that there
was no memory available to perform the call.

An attempt was made to
write out a partial record. A file with a fixed record format,
RECFM=F, requires all records to be full-length.
The library will only pad short records
if the pad
amparm is specified. Valid
pad specifications are pad=null
and pad=blank. Note, for binary files accessed using the
seq access method, pad=no is assumed by default.

Either correct the program to write full-length F format records,
change the output RECFM, or specify an appropriate pad amparm
when opening the file.
Refer to "I/O Functions" in Chapter 3 of the SAS/C Library Reference, Volume 1.

Correct the erroneous call to specify a valid symbolic constant as
the final argument.
Refer to "I/O Functions" in Chapter 3 of the SAS/C Library Reference, Volume 1
for descriptions of specific functions.

To perform both input and output to the terminal, open them separately.
To assume complete control of the terminal,
use the SAS/C full-screen support library and
window manager.
For more details refer to SAS/C Full-Screen Support Library User's Guide, Fourth Edition.

The access method passed to afopen
is not defined.
The access method name must be no more than four
characters in length. Valid access methods are: term,
seq, rel, kvs, and hfs.

This error may occur with an all-resident program if an unusual type
of file is processed and appropriate symbols were not defined in the
source module that includes <resident.h>. For example, you
might get this message for access method kvs if RES_VSAM was not defined and the program attempted to access a VSAM
file.

Refer to the section "Library Access Methods" in Chapter 3 of the
SAS/C Library Reference
for more detail. See "All-Resident C Programs"
in SAS/C Compiler and Library User's Guide, Fourth Edition, for more
information on <resident.h>.

The file name style specified in the open is invalid.
Valid styles are:

Stylecode

File type

cms

CMS file name

ddn

DDname

dsn

OS/390 data set name

hfs

UNIX Systems Services HFS file

path

NFS file (on another system)

sf

CMS shared file

sfd

CMS shared file directory

tso

TSO file name

xed

XEDIT file

This message may be generated for an all-resident program if it tries
to use a file name that is supported only if an appropriate symbol
is defined when including <resident.h>. For instance, an
all-resident program can access files with sf style file names
only if the program first defines the symbol RES_SHARED_FILE
before including <resident.h>.

Refer to "I/O Functions" in Chapter 3 of the SAS/C Library Reference, Volume 1,
for more details. See "All-Resident C Programs"
in SAS/C Compiler and Library User's Guide for more
information on <resident.h>.

clearerr or clrerr was called to clear the error flag
for a file, but the flag could not be cleared. The file is a standard
file (stdin, stdout or stderr) that failed to open
successfully. A standard file can fail to open due to an invalid
redirection, an invalid specification of _stdinm, _stdonm,
_stdenm, or a missing DD statement.

One of the standard files (stdin, stdout,
or stderr)
failed to open successfully. This can be caused by a missing DD
statement, an invalid redirection or an invalid _stdinm,
_stdonm,
or _stdenm specification. Another message should have been
generated describing the failure.

The only means of clearing the error flag in this case
is to close and
reopen the file. A previous message should explain the cause of the
original error. Note, by using the function clrerr to
clear the error flag, you can determine at execution time whether or not
error recovery is possible.

For a call to afread, the record to be read was larger than
the amount specified by the afread arguments. For a call to
afwrite, an existing record was being overwritten, and the
amount to be written was less than the existing
record size. (This can happen
only when the file has trunc=no behavior.)

This message indicates that fread or afread was called to read items whose size was
greater than 1, but the amount of data read was not an even
number of items. For instance, reading 2 integers (size 4) from a file
containing six bytes of data would cause this message to be
generated.

Correct the program, or correct the input data to conform to the
program's requirements. Note that the second argument to fread
or afread is the item size, and the third argument is the
count. If you code afread(buf, 6000, 1, fileptr), the call
will fail unless the next input record is exactly 6000 bytes long.
If you code afread(buf, 1, 6000, fileptr), you can successfully
read any record whose length is 6000 bytes or less.

An attempt was made to push back more characters with ungetc
than can be supported by SAS/C.
The ISO/ANSI standard states that only one character of pushback can
be guaranteed. SAS/C allows more than one character to be pushed
back when each character pushed back
matches the character read from that position,
except at the start of a record.

An output request was rejected because the last file operation was
a read. The ISO/ANSI standard requires that a seek operation be
performed between read and write requests unless the read
detected end of file.

To switch between input and output modes, the program
must be at the beginning of file for certain files, notably OS/390 PDS members.
If this restriction is violated, the requested operation
is not performed and the error flag is set for the file.

The file to be opened does not have a RECFM (record format) that
includes A (ANSI carriage control), and therefore the print=yes
amparm cannot be supported.
The open attempt will continue ignoring print=yes.

Note that the standard file stdout is opened by the library using
the amparm print=yes. Therefore, this message may be issued for
stdout if the file's RECFM does not include A, even though stdout is not explicitly opened by the program.

None is required. However, to avoid the message
either use a file capable of being printed
or remove the print=yes amparm.

If the message is issued for stdout, you can use the external
variable _stdoamp to override the library's amparms for this
file. For example, you can code char *_stdoamp = "" to specify
that stdout should be opened without any amparms.

An attempt was made to change a text
file's record structure by changing a new line character to an ordinary
character or changing an ordinary character to a new line.
An example is trying to replace the text abcn with ancn or
abcd. The first attempts to replace one record with two, the second
attempts to combine this record and the next record. The error flag
is set for the file.

Note, this condition occurs only for trunc=no files, since
with a trunc=yes file, the file is truncated at the point of
output, and therefore the length of the last record can be changed.

The length of a record was not consistent with the
record format of the file. This could be caused by
using JCL DCB parameters to tell the library that a file was
suitable for
rel access when it fact it was not. The error flag is set for
the file.

The presence of a wrong-length record in a relative file may
cause incorrect file positioning among other errors.
Therefore, if you receive this
message, you should be suspicious of the correctness of any I/O to
the file after the incorrect record.

Refer to IBM messages listed in the job log for other
information, and contact SAS/C Technical Support for further
assistance if this condition is not associated with overriding
the file's DCB parameters.

End of file occurred unexpectedly while the library was processing a
file opened for UNIX-style I/O.
This could be caused by several users trying to access the same file
simultaneously, which is generally not supported by OS/390 or CMS.
In other circumstances, it is a SAS/C library internal error.

When a file was opened using the open function for read-only
access, one of the open options O_TRUNC or O_CREAT|O_EXCL
was specified. These options are supported only for files that allow
writing. The open failed.

A file was opened that could not directly support UNIX-style I/O.
For these files, the library creates a temporary file into which
the file to be opened is copied. This temporary file failed to open.
This failure is described by a previous message.

The maximum number of files were opened simultaneously.
The SAS/C library allows up to 256 files to be open at once. However,
note that any call to open for a file that is not suitable for
rel access creates two open FILE pointers.

An attempt was made to close a FILE pointer that
has already been closed, was never opened, or
contains a corrupt FILE pointer value. If this message is received
during program termination, it generally means that FILE
pointers maintained by the library and used at program termination
to close all open files have been corrupted. These FILE
pointers are stored in the PRV (pseudo-register vector) for the
main program load module. The most likely cause
of such corruption is writing beyond the bounds of a __rent static or extern item.

If the message was generated for a call to fclose, correct the
argument to fclose. If the message is issued during program
termination, check the program source for storing outside the bounds of
extern or static data. Variables stored in the PRV
immediately before the library pseudo-register L$CXGIOT are the
most likely to be at fault. (A mapping of the PRV can be obtained from
CLINK if the CLINK PREM option is used, and from the linkage editor if
PREM is not used.)

A maximum of 255 temporary files can be opened simultaneously. This
limit has been reached.
Note that temporary files are opened by the library when UNIX-style I/O
is requested for a file that does not support rel access,
as well as when the tmpfile function is called.

Certain file types do not support trunc=no:
OS/390 PDS members and sequential data sets, including OS sim (file mode 4
and tape) files under CMS,
except for those suitable for rel access
opened as binary. However, if grow=no is used
with these file types, only trunc=no is supported.

A signal was received during an I/O operation, and a signal handler
performed I/O to the same file or used longjmp to avoid
returning to the point of interrupt. This leaves the file in an
uncertain state, and an interrupt flag is set that prevents
further I/O to the file until clearerr is called.

Avoid use of files within signal handlers, and avoid the use of
longjmp for signals that may occur while a library I/O
function is running. If these cannot be avoided, add calls to
clearerr as necessary to allow I/O to continue.

Correct the program or JCL so that a VSAM file is accessed, or modify
the program not to specify a keylen other than 0.
For more details on the keylen keyword
refer to SAS/C Library Reference, Chapter 3, "I/O Functions."

A file opened for access using the rel access method is
larger than (2[32]-2) bytes. Because the file position is
stored in a full word and the bit pattern 0xffffffff is
reserved for an error indication, the file cannot be opened.

Correct the program to use ftell only at record boundaries
when processing a VSAM ESDS.
See Table 3.6 in SAS/C Library Reference, Volume 1,
for information on file types for which seeking is restricted.

The library was unable to successfully convert the file position to
a long integer, the return type of the ftell function.
This indicates that the file being processed is too large or has
records that are too large to allow all possible file positions to be
returned successfully.
See the "File Positioning" section in Chapter 3 of SAS/C Library Reference, Volume 1, for a detailed discussion of how file positions are
transformed into long values.

If it is necessary to seek relative to end of file, access the file
using the rel access method, or use UNIX-style I/O.
See Table 3.6 in SAS/C Library Reference, Volume 1,
for information on file types for which seeking is restricted.

If seeking relative to the current position is required, consider
whether the program can be modified to use binary access and the
rel access method.
See Table 3.6 in SAS/C Library Reference, Volume 1,
for information on file types for which seeking is restricted.

The file or access method does not permit the use of ftell.
For instance, ftell cannot be used with a file open for binary
access unless its return value is the number of bytes from the
start of file. Most files do not permit this value to be readily
computed.

The argument to the function indicated did not point to a
valid open file. The file may have failed to open, or the argument
may have been overlaid. This message is associated with file inquiry
functions like fattr and fnm. After the message the
function returns a degenerate value (e.g., the address of
an all-zero struct fattrib object for fattr).

The fflush function was called for an UNIX Systems Services input file
which does not support seeking, such as the terminal or a pipe.
The call to fflush is successful, but one or more
characters of input data were lost.

The rel access method detected an impossible record number
during processing. This could occur processing a file larger than
2[32]-2 bytes sequentially. Files this size are
not supported by the rel access method.

If the file is smaller than the supported maximum, contact SAS/C
Technical Support. If the file is too large, process it using the
seq access method. See SAS/C Library Reference, Volume 1, for more information on library access methods.

An attempt was made to call ksearch for a stream that did not
permit searching. Searching is permitted only for keyed streams
that allow reading. In particular, a stream opened for wk
or ak does not permit searching.

A call to the ktell or kgetpos function requested
position information about the current record. If there was no current
record (that is, if the previous action on the file was not a call to
kretrv), then the call fails.

A call to a UNIX-style I/O function specified a file descriptor that
was not associated with an open file or socket. This error may be
the result of not checking a call to open or socket
for failure. It may also be caused by overlaying a variable
containing a file descriptor.

While processing a file that allows duplicate keys, an attempt was made
to change the direction of retrieval. That is, a call kretrv
specifying K_backwards was made after a call that did not specify
K_backwards, or vice versa. For files with duplicate keys,
you can only change the direction using a successful
call to ksearch.

The access mode that was passed as the second argument to the
access function
was invalid. Valid access modes are
R_OK (check for read access), W_OK
(check for write access), 0 (check for existence), and
R_OK | W_OK (check for read and write access).
For UNIX Systems Services HFS files, X_OK (check for execute access) is
also honored.

The library was unable to load the requested TCP/IP implementation
load module. The failure should be described by a previous message.
Perhaps the implementation name is misspelled, or perhaps the MVS
library or CMS minidisk containing the load module is not accessible.

If IBM TCP/IP has been installed at your site, run the program
again when TCP/IP has been started and available. This message
can also be the the result of supplying (or defaulting to) the wrong
TCP/IP address space name. The correct name can be supplied in a
number of different ways. Refer to SAS/C Library Reference, Volume 2, for details.

Otherwise, insure that your site's TCP/IP vendor supplied LSCNCOM
module is found in the SAS/C library transient search
order before the IBM TCP/IP version of the LSCNCOM load module
shipped with the SAS/C transient library.

This is a secondary message. Action should be directed toward
resolving problems associated with previous error messages. The
socket library unrecoverable state can be reset by terminating and
reinitializing the current SAS/C environment or by calling the
socktrm function.

An internal error occurred in the SAS/C socket library or a
critical internal function call failed. The usual reasons for
these internal failures are errors returned by IUCV functions dealing
with path establishment or message exchanges with the TCPIP address
space.

Common failures include iutpset rc=1 and/or
iutpconn return code = -1, which indicate a problem
establishing IUCV communication with
the TCP/IP address space. These conditions are known to occur in
association with products that run multiple job steps in a single
address space, such as some popular TSO multi-session products, if
more than one of the job steps attempts to run a socket application.

Another failure that is occasionally seen is iutpset rc=4 or
iutpset rc=5, which indicates a memory protection or addressing exception has occurred in IBM TCP/IP IUCV Platform code attempting to
establish the IUCV path.

Most other failures are rare and SAS/C Technical Support should
be contacted for assistance.

This is an informational message note generated in conjunction
with other run-time TCP/IP error messages relating to IUCV
communication failures with the named virtual machine or
OS/390 address space name.

An IUCV macro completed and stored a failing IPRCODE. Note,
this run-time message is analogous to 477, but applies to MVS
IUCV platforms. The message is most commonly seen when an
IUCVMCOM (OS/390 IUCV Platform macro) CONNECT fails.

Consult the appropriate IBM OS/390 TCP/IP programmers reference for an
explanation of the IUCV return code. Alternatively, consult
VM/ESA CP Programming Services or VM/SP System Facilities for Programming,
since many of the IUCV IPR codes for OS/390 TCP/IP
IUCV Platform Support are not currently documented in the
TCP/IP Programmer's Reference.

A call to fcntl for a socket specified an unsupported command
or option. Only the commands F_GETFD, F_SETFD, F_GETFL and
F_SETFL are supported, unless UNIX Systems Services integrated sockets
are used.

The library was unable to open any more sockets. If UNIX Systems Services is
installed, the maximum number of sockets is controlled by UNIX Systems Services,
and can be changed by modifying the UNIX Systems Services startup parameters
in SYS1.PARMLIB. The limit is 256 if UNIX Systems Services is not installed.

More than MAXNS (6) NSINTERADDR nameserver definition keywords appear
in the IBM TCPIP.DATA file. Only the first MAXNS nameservers found
will be used by the resolver functions defined in <resolv.h>
header file.

Remove any unneeded NSINTERADDR statements from the TCPIP.DATA file.
Having more than two or three name servers to query can result in poor
performance for the TCP/IP resolver functions unless the servers are
properly configured.

If the TCPIP.DATA file is shared among different systems it may be
possible to place a system id prefix to identify the system(s) that
use a particular name server and thus reduce the name server
count on a per system id basis.

Alternately, the name server configuration may be changed so that the
excess name servers are pointed to by other name servers in the in the
configuration, thus reducing the number of NSINTERADDR statements
required.

A syntax error or unrecognized keyword was encountered while
processing the IBM TCPIP.DATA file. The line number and column of the
statement are part of the message. The failing statement is ignored
and processing of the TCPIP.DATA file continues with the next valid
TCPIP.DATA statement.

The library was unable to identify the
specific system executing the application.

For OS/390, this means the system name was not obtainable from the VMCF
entry in the subsystem name table defined by IEFSSNxx member(s) of
SYS1.PARMLIB.

For CMS, the SYSTEM NETID file is not accessible and/or failed to
contain an entry name name for the current CPUID, and the QUERY
USERID command failed to return a recognizable system name for the
current userid.

The command and response code will be a guide for the
action you should take. The response code can be looked
up in the appropriate CICS documentation under EIBRESP.
They are also listed after the command descriptions.
Common responses include NOTAUTH, QIDERR, SYSIDERR,
ISCINVREQ, IOERR, and LENGERR. If necessary, contact
your CICS Systems Administrator or call SAS/C Technical Support.

An attempt was made to open an OS/390 sequential file with open mode
r, rb, r+, or r+b.
The file contained no data
and appeared never to have been initialized. SAS/C treats such
files as not existing.

For a file to be created, it must not only be defined by the
operating system but must also contain data (as recorded in
the VTOC) or, for a VSAM file, have been initialized by writing at
least one record to the file.

This message can be generated when a data set was created
by the operating system via a DD card or TSO ALLOCATE command
immediately before the program containing the failing open was run.

Refer to Chapter 3, "I/O Functions" in SAS/C Library Reference, Volume I, for a detailed discussion of
the SAS/C interpretation of file existence. To correct the problem,
use a file type for which an empty file can be distinguished from
an uninitialized file, such as a PDS member, or ensure that the
input file contains at least a byte of data before attempting to
read it.

An attempt was made to open a file in r or r+ mode
(or some other open mode beginning with r),
and the
file was not found. Either the file does not exist or the
file has been defined but no data has been written to the file.
CMS does not support the existence of files
containing no characters.

Either you are trying to read an extrapartition transient data
destination defined to CICS as TYPEFLE=OUTPUT or
you are trying to write to an extrapartition transient data
destination defined to CICS as TYPEFLE=INPUT.

Processing of a RECFM V file has failed due to incorrect
record or block length information in the file, possibly because of improperly
concatenating a data set with a smaller block size or record length before
a data set with a larger block size or record length.

Make sure the MACLIBs or TXTLIBs in the GLOBAL
list contain the specified member and make sure the member
name is spelled correctly.
Refer to "I/O Functions" in SAS/C Library Reference, Volume I,
for file name specification under CMS for use of
%MACLIB and %TXTLIB file names.

The maximum record length for an OS/390 data set is 32756. The maximum
record length for a CICS spool file is 32760. A larger reclen
was specified, but this was treated by the library as the maximum
permitted.

The library failed to allocate the specified number of bytes of additional memory,
which were needed to read or write a VSAM DIV window. The requested I/O will still be
performed; however, the library will be forced to remap a previously allocated window.

A request was made to reposition the specified file. When
the library attempted to position the file it determined that
the position requested was not valid. This may be caused by
unintentionally writing over the argument to fseek or
fsetpos.

Make sure the file position is valid. If an fseek or
fsetpos argument has become corrupted, consider the use
of the SAS/C debugger monitor command to locate the
problem.
Refer to "I/O Functions" in SAS/C Library Reference, Volume I, for details on file
positioning under CMS.

The run-time library only recognizes one of the above
types of transient data destinations. One possibility
is that the internal CICS transient data control information
has been overwritten with misleading information. If that is
not the case ensure that the destination definition in the
CICS Destination Control Table (DCT) is correct.

The command and response codes will be a guide for the
action you should take. The response code can be looked
up in the appropriate CICS documentation under EIBRESP.
They are also listed after the command descriptions.
Common responses include NOTAUTH, QIDERR, SYSIDERR,
ISCINVREQ, IOERR, and LENGERR. Discuss further with
your CICS Systems Administrator or call SAS/C Technical Support.

The program specified the amparm reclen with a record length
different from the actual record length of the file being opened.
The reclen of a file can
only be changed when the file is opened for output (open mode
w, wb, etc.).

The reclen amparm specified a record length that is inconsistent
with other characteristics of the file being opened.
For instance, the file has
RECFM F, but the reclen does not evenly divide the file's
block size.

The program specified the amparm recfm with a record format
different from the actual RECFM of the
file being opened. The RECFM of a file can
only be changed when the file is opened for output (open mode
of w, wb, etc.).

The I/O-type value can be either update or append.
If the type is update then the file being opened was a unit record device.
These types of devices do not
support update I/O.
If the type is append the file being opened is probably
a CMS tape file. SAS/C does not support appending to a tape file on CMS.

An attempt was made to open an existing PDS member for which
DISP=MOD was specified.
When used with a PDS member, the JCL specification DISP=MOD is
interpreted by OS/390 as requesting a member which does not yet exist.

A CMS FILEDEF specified a LRECL, which is
different from the record length supported by the device being opened.
The library, while
opening the device, noticed the inconsistency and used the record
length supported by the device.

The library determined that the block size requested by the
blksize amparm for a file
being opened
was larger than the device could
support.
The block size was reduced to the maximum maximum-value for the device.

The library detected an incompatibility between the file
characteristics requested via amparms and the actual characteristics
of the file being opened.
The program's request was ignored, and the existing data set's
characteristics were retained.

None required. Refer to Chapter 3, "I/O Functions" in SAS/C Library Reference, Volume I for
information on use of the quiet function to suppress the
message. See the section "Opening Files" for a detailed discussion
of when the library's processing of amparms for existing files.

The record format specified by the program's amparms was not compatible
with the other attributes of the file to be opened.
For instance, the program specified
recfm=f, but the file's LRECL did not evenly divide the BLKSIZE.

The program specified a reclen value, and a spool file
record that was longer than the program specified length was read
by the library. The single long record will be
split and returned to the program in segments.

The library was searching for a GLOBALed OS MACLIB or
TXTLIB. (An OS MACLIB or TXTLIB is considered to be GLOBALed when
it is FILEDEFed using the DDname CMSLIB, and CMSLIB appears in the
CMS GLOBAL list.)
The data set specified was not found.

While opening a RECFM FBS data set for rel access, the
library attempted to read the last record of the file, but a physical
I/O error occurred.
The text is information
obtained from the OS/390 SYNADAF macro.

A file accessed via the rel access method ran out of space.
The library attempted to reopen the file after the failure, but the
reopen was unsuccessful. The file can no longer be accessed, even if
clearerr is used to attempt to clear the error.

One possible cause of this problem is use of the JCL parameter
FREE=CLOSE.

An error occurred opening a GLOBALed OS MACLIB or TXTLIB member. The
CMSLIB FILEDEF defining a GLOBALed OS MACLIB or TXTLIB did not specify
a file mode, which prevents the library from locating the data set.

The library was searching for the virtual address of
an attached tape drive in the CMS device table. The end
of the list was reached without locating the device. The most
probable cause is an internal library error.

An operating system access method, such as BSAM, detected an error.
The text attempts to provide more detailed information on the
failure. This can be the result of a hardware problem.
However, it can also be caused by misuse of I/O functions, such as
attempting to read a concatenated data set where the data set with the
largest block size is not first in the list.

An operating system access method, such as BSAM, detected an error.
The text attempted to provide more detailed information on the
failure.
A seek operation preceded the error; possibly, the error may have been
caused by use of an incorrect seek address.

During file output, a write operation failed because these was no space
left in the file, and the file could not be extended.
For any access method other than rel, any further access
to the file (without closing it and reopening it) is impossible.
However, with rel access it is possible to continue to use the file
after calling clearerr, as long as no attempt is made to add
new records.

An attempt was made to open a data set with RECFM FBS for append (open
mode a, ab, a+, or a+b).
Due to the characteristics of a RECFM FBS data set, it is not
possible to open one for append using the seq access method.

Either add a record to the file before running the program, or correct
the program to use a different open mode, such as w+ or
a+. Refer to "I/O Functions" in SAS/C Library Reference, Volume I, for
information on the meanings of open modes when used with VSAM files.

The library attempted to seek past the end of a CMS RECFM V file and
failed. The
probable cause was the program called fseek or fsetpos
specifying a file position that indicated a record past the current
end of file.

While performing a fsetpos or fseek operation, the
library detected the end of file. Seeking past the end of file is not
supported under OS/390 by the seq access method. This condition
is usually caused by the use of a seek target which is uninitialized
or corrupted.

A call was made to ftell or fgetpos, but a previous error
made determination of the current file position impossible.
A diagnostic should have been generated describing the previous error,
which was probably associated with the errno value EDEVICE.

Remove the DSORG DA attribute from the file. Note, in general using
DSORG DA with files read or written by SAS/C programs should
be avoided. Use of DSORG DA adds no additional capabilities and
results in additional restrictions such as the above.

Make sure the file position is valid. If an fseek or
fsetpos argument has become corrupted, consider using
the SAS/C debugger monitor command to locate the
problem.
Refer to "I/O Functions" in SAS/C Library Reference, Volume I, for details on
file positioning under CMS.

An attempt to dynamically allocate a temporary file failed because
the unit name requested for the temporary file was not known to the
system. The unit name for temporary files is VIO by default; however,
the unit name can be changed by means of a zap described in the
SAS/C installation instructions.

This message normally indicates an internal library error in opening a
temporary file. The message can also be produced if multiple tasks in
an address space are executing the SAS/C debugger, and a SYSTMPDB DD
statement has been defined.

While processing a linear data set, the library issued the DIV macro. The
DIV macro failed with reason code X'E10802', indicating an attempt to
map beyond the end of file. This code usually indicates that it
was not possible to allocate a new extent for the file.

An attempt was made to open a linear data set (LDS) defined with a
SHAREOPTIONS value other than SHAREOPTIONS(1,3). Correct processing
of a linear data set cannot be guaranteed if the data set is shared.
This note is generated to inform the user; however, processing
continues.

Since the results of sharing an open linear data set are unpredictable,
consider redefining the file as SHAREOPTIONS(1,3). To suppress the
message, see the description of the quiet function in the
SAS/C Library Reference, volume 1.

An attempt was made to open a %MACLIB or %TXTLIB file
where the GLOBAL list identified a file on an OS disk. CMS was
IPLed in XA mode, but this form of access to OS disks is supported
only in 370 mode.

An attempt to open a VSAM data set
failed because the data set was in use by another job or user.
This message will be generated even if all users have the data set
allocated with DISP SHR unless sharing is permitted by the
data set's SHAREOPTIONS. Note, however, that SAS/C does not
support sharing of VSAM files by multiple users. If the
SHAREOPTIONS allow sharing, the library will not detect when
sharing occurs, and the results will be unpredictable.

An attempt was made to open and truncate an existing VSAM file
using an open mode beginning with w, such as wb.
The file
was not defined by Access Method Services as REUSABLE, and therefore
the file could not be opened as specified.

An attempt was made to update or delete a record of a VSAM data
set, but the control interval containing the record is held by another
FILE pointer referencing the same data set, or by another task
in the same address space. The other FILE or task must release
control of the interval before the request will be allowed.

The library had to close and reopen a VSAM file to switch from
load mode to update mode. The reopen request failed, and therefore
the file is no longer accessible.
Using the JCL option FREE=CLOSE can cause this error.

A VSAM macro failed with the indicated return code. If the errno
variable is ELIBERR, it indicates a condition the library believes
should not occur. If the errno variable is ESYS, it
indicates a failure which could be either an environmental error or a library
error.

If the errno variable is ELIBERR, contact SAS/C Technical Support.
If the errno variable is ESYS, look up the macro in
MVS/ESA Macro Instructions for Data Sets
and take the action indicated for the return
code.

A VSAM operation failed, generating this reason code. If the errno
variable is ELIBERR, it indicates a condition the library believes
should not occur. If the errno variable is ESYS, it indicates a
failure which could be either an environmental error or a library
error.

If the errno variable is ELIBERR, contact SAS/C Technical Support.
If the errno variable is ESYS, look up the macro in
MVS/ESA Macro Instructions for Data Sets
and take the action indicated for that return
code. (For the operation of temporary close, see the CLOSE
macro description.)

The user attempted to open a KSDS file for output or update in text
or binary mode. This is not supported. The errno variable
is set to EARG if the amparm org=ks is specified;
otherwise, the errno variable is set to EFATTR.

The program attempted to replace a record in a VSAM ESDS or RRDS with
one whose length was different. Changing the length of a record with
kreplace is supported only for a KSDS. Note, that even though an
alternate index over an ESDS can be treated as a KSDS for most purposes,
these files do not support updates that change the length of a record.

Don't attempt to add a duplicate record unless the file is an
alternate path that allows duplicate keys. Note that this message
is suppressed by default, and therefore is generated only when the
run-time option =warning is in effect.

An attempt to dynamically allocate a data set failed. If the error
occurred in osdfind or osdnext, text gives the
name of the file which could not be allocated. If the error
occurred in some other function, the text describes the operation
being performed.

Look up the error codes in the IBM MVS/ESA Application Development Guide: Authorized Assembler Language Programs, and take
appropriate action. If the error codes indicate a programming problem,
this is a SAS/C library internal error.

The remove function called for a DDname that identified
a file whose organization was not physical sequential. For a DDname
that is not a PDS member, remove attempts to empty
the file, but because of the file's organization, this was
not possible.

A call to rename attempted to rename one kind of data set as
another kind. For example, the old name specified a PDS member,
but the new name did not. Renames which change the type of a data
set are not supported. The errno variable is EUSAGE if the error
was in the rename arguments, or EFATTR if the error
depended on the environment (for example, if it occurred because a DDname was
allocated to an HFS file).

A call was made to remove or rename specifying a DDname
that referenced an HFS file. remove and rename are not
supported with DDnames allocated to HFS files unless the
DDname/filename syntax is in use.

An attempt to rename a multi-volume data set was successful on some
volumes but not on others. Each error was described by a previous
message. The library did not attempt to change the catalog or repair
the damage. This must be done by the user or by Systems Programming
Staff.

While removing or renaming an OS/390 data set, the library attempted to
uncatalog the data set. The uncatalog operation failed with a system
error. In the case of remove, the data set was scratched from
the disk before uncatalog was attempted. In the case of rename,
the library attempted to restore the file's original name after an
uncatalog error occurred.

An attempt was made to load a dynamic module, but the module was not
found in any appropriate library. Under OS/390,
the library searches first for the module
in any active tasklibs, then in STEPLIB and JOBLIB, and finally in the
system linklist and LPA. If the module appears to be a library module
(that is, its name begins with LSC or L$), the library also searches the
CTRANS data set.

Under CMS, the library searches DYNAMC LOADLIB, as well as any other
locations specified by a call to addsrch. For run-time library
modules, it searches in LSCRTL LOADLIB on an accessed disk, or
possibly in a run-time library shared segment. For more information
on the CMS search order, see the SAS/C Library Reference, Volume 2.

Confirm that the module name and search order were specified
correctly. Under OS/390, verify that the
correct libraries were specified as STEPLIB or
JOBLIB in the JCL. (If running under the UNIX Systems Services shell, verify
that the STEPLIB environment variable has been defined
appropriately.) Under CMS, verify that the mini-disk containing
any required LOADLIB was correctly ACCESSed.
Refer to Chapter 1, "Dynamic-Loading Functions" in SAS/C Library Reference, Volume 2, for complete details.

An attempt was made to load a dynamic load module that was marked
not executable. This indicates that when the module was link-edited,
one or more errors occurred that precluded load module execution.
(A return code of 8 or greater is returned by the linkage editor
when this occurs.)

Verify that the load module that could not be loaded was linked
successfully, with a return code less than 8. If it appears that
the linkedit was successful, verify that libraries are specified in the
right order in the JCL so that the module is being fetched from
the correct library. If the link edit failed because routines that are
not actually required for execution were absent, consider using the LET
linkage editor option or the C __weak keyword.

Verify that the search element type is one of the symbolic constants
defined for this purpose in <dynam.h>, and that the element
type is appropriate to the operating system. See SAS/C Library Reference, Volume 2, for details.
Note that under OS/390
calls to addsrch specifying a CMS search element type are
ignored, and no diagnostic is generated.

The function delsrch was called to delete a search element from
the search list. The search element was not valid or has already
been deleted. This message may indicate that the search element has
been overlaid.

One of the timing functions such as localtime attempted to
determine the difference between local time and Greenwich time. This
attempt failed, probably because of a hardware time-of-day clock
failure. The library assumes that local time and Greenwich time
should be the same.

Specify a valid system command prefix. If the system command
to be executed has a colon in its first nine characters, add the
default prefix to the start of the command to keep the text before
the colon from being interpreted as a prefix.

A call to system attempted to invoke a program or command longer
than 8 characters, which is the maximum supported by OS/390. Note
that the error may be in a CLIST or REXX EXEC invoked by the
system function as well as in the argument to system.

A program or TSO command invoked by the system or oslink
function, or by one of the OS/390 SUBCOM functions, abnormally terminated.
In the case of system, the failing command may have been
specified by a CLIST or REXX EXEC rather than by the caller of system.

This message generally indicates a problem with the program or command
being invoked, not with the caller of oslink or system.
For a system code, refer to MVS/ESA System Codes for further
information on the ABEND. If the program being invoked is a SAS/C
program and the ABEND code is in the range 1200-1240, see
Library ABEND Codes for further information.
For other user ABEND codes, see the documentation for the program being
invoked, or for other products used by that program
(for example, FORTRAN or DL/I).

An invocation of the system function to run a TSO command
detected an invalid TSO command name. The invalid name may have been
specified in a TSO CLIST or REXX EXEC rather than by the argument to
system.

An attempt was made to handle a signal that is not supported in
the current environment, for example, SIGINT in OS/390 batch or CICS. The
call to signal or sigaction indicates success, but the
only way the signal can be generated is using the raise
function.

Correct the program so that it does not attempt to handle signals that are not
supported by the expected environment. Also, see the SAS/C Library Reference, Volume 1, for information on using the quiet
function to suppress unwanted run-time messages.

If you have edited or modified the PERMANENT scope environment
variable file (normally called C@ENV.PERM), correct the file.
Otherwise, contact SAS/C Technical Support. See the SAS/C Library Reference, Volume 1, for information on the contents of this
file.

An environment variable function such as getenv encountered an
unexpected end-of-file trying to process the TSO permanent environment
variable file (normally called C@ENV.PERM). Any incomplete data was
ignored.

The library failed to allocate the TSO PERMANENT scope environment
variable file. For a call to getenv, the library assumes
there are no PERMANENT scope variables. For a putenv or
setenv call, an error is indicated to the caller.

Look up the DYNALLOC error code in MVS/ESA Application Development Reference: Services for Authorized Assembler Language Programs and take appropriate action. If the code
indicates a programming problem, contact SAS/C Technical Support.
For information on how the library allocates and uses the environment
variable file, see the SAS/C Library Reference, Volume 1.

This may be caused by allocating a file to the DDname C@ENV that
does not have an appropriate DCB (RECFM VB, LRECL 259). Check the
file's DCB, and also check the OS/390 console log for message IOS000I,
indicating a hardware problem. If a hardware problem is indicated,
report the message to your site's Systems Programming Staff.

The response code should indicate the action to take. Response codes
can be found in the appropriate CICS documentation
under EIBRESP and are listed after the READQ and WRITEQ command
descriptions. For example, a response code corresponding to NOSPACE
occurs when insufficient space is available in the temporary storage
data set, while a response code corresponding to IOERR occurs when there
is an unrecoverable I/O error in the temporary storage data set.

The putenv or setenv function was called to update a
PERMANENT scope environment variable in a program running under
the TSO terminal monitor (IKJEFT01) in batch,
but there was no C@ENV DD
statement defined. PERMANENT scope environment variables can be
accessed in batch only when running under IKJEFT01, and only
if a C@ENV DD statement is present.

A call to putenv or setenv failed because an ancestor
task of the C program failed to share TSO subpool 78 properly with
its subtask. Full SAS/C TSO environment variable support is dependent
on proper sharing of subpool 78.

Determine the program that is failing to share subpool 78 with
its subtasks, and correct that program. If this is not possible,
modify the program not to call putenv or setenv to
update non-PROGRAM scope environment variables.

Environment variables are stored in the first record of a temporary
storage queue. The stored variables are preceded by an identifying
header. In this particular instance, the temporary storage queue
identified by name was found to contain a record which did not have a
recognizable header. The SAS/C library assumes that the named queue is
being used for some other purpose and cannot be used to
store or retrieve environment variables.

The default queue name used by the library is the VTAM luname associated
with the transaction. If the named queue is already used for something
other than storing environment variables, then modify the code in the
user-replaceable module L$UEVQN to choose a different name for the
library to use.

The environment name passed to execinit is not supported by the
command language (CLIST or REXX under TSO, REXX under UNIX Systems Services).
The environment name is limited to 8 characters, which must be
alphabetc, numeric or national ($, # or @) characters.

The indicated CMS macro failed, producing the indicated return code.
If the message is a NOTE, execution was able to proceed, ignoring the
error. If the message is a WARNING, the function that detected the
error returned failure to its caller.

Refer to the CMS Application Development Reference for Assembler
for an explanation of the return code and take appropriate action.
If the return code indicates a programming problem, contact SAS/C
Technical Support.

SUBCOM applications can only be run under TSO or when UNIX Systems Services
exec-linkage is in use (for instance, under the UNIX Systems Services shell).
To run a SUBCOM program
in OS/390 batch, consider use of the background TMP (IKJEFT01).

The function execinit was called to initialize a non-interactive
SUBCOM environment, but the program was not called directly from CMS.
(For instance, it was called by an assembler language routine.)
The non-interactive SUBCOM mode is supported only for programs called
directly from CMS.

While scanning the list of functions passed to cmsrxfn, the
library found a function with an extended name. The extended names
CSECT is not present, presumably because it was deleted during
CLINK/COOL
processing. cmsrxfn is therefore unable to determine the
function names to be passed to REXX.

A call to execshv requested that a CLIST variable be updated,
but the CLIST language does not support update of this variable.
Probably the variable is a CLIST &SYS... constant symbol such
as $SYSTIME.

Explanation

An attempt was made to use one of the functions execcall,
execid, execget, or
execrc in a child
process created by a TSO address space. A child process of a TSO address space
is not itself a TSO address space, and therefore these functions can no longer
be called.

Action

Change the program not to call any SUBCOM functions in a
child process. The execend function can be
called in this situation, and it will release any resources previously allocated
by the TSO SUBCOM interface.

Check the job log for OS/390 messages giving further information about the
failure. If running in TSO, specify PROFILE WTPMSG, which causes many
OS/390 messages to be displayed at the terminal, and run again to get
further information.

The value specified by the named keyword in the osdynalloc keyword string was not recognized. The named keyword is
restricted to a small set of values. For example the DYN_ALLOC
keyword status is only allowed a value of OLD,
NEW, MOD, or SHR.

The value specified by the named keyword in the osdynalloc
keyword string included an unrecognized character. The named keyword
is restricted to a string of characters from a specific set. For
instance, the specification recfm=vby is rejected because
y is not a meaningful RECFM specification.

The value for the named keyword in the osdynalloc
keyword string was not specified correctly. For example, the
value for the expdt keyword did not match any of the permitted
formats: yyddd, yyyyddd or yyyy/ddd.

The value for the named keyword in the osdynalloc
keyword string was specified as an incomplete data set name, starting
with a period. The library was unable to determine the OS/390 user id
associated with the job, and therefore the name could not be completed.

A request was made to open a tso or cms style file name in a
non-TSO environment, and no userid could be determined. This
usually means one of two things: the site is not running a
RACF compatible security product; or the program is running
as an OS/390 started task, and the security system has not been
configured to define a userid for started tasks.

Look up the error codes in the IBM MVS/ESA Application Development Guide: Authorized Assembler Language Programs and take
appropriate action. If the error codes indicate a programming problem,
this is a SAS/C library internal error.

During the opening of a dsn or tso style file name, the data set
was allocated, and then open failed for some reason described by a
previous message. When the library attempted to free the allocation
after the previous error, the DYNALLOC SVC failed.

Look up the error codes in the IBM MVS/ESA Application Development Guide: Authorized Assembler Language Programs and take
appropriate action. If the error codes indicate a programming problem,
this is a SAS/C library internal error.

An attempt was made to open a tso or dsn file name for writing.
The file was already allocated and was shared with another job or
user. The library was therefore unable to get exclusive use of the
file.

Run the program when no other users are using the file. Alternately,
access the file via a DDname, which can be allocated SHR and shared
with other users. (However, note that only one job or session should
have the data set open at a time, or the effects are unpredictable.)

Run the program when no other users are using the file. Alternately,
access the file via a DDname, which can be allocated SHR and shared
with other users. (However, note that only one job or session should
have the data set open at a time, or the effects are unpredictable.)

An attempt was made to create a file whose name conflicts with the
name of an existing file. For instance, an attempt was made to
create FRED.MASTER.DATA when FRED.MASTER already exists. Note that
this condition occurs only when the created file is cataloged in a
CVOL.

A request was made to create a data set as a PDS/E, but the operating
system does not support PDS/E. (MVS/ESA 3.2 is required.) The data
set is created as a regular PDS, and no error is indicated to the
caller of afopen.

The library was unable to create a new VSAM data set because the
amparms did not specify a key length or specified keylen=0.
Note, if you open a non-existing file for keyed access, it is assumed
to be a KSDS unless you use the org amparm to specify differently.

UNIX Systems Services must be installed and active to call this function.
This message may also be generated if a program linked with a version of
the SAS/C Library which did not support UNIX Systems Services attempts to use
an UNIX Systems Services service, such as opening an HFS file.

An attempt was made to access a standard file descriptor (0, 1
or 2) that was allocated to
some other file descriptor. The requested file descriptor
number was not in use. This situation can arise only in unusual
circumstances, generally involving the freopen function.

A pathname passed to an UNIX Systems Services function was too long or
contained a component which was too long. The maximum length
of a path name under UNIX Systems Services is 1024 bytes; the maximum
component length is 255.

When a non-integrated socket is accessed, the library opens a
shadow file of /dev/null to prevent UNIX Systems Services from reassigning
the file number assigned to the socket. This diagnostic is
issued if this open fails. Note that this condition also causes
the socket access to fail.

Look up the error codes in the IBM MVS/ESA Application Development Guide: Authorized Assembler Language Programs and
take appropriate action. If the error codes indicate a programming
problem, this is a SAS/C library internal error.

An attempt to open a DDname allocated to an HFS file failed because
the open mode conflicted with the PATHOPTS specified on the DD
statement. For example, the program attempted to open the file for
reading, but PATHOPTS specified OWRONLY.

An exec-linkage program attempted to open a DDname identified
by an environment variable, but the file could not be allocated.
Possible reasons for this failure include data set name invalid,
member name invalid, data set not found,
data set in use, reserved DD name, and
denied by installation exit.

An exec-linkage program attempted to open a DDname identified
by an environment variable, but the file could not be allocated due
to an unusual condition. If the errno variable is ELIBERR,
the failure was an internal library error.

Look up the error codes in the IBM MVS/ESA Application Development Guide: Authorized Assembler Language Programs and
take appropriate action. If the error codes indicate a programming
problem, this is a SAS/C library internal error.

An exec-linkage program attempted to open a DDname identified
by an environment specifying an HFS file, but the file could not be
allocated. The errno variable value and reason code identify the cause of the
failure.

Consult the list of errno values in Appendix 2, "ERRNO Values" and take appropriate action.
The reason code can
be looked up in Assembler Callable Services for UNIX Systems Services OS/390
for further information. This message may indicate a
problem within UNIX Systems Services OS/390.

Correct the program so it specifies an appropriate file name. Note
that if the application is not compiled with the posix
compiler option, an explicit style prefix of hfs: is required
to access an HFS file (unless hfs is the default style).

Avoid accessing a non-integrated socket opened by a parent in a
child process except to close it. Consider the use of integrated
sockets for programs which call fork. See SAS/C Library Reference, Volume 2 for information on the setsockimp
function, which can be used to request the use of integrated sockets.

While the system function (called to invoke an UNIX Systems Services
shell command) was waiting for a child process to terminate, a signal
was received; the signal handler called longjmp,
terminating system without allowing the child process to
terminate.

An UNIX Systems Services function returned an errno variable value whose meaning
was not defined at the time this information was prepared. This message
is only generated if the =warning run-time option is
specified.

The library determined that it was not possible for the program to
access any UNIX Systems Services services. The most likely cause of this message
is that your site has not defined your RACF user id or RACF group id to
have an UNIX Systems Services uid or gid.

Action

A call to oesigsetup occurred after some other signal-handling
function was called. Except for signal set manipulation functions
like sigemptyset and sigaddset, oesigsetup
must be the first signal-handling function call. The late call to
oesigsetup is ignored, and the default division of signals
between the SAS/C library and UNIX Systems Services OS/390 is in effect.

A call was made to the alarmd or sleepd function in
a program for which SIGALRM is managed by UNIX Systems Services. These
functions are supported only when SIGALRM is managed by SAS/C. The
time interval is rounded down to the nearest second, and the
corresponding standard function is called; in the case of
alarmd with a nonzero argument less than 1, the signal
SIGLARM is raised immediately.

Either change the program to allow management of SIGLARM
by SAS/C, or replace the call to alarmd or sleepd
with a call to alarm or sleep. Also note that the
select function can often be used in place of sleepd.

An attempt has been made to define a handler for the SIGINT
signal. SIGINT is defined as managed by SAS/C, but the
program was invoked by exec or is a child process
created by fork. SAS/C SIGINT handling is
effective only in a TSO address space.

Either define SIGINT as managed by UNIX Systems Services, or avoid
defining a SIGINT handler in a non-TSO address space. The
intractv function can be used to test whether a program
is running in a TSO address space. See SAS/C Library Reference, Volume 2.

A sigaction or signal call has been made for an
UNIX Systems Services signal, but the program does not have exec-linkage,
and no call to oesigsetup has been made. By default, a
non-exec-linkage program is not able to handle
UNIX Systems Services signals.

The process running the SAS/C REXX interface for UNIX Systems Services was
terminated by a signal. Note that when this message is issued, the
interface to UNIX Systems Services REXX has been disabled and any call other
than execend will fail.

The process running the SAS/C REXX interface for UNIX Systems Services was
terminated by an ABEND. Note that when this message is issued, the
interface to UNIX Systems Services REXX has been disabled and any call other
than execend will fail.