Chapter Contents

Previous

Next
Systems Programming with the SAS/C Compiler

SPE and USS

This section provides miscellaneous information about systems programming under USS. Refer to SAS/C Library Reference, Volume 2 for additional information about USS and SAS/C POSIX support.


USS Interface

All uses of USS system calls in SPE are routed through a single function, L$CUBPX, with the exception of a few signal-handling calls. In addition to issuing the requested system call, L$CUBPX is responsible for translating USS error codes into SAS/C error numbers and for detecting failures in USS itself. L$CUBPX is provided in source (member L$UUBPX in the SPE source library) to allow it to be tailored if necessary.


Timing Functions

The SPE library does not support POSIX time zones. Time zone information is determined exclusively by the SPE L$UTZON routine.

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 the timing of signal delivery is different under SPE than with the library. When an USS signal is delivered to an SPE program, the signal handler is invoked immediately, in contrast to the library case, where the signal is delayed until the signal can be discovered. Because signal handlers can be called at any time, you may need to block signals during critical sections to prevent interruptions at inconvenient times.

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.

A number of SPE signal-handling routines are supplied in source to support user enhancements. The source modules are
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.