To check: a/ The defer=yes should be in libname definition for all users. It only saves netezza sessions for users that could go to netezza but are not doing that. b/ The sharing of sessions should be set up and tested for each user going to netezza. Every call can cause one or multiple netezza sessions, it is better to maximize this usage for 1 shared read. SAS/ACCESS(R) 9.4 for Relational Databases: Reference, Third Edition ( unique is the default setting for the connection= SAS/ACCESS(R) 9.4 for Relational Databases: Reference, Third Edition (LIBNAME Statement Specifics for Netezza) This will cause many sessions to be openend to Netezza (same with other RDBMS ones). c/ The use of the EG query builder can be done of the use of libnames or with explicit pass though. The use of libnames is more easy with EG not needing building a new netezza session. It has the disadvantage of possible SQL problems ANSI/Netezaa specific. Sharing netezza sessions between libnames is another topic. Use of SQL-pst will cause additional netezza sessions and the EG-builder can fail to generate correct netezza SQL. How far did you come in pinpointing your problem? I only read "defer=yes" does not help and the netezza DBA is not helping with higher limits,12 is really a low limit. Saying netezza is not able to support more than 12 concurrent users. What about all other config settings and debugging their effects? Running SAS with EG6.1 could cause multiple SAS sessions being used (parallel execution) each of them needing a netezzaa connection.
... View more
