[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

696.0. "pgflquota and excpetions from VMS$IEEE_HANDLER.EXE" by LOWFAT::DIETER () Thu Jun 05 1997 15:09

A customer, SAS, has posed this question to me.  Although they have already
contacted customer support, they say they cannot implement the suggestions 
from customer support and are looking for other ideas.  Does anyone have any
suggestions I can relay?

thanks, 
Mary


*****************************************************************************

Several months ago, a site called Technical Support and reported the following
errors were being generated when a SAS job was executed in batch mode on
an alpha machine running SAS Release 6.09 TS027 under OpenVMS 6.2:

   %SAS-F-INTSASERR, a SAS error has occurred
   %SAS-F-CALLREP, please contact your SAS Site Representative
   %RMS-F-CHN, assign channel system service request failed
   -SYSTEM-F-NOIOCHAN, no I/O channel available

The user's parameters and quotas were as follows:

   channelcnt=300; fillm=255; bytlm=64000; procsectcnt=300

The system admin at this site noticed that right before the SAS job access
violated, only 75 channels were in use.  Then there were ~200 calls to the
VMS$IEEE_HANDLER.EXE image.  After the system admin increased the pgflquota
to 197904 the SAS job ran successfully.

The system admin reported this problem to Digital to determine why so many
calls were made to the VMS$IEEE_HANDLER.EXE image.  Problem C961107-413 was
opened at Digital by Jeff Chisolm and the system admin was told the failure 
was an application or configuration issue.  He concluded this from an article 
on file at Digital:  MONITOR CLUSTER Fails w/Many Open Channels to 
VMS$IEEE_HANDLER.  The VMS$IEEE_HANDLER is installed by default in OpenVMS 
6.2 and OpenVMS 6.2 is installed at this site.

According to DEC Engineering, the problem is due to an exception when the
VMS$IEEE_HANDLER image fails to execute.  Since the SAS code is compiled
with /float=ieee and no /ieee_mode is specified, it defaults to FAST and
because of that, the system won't pass an error to the application if the
result of a floating point computation is an error.

As a solution to this problem, it was requested that SAS specify the
IEEE_MODE option when compiling code.  Unfortunately, our developers cannot
change the way the SAS code is compiled on OpenVMS.  I was told by SAS 
development that "we MUST be able to trap overflows and divide by zeros and 
do something about them, and the only one of these modes that allow that to 
happen is FAST.

Do you think there is anything else that can be done (other than having sites 
that encounter this problem increase their pgflquota to a large value) to
resolve this matter?

T.RTitleUserPersonal
Name
DateLines
696.1CSC64::BLAYLOCKIf at first you doubt,doubt again.Thu Jun 05 1997 16:5113

Try 

$ install add /open/share sys$share:vms$ieee_handler

If the SAS image (or one of its shareable images) is installed with /PRIV
the exception code may not be able to load (LIB$FIND_IMAGE_SYMBOL/$IMGACT)
the image if it is not installed.  Thus every exception trys to open
the file again and you run out of channels.

I found this information from the COMET server at:
	http://encke.alf.dec.com/cgi/v4.2
696.2suggestionCSC32::J_CHISHOLMVMS INTDRV, CSC/ColoradoFri Jun 06 1997 12:0815
    Gosh, I never thought this call would surface again.
    
    We elevated this call to Engineering, delivered their response to the
    customer (Westinghouse) and SAS.  The real solution is to make the
    IEEE handler part of the exception execlet.  No additional pgflquota
    required.  Engineering said they'd include that fix in a version after
    v7.1
    
    If SAS isn't happy with the other /ieee_mode settings and the pgflquota
    workaround isn't acceptable, let's get this back to Engineering via
    the IPMT process.  
    
    Regards,
    Jeff Chisholm
    CSC/Colorado