Chapter Contents |
Previous |
Next |
Systems Programming with the SAS/C Compiler |
USS Interface |
Timing Functions |
The support for the
_epoch
external variable is available
in SPE as well as in the regular library. Note that the SPE default epoch
is the UNIX epoch beginning January 1, 1970. This is the same default as
for the regular library.
HFS Access |
SPE supports
access to Hierarchical File System (HFS) files using the low-level routines
such as
open
,
read
,
write
,
lseek
, and so on. Note that when you use SPE, these functions can only
access the hierarchical file system; that is, you cannot use these functions
to access OS/390 data sets or sockets. Filenames passed to
open
and other POSIX functions
should always specify a POSIX filename. Style prefixes will be treated as
part of the filename, and a leading
"//"
prefix will be treated as if
it were a single slash.
When an USS SPE application receives control from the
exec
system call, file descriptors 0, 1, and 2 are normally passed by the caller
of
exec
. The SPE library does not use or require these file descriptors,
but they are available for the use of the application.
Note that HFS I/O can only be performed using low-level
POSIX functions, as the standard I/O functions are not supported in SPE. The
POSIX functions
fdopen
and
fileno
are also not available, since they are used in the context of
standard I/O.
SPE supports access to USS integrated sockets using
the standard UNIX socket interface functions such as
socket
,
accept
,
read
,
write
, and so on. Note
that only integrated sockets can be accessed. Also, TCP/IP configuration information
functions, such as
gethostbyname
and
getservent
, are not supported because USS does not
provide system calls for these functions.
Environment Variables |
Environment
variables are now supported by SPE for both USS and
other applications. However, the only way to create an environment variable
in SPE is to call
putenv
or
setenv
. That is, there is no library processing to copy environment
variables from any external source. Note that for programs called via the
exec
system call, the L$UOEEP start-up routine is responsible for setting up the
environment variables passed by
exec
.
Environment variable names are always case sensitive when SPE is used.
Signal Handling |
SPE supports USS signal
handling. Only signals supported by USS can be handled. (For instance, the SAS/C signal
SIGMEM is not supported in an SPE environment.) Further, only functions defined
by the POSIX Standard are supported. For instance, you can use the
sigaction
,
kill
, and
sigprocmask
functions in an SPE application but not the
signal
,
raise
, and
sigsetmask
functions, which
are defined by ANSI or by SAS/C, not
by POSIX.
Note that when you use SPE, the signals SIGILL, SIGSEGV,
SIGFPE, SIGABRT, and SIGABND are not by default associated with program checks
and ABENDs, as in the standard library. Your application will receive one
of these signals only if sent by some program using the
kill
function. If you
want an SPE application to handle program checks or ABENDs, you can use the
SPE-only function
oeabntrap
, which issues an
ESTAE
macro to define an exit that transforms any
recoverable ABEND into an appropriate USS signal.
oeabntrap
also enables
an interface to the USS
ptrace
system call, which allows an SPE program to
be debugged (as an assembler program) by the IBM
dbx
debugger.
L$UZABN |
oeabntrap
interface |
L$UZEST |
oeabntrap
ESTAE exit and retry routine |
L$UZOEI | initialize and terminate USS signal handling |
L$UZSIA | define a signal handler |
L$UZSIR | invoke a signal handler on receipt of an USS signal |
L$UZSIR contains both a signal interface routine (SIR),
which is called by USS when a signal occurs, and L$UZRTE, a routine which
is given control by the SIR using
bldexit
linkage in order to invoke the user's handler.
fork Function |
SPE supports the use of the
fork
function. The
atfork
SAS/C
extension
is not supported. However, a CRAB field CRABFKCT is defined to allow the
application to be aware of the use of
fork
. CRABFKCT is initialized to zero.
Whenever a fork occurs, it is incremented by one in the child process. This
allows a function to determine whether the process id has changed as the result
of
fork
. Such checks may be needed due to the fact that many OS/390 resources
(for example, timers) are not copied to a child process.
POSIX Compiler Option |
Whether or not
the POSIX compiler option is used has no effect at runtime on an SPE application.
It still has its other compile-time effects, such as defining
_SASC_POSIX_SOURCE
and
implying the
refdef
option.
Chapter Contents |
Previous |
Next |
Top of Page |
Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.