Fopen limitaion in solaris

Standard C Library in solaris uses unsigned char to hold file descriptor. This puts a limitation on number of files that can be opened from a process (256). Whereas WinNT uses int for holding the file descriptor. Can
we any way overcome this limitation and still use standard library?
-jimson

Hi ,
There is an open RFE on this with RFE id # 1085341 to be considered
for a future release on this issue.
You can try using 64-bit Solaris 7 or 8 as a workaround.
Thanks,
Gopinath.

Similar Messages

Fopen() on solaris 7 and solaris 8

Hi,
When I am trying to open more than 255 files using fopen()
call, I am getting the different behaviour on solaris 7 and
solaris 8. On sol 7 it returns 0 and errno set to 0. On
sol 8 it returns 0, but errno set to 24. My application is
using value of errno to implement the code to allow users
to open more than 255 files. But it is failing on solaris 8
becoz of the above behaviour. Is there any change in fopen()
call?
I have to fix my application ASAP. Any help in this regard
will be greatly appreciated.
regards,
vinod.

Hi Vinod,
The err no 24 being returned by Solaris 8 is correct.
if rlimit has been adjusted to greater than 256 fds, and
fopen()'s call to open() returns a descriptor value greater
than 255, fopen() used to return NULL but did not set
the errno. hence it was fixed to set the errno to EMFILE
which does correctly say " Too Many open Files".
HTH
Shridhar

How to use Linux Print queue in client_text_io.fopen to print from Windows

We have a forms application deploed on LINUX (Oracle application server 10g).
I have to print a file from local windows PC to a linux Print Queue from forms
I have the following code
PROCEDURE file_to_printer (i_filename_output IN VARCHAR2
,i_network_printer IN VARCHAR2) IS
l_line VARCHAR2(2000);
l_fileid_output client_text_io.file_type;
l_fileid_print client_text_io.file_type;
BEGIN
l_fileid_output := client_text_io.fopen (i_filename_output,'R');
l_fileid_print := client_text_io.fopen (i_network_printer,'W');
WHILE 1 = 1 LOOP
client_text_io.get_line (l_fileid_output, l_line);
client_text_io.put_line (l_fileid_print, l_line);
END LOOP;
EXCEPTION
WHEN NO_DATA_FOUND THEN
client_text_io.fclose (l_fileid_output);
client_text_io.fclose (l_fileid_print);
END file_to_printer;
Everything works fine if I use a windows printer like \\machine\printer.
I want to use a Linux printer and specified the print queue as
\\machine\print_queue_name. It's not working
and I get error ORA-302000 on the following line
l_fileid_print := client_text_io.fopen (i_network_printer,'W');
and if I give only the queue name no error but it's not printing.
Could you please tell me how to use a Linux/Unix print queue in this situation

the simplest way is to edit the interface file (look in /etc/lp/interfaces for existing printers). Each script is
run per print job where stdin has your print data, and stdout is going to your print device. You can just
send the output to a file instead (assuming you can create a file in the windows directory from the solaris
box). If it's a network share, you could use smbclient.
-r

File Name error when creating file in Solaris C locale

Background Info:
1.In Java, we can use new File(filename) to create a new file. The filename there is a string denoting the name of the new file.
2.As mentioned in bug4409965, "The 'C' locale in a 7-bit ASCII locale, the 8bit characters enteredn are not read in properly probably because in that locale, the input byte stream is expected to contain only 7bit characters, anything else is 'garbage'".
My problem is:
when I tried to construct a filename containing non-ASCII characters in the Solaris C locale, Java works quite different from C language.
To be specify, follwing c code works quite well in C locale:
char * temstring = "\0xd6\0xd0";
FILE* fd = fopen(temstring, "w+");
fprint(fd, "test");
fclose(fd);
Although the created file can't be viewed in C locale, the filename shows quite well in other suppoted locale , which means the filename doesn't get modified.
While in Java, the following code
File f = new File("\0xd6\0xd0");
fos.println("test");
try {
f.createNewFile();
} catch (IOException e)
System.err.println(e.toString());
will generate the file in C locale as ???? as garbage file name. Even in the proper locale, the filename can't be read correctly.
I doubt the JVM in Solaris (file unixfilesystem.c) has modified the input filename and made the filename unreadable.
I just wonder if there is some workaround to solve this problem, which means I can correctly generate the filename using Java just as what the C code has done: create the file just as what I denote instead of modifing the filename.
Thanks

Hello:
Any luck with this problem?
I am facing the same problem and was wondering if you had found a solution....
Thanks
Kiran

8i on Solaris hangs during xa_open

I just installed 8i on solaris 2.7. I start the database and then run my tried and true transaction app which calls xaoopen_help and then hangs. When I peek at the stack, I see the following... Any ideas what might be problem? Thanks
----------------- lwp# 1 / thread# 1 --------------------
fe397d34 lwp_sema_wait (67e80)
fe12b044 _park (67dd0, 67e80, 0, 1, fe14d298, 0) + 10c
fe12ad38 _swtch (5, fe14c524, 67e60, 67e5c, 67e58, 67e54) + 350
fe129ae0 condwait (fe3b8080, fe14dee8, 4356, fe14c524, fe3b3bb0, fe12d024) +a4
fe12d024 rw_rdlock (fe3b8060, 5000, fe14c524, 5257, fe3b3bb0, fe3b8080) + ac
fe38b0e4 fflushu_iops (0, 1, fe3b3bb0, ff3dfd30, fe3b3bb0, fe339388) + 2c
fe33944c abort (fe3b3bb0, 0, ff360fb0, fe38abc0, fe3b3bb0, fe392024) + e0
fe39207c rmutexunlock (fe3b7870, 1, 0, fe38b5e4, fe3b3bb0, fe12d144) + 68
fe38b508 getiop (0, fe3bb7ec, fe3b7870, fe3b8044, fe14dee8, fe38abc0) + 11c
fe38abe4 _findiop (fe7638dc, 13, fe3b3bb0, fe3b8058, fe3b8044, 678c0) + 4c
fe38b5e4 fopen (ffbe7ae8, ffbe7bec, 0, 4, 61, ffbe7ae8) + 4
fe7638dc snlfohd (ffbe7cf4, 1, fb360, 2a, fa83c, fa84c) + 88
fe759e08 nlpardfile (fa84c, fa818, ffbe7fd8, ffbe7cf4, 0, fb360) + 148
fe757358 nlpains (ffbe873c, ffbe805c, 0, ffbe7fd8, 0, 0) + e4
fe7576ec nlpainso (ffbe873c, ffbe805c, 0, ffbe7fd8, 0, 0) + 60
fe760178 nlstdlp_load_psource (fea7beb0, ffbe8cf4, 0, ffbe8210, 2, 0) + 108
fe75d688 nlstdggo (0, ffbe8cf4, ffbe89d0, 100, ffbe89cc, 2) + 1d4
fe67b15c nigini1 (ffbeb53c, 2a7c, 0, 2800, fea37914, fe9f4288) + 220
fe5e8880 osncon (0, 1803, 0, 0, 0, 0) + 518
fe515874 upiini (f786c, 1400, f574c, f408c, f3fe8, f646c) + 288
fe5068f4 upiah0 (f3fe8, 0, 0, 0, efcb0, 1000) + 3c
fe5161b8 kpuatch (f3fac, 0, f574c, efb18, f3fe8, 0) + 288
fe567c38 OCIServerAttach (f3fac, f41d4, 0, 0, 0, 0) + 1c
fe571c0c xaolgn_help (ffbec4d4, a0b0, ffbec4dc, 0, fea37914, ffbec4e0) + 380
fe57241c xaolgn (cdb28, fea37914, 0, cdb28, 0, fea37914) + 34
fe56cc1c xaoopen_help (a0b0, 0, 0, 0, fea37914, ffbec7b7) + 538
fed34714 tpopen (ffbec7b7, fedbe84c, 0, fec6d2e8, fedbbd4c, 6ee28) + 514
fed5c54c tx_open (6ed58, fedbbd4c, 76420, 0, 6ee28, ff332d8c) + 178
ff1453d8 __1cCTPKopen_xa_rm6F_v_ (ff16835c, ff30b700, ff334adc, ff3e1d6c, 4, ff33484c) + 14
00041054 __1cTbegin_transactional6F_v_ (ffbecf88, 5349c, bd, 534a8, 2d41, ff00)+ 4
000417e4 __1cGServerKinitialize6Mippc_c_ (6e968, e, 7f268, 38, ffbeec4c, ff16835c) + 2c
ff130104 __1cHOrbMainHstartup6Mippc_v_ (7f218, ffbeec4c, 6ee28, ff16835c, 7b730, 6ed58) + 4f4
ff130fc8 __1cLserver_init6Fippc_i_ (7b730, 7b730, ff16835c, 0, ffbeec4c, e) + 50
000424e8 tpsvrinit (e, ffbeec4c, 63ba4, 6eee8, 6ee28, 1) + 18
fed4bfdc _tmmain (fed4e1c4, ffbeec4c, 1, fedbe84c, 0, fed11fc4) + 4a8
fed3cc74 _tmstartserver (fedbbd4c, 6ee28, ffbeec4c, 644e0, fe3b3bb0, fe3201e0) + a8
00020924 main (e, ffbeec4c, ffbeec88, 64400, 0, 0) + 64
0001d740 _start (0, 0, 0, 0, 0, 0) + b8
----------------- lwp# 2 / thread# 2 --------------------
fe397704 signotifywait ()
fe12f590 _dynamiclwps (fe14c524, fe14de3c, 2, 0, fe3b3bb0, fe3b3bb0) + 1c
fe392a78 thr_errnop (0, 0, 0, 0, 0, 0) + 24
----------------- lwp# 3 --------------------------------
fe397ce8 lwp_cond_wait (fe150c10, fe150c20, fe3d5c40)
fe38fa78 lwpcond_timedwait (fe150c10, fe150c20, 0, 3a0326b1, 0, 0) + 90
fe12a728 _age (fe14c524, fe14d28c, 0, 0, 0, 4) + 90
fe395338 doorreturn (fe14db28, fe14db40, 3, fe14c524, fe3d5d08, fe12bc18) + 68
----------------- lwp# 4 --------------------------------
fe3952dc door (0, 0, 0, 0, fe0b5d68, 4)
fe12bc18 lwpstart (0, 0, 0, 0, 0, 0) + 14
-------------------------- thread# 3 --------------------
fe12e64c reapwait (fe14e070, 1e184, 0, 0, 0, 0) + 34
fe12e3d0 _reaper (fe14c524, fe14e070, fe14d308, 67e5c, 1, fe400000) + 34
fe13b824 threadstart (0, 0, 0, 0, 0, 0) + 40
null

I had the same symptom from a multithreaded C++ application
until I added the -mt option to the CC command when linking.
You are supposed to use it for compiling, too.
Louis Warshawsky
Computer Associates

InBuilt Apache Web Server v2.0.58 on Solaris 10

Hi,
We are working on a custom application which works with the inbuilt Apache Web Server on the Sun Solaris platform. Here are the details of the versions of the various components involved:
Apache Web Server: Version 2.0.58
Platform: SunOS 5.10 Generic_127111-03
Our application is in the form of a shared library(.so binary) which is loaded into the Apache Web Server by mentioning the following directive in the Apache Web Server's configuration file (httpd.conf):
LoadModule at_module "/var/apache2/logs/sample/sample.so"
Where, sample.so is our application's binary
And at_module is the name of the module.
Problem details:
For each request to the Apache Web server, the server maintains a table of type "apr_table_t" which contains the header environment from the request. There is a structure "request_rec" maintained in the httpd.h file:
/** A structure that represents the current request */
struct request_rec {
/** The pool associated with the request */
apr_pool_t *pool;
/** Request method (e.g. GET, HEAD, POST, etc.) */
const char *method;
/** MIME header environment from the request */
apr_table_t *headers_in;
In our case, when we try to retrieve the address of "headers_in", we get a NULL Value. Please refer to the code for "sample-apache.cpp" program. Here it goes:
** Sample Program acting as a loadable Apache module.
** Overview:
** This sample program contains the necessary methods to make the program act as a module which can be loaded into the Apache ** Web Server. This program contains skeleton code which is necessary for any module which needs to be loaded into the Apache ** Web Server.
** Usage:
** 1) Compile and link this program to create a shared library.
** Compilation step:
** /opt/SUNWspro/bin/CC -c -o sample.o -I<Path to your include directory for Apache API's> sample-apache.cpp
** Link step:
** /opt/SUNWspro/bin/CC -G -compat=5 -mt -M map.SunOS -o sample.so sample.o -lsocket -lnsl -lpthread -ldl -lposix4 -lCstd ** -lCrun -lm -lw -lthread -lcx -lc
** 2) The sample program creates a module named "at_module" which can then be loaded in the Apache Web Server's configuration ** file, httpd.conf in the form of a configuration directive as shown below:
** LoadModule at_module "<Location of the shared library created from this sample program>"
#include "httpd.h"
#include "http_config.h"
#include "http_request.h"
#include "http_log.h"
static const char s_szInputFilterName[] = "INPUTFILTER";
extern "C" module at_module;
typedef struct
     int Enabled;
     char *szConfigFile;
     apr_array_header_t *input_filters;
} server_config_struct;
extern "C" apr_status_t ChildExit(void *p);
extern "C" apr_status_t ParentExit(void *p);
extern "C" int Init(apr_pool_t p, apr_pool_t pLogPool, apr_pool_t pTempPool, server_rec s)
void *data;
const char *user_data_key = "init_module";
apr_pool_userdata_get(&data, user_data_key, s->process->pool);
if(!data)
          apr_pool_userdata_set((const void *) 1, user_data_key, apr_pool_cleanup_null, s->process->pool);
else
          server_config_struct pConfig = (server_config_struct ) ap_get_module_config(s->module_config, &at_module);
          apr_pool_cleanup_register(p, s, ParentExit, apr_pool_cleanup_null);
          ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, "Exit callback registered.");
          fflush(NULL);
return OK;
extern "C" void ChildInit(apr_pool_t p, server_rec s)
     apr_pool_cleanup_register(p, s, ChildExit, apr_pool_cleanup_null);
     return;
extern "C" apr_status_t ChildExit(void *s)
     return APR_SUCCESS;
extern "C" apr_status_t ParentExit(void *s)
     return APR_SUCCESS;
extern "C" int access_checker(request_rec *r)
     FILE * fp;
     fp = fopen("/var/apache2/logs/sample.txt", "a");
     fprintf(fp, "\n r->headers_in = %u, r->method = %s", r->headers_in, r->method);
     fclose(fp);
     return OK;
extern "C" apr_status_t input_filter_init(ap_filter_t *f)
     return APR_SUCCESS;
extern "C" apr_status_t input_filter(ap_filter_t f, apr_bucket_brigade pbbOut,
                                             ap_input_mode_t mode, apr_read_type_e block,
                                             apr_off_t readbytes)
     return APR_SUCCESS;
static void register_hooks(apr_pool_t *p)
     ap_hook_post_config(Init, NULL, NULL, APR_HOOK_MIDDLE);
     ap_hook_child_init(ChildInit,NULL,NULL,APR_HOOK_MIDDLE);
     ap_hook_access_checker(access_checker, NULL, NULL, APR_HOOK_REALLY_LAST);
     ap_register_input_filter(s_szInputFilterName, input_filter, input_filter_init, AP_FTYPE_RESOURCE);
extern "C" module AP_MODULE_DECLARE_DATA at_module =
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
register_hooks
//End of sample
In this program, inside the access_checker() method, we try to retrieve the address of "headers_in" and get that as NULL:
extern "C" int access_checker(request_rec *r)
FILE * fp;
fp = fopen("/var/apache2/logs/sample.txt", "a");
fprintf(fp, "\n r->headers_in = %u, r->method = %s", r->headers_in, r->method);
fclose(fp);
return OK;
Here is the output of the sample program after accessing the main page of the Web server:
r->headers_in = 0, r->method = GET
r->headers_in = 0, r->method = GET
r->headers_in = 0, r->method = GET
Though we are able to retrieve one member of the structure request_rec (method), we are not able to retrieve the address of the other member (headers_in).
Observation:
We made an interesting observation that when we used the same sample program with the inbuilt Apache 2.0.52 Web Server on Solaris, we were able to successfully retrieve the address of headers_in. Here are the details of the set-up which is working fine:
Apache Web Server: Version 2.0.52
Platform : SunOS 5.10 Generic_118822-30
Thus, there is something different which has happened between the Sun's Solaris Apache Web Server's versions 2.0.52 and 2.0.58 which is making it unable to retrieve the address of the request headers (headers_in) in version 2.0.58.
Can sombody please help me find out the reson for this difference and let me know if we need to change the way of retrieving the request headers for Solaris Apache 2.0.58.
Thanks

Ok, found the problem:
Do not use this "SSL_RENEGOTIATE_NEVER" as a value for the environment variable:
NSS_SSL_ENABLE_RENEGOTIATION=SSL_RENEGOTIATE_NEVER;export NSS_SSL_ENABLE_RENEGOTIATION
instead, use "0":
NSS_SSL_ENABLE_RENEGOTIATION=0;export NSS_SSL_ENABLE_RENEGOTIATION
Add that line to your startserv script and it should disable ssl renegotiation permanently.
Regards,

Is a binary on 32 bit faster than a 64 bit binary in solaris ?

I timed a program for both 64 bit and 32 bit . The code is something like this --
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
int main (int argc,char **argv)
int count=0;
int count2=0;
int u=0;
int count3=0;
int sizeoffile=0;
int sizefile[5];
for(u=0;u<5;u++)
sizefile=1;
printf("%d\n",sizefile[u]);
char a='a';
char *b ;
FILE *file ;
b = (char *)malloc(512*sizeof(char));
while(count <512)
strncpy(b+count,&a,1);
count++;
for(u=0;u<2;u++)
sizeoffile=0;
if(u==0)
file=fopen("./writesize1","a");
else if (u==1)
file=fopen("./writesize2","a");
else if (u==2)
file=fopen("./writesize3","a");
else if (u==3)
file=fopen("./writesize4","a");
else if (u==4)
file=fopen("./writesize5","a");
while(sizeoffile<sizefile[u])
while(count2<(1024*1024))
count3=0;
while(count3 < 2)
fprintf(file,"%s",b);
fprintf(file,"\n");
fflush(file);
count3++;
count2++;
count2=0;
// count3++;
count3=0;
sizeoffile++;
fclose(file);
return 0;
The above code is crude code to write files of 1 GB.
I timed the above code binaries for 32 and 64 bit on a solaris 10 box . I got the following times :
for 32 bit : 2.16796for 64 bit : 2.5039466
Is this the expected behaviour or something I am missing ?
Edited by: rarpit on Mar 18, 2009 9:59 PM

Reasons a 64-bit program might be better:
* Can directly access more than 4GB of VM
* Has direct access to 64-bit math routines
* On x86, has access to more registers (big win for some code/compiler combinations) Shouldn't affect SPARC much.
Reasons a 32-bit program might be better:
* Can run on both 32-bit and 64-bit kernels
* Pointers are smaller. More code can fit in CPU cache, may run faster
* Memory footprint slightly smaller due to smaller pointers
So the general case is that unless you need the extra VM space, 64-bit math, have a special need to access 64-bit libraries, or your compiler is doing a great job of using the extra registers on x86, there's not much benefit to creating a 64-bit binary.
All that said, your program appears to be writing large files to disk. That task should be completely dominated by your I/O times. Did you run them more than once? I would imagine both versions to be identical because anything other than the disk writes will be in the noise.
Darren

Libc/stdio bug in Solaris!?

Hello,
I was testing the following code using gcc + cc on Solaris 10 x86 & Solaris 8 sparc, both times it breaks. It breaks inside a call to fprintf. According to the man-pages I should not do a read after write without a flush/position change (which is done). I should not do a write after read without a position change or if the input reached the end of the file (which is the case here). So I assume that either I overlooked something or there is a subtle bug in the implementation stdio.
Greeting
Matthias Kretschmer
The "bad guy":
#include <stdlib.h>
#include <stdio.h>
int
main(int argc, char **argv)
FILE *fp;
int i, j, k;
int values[37];
char buf[256];
/* initialize values to bullshit */
for (i=0; i<37; i++)
values[i] = rand() % 32;
/* open file */
if ((fp = fopen("test.txt", "a+")) == NULL) {
perror("fopen");
exit(1);
/* loop to write and then read all */
for (j=0; j<100; j++) {
printf("j=%d\n", j);
/* loop for writing all */
for (i=0; i<10000; i++) {
for (k=0; k<37; k++)
if (fprintf(fp, " %d", values[k]) < 0) {
perror("fprintf");
exit(1);
if (fprintf(fp, "\n") < 0) {
perror("fprintf");
exit(1);
printf("write done\n");
/* seek to beginning */
if (fseek(fp, 0, SEEK_SET) < 0) {
perror("fseek");
exit(1);
printf("seek done\n");
/* read in everything */
while (fgets(buf, 256, fp) != NULL) ;
/* with the following code it doesn't crash for me on Solaris */
#if 0
if (fseek(fp, 0, SEEK_END) < 0) {
perror("fseek");
exit(1);
#endif
printf("read done\n");
}

Hello.
Please try if the "printf("seek done\n");" line has been reached by adding an "fflush(stdout);" after that line - otherwise you will not get the message if the program crashes. (If the program crashes the data written by successful fprintf()s will also be gone.)
Maybe the "fgets(buf, 256, fp)" is the problem because buf is 256 bytes long - but it must be 257 (258 ?) bytes long due to the trailing NUL byte.
Martin

Problem with inbuilt Solaris Apache Web Server v 2.0.58

Hi,
Set-up:
We are working on a custom application which works with the inbuilt Apache Web Server on the Sun Solaris platform. Here are the details of the versions of the various components involved:
Apache Web Server: Version 2.0.58
Platform: SunOS 5.10 Generic_127111-03
Our application is in the form of a shared library(.so binary) which is loaded into the Apache Web Server by mentioning the following directive in the Apache Web Server's configuration file (httpd.conf).
LoadModule at_module "/var/apache2/logs/sample/sample.so"
where, sample.so is our application's binary
and at_module is the name of the module.
httpd.conf file has been attached for your reference.
Attachments:
httpd.conf - Apache Web Server's configuration file.
sample-apache.cpp - Sample program which is showing the problem.
httpd.h - Apache Software Foundation's file which contains the structure "request_rec" that represents the current request.
Problem summary:
For each request to the Apache Web server, the server maintains a table of type "apr_table_t" which contains the header environment from the request. There is a structure "request_rec" maintained in the httpd.h file:
/** A structure that represents the current request */
struct request_rec {
/** The pool associated with the request */
apr_pool_t *pool;
/** Request method (eg. GET, HEAD, POST, etc.) */
const char *method;
/** MIME header environment from the request */
apr_table_t *headers_in;
In our case, when we try to retrieve the address of "headers_in", we get a NULL Value. Please refer to the attached "sample-apache.cpp" program. In this program, inside the access_checker() method, we try to retrieve the address of "headers_in" and get that as NULL:
extern "C" int access_checker(request_rec *r)
     FILE * fp;
     fp = fopen("/var/apache2/logs/sample.txt", "a");
     fprintf(fp, "\n r->headers_in = %u, r->method = %s", r->headers_in, r->method);
     fclose(fp);
     return OK;
Here is the output of the sample program after accessing the main page of the Web server:
r->headers_in = 0, r->method = GET
r->headers_in = 0, r->method = GET
r->headers_in = 0, r->method = GET
Though we are able to retrieve one member of the structure request_rec (method), we are not able to retrieve the address of the other member (headers_in).
Observation:
We made an interesting observation that when we used the same sample program with the inbuilt Apache 2.0.52 Web Server on Solaris, we were able to successfully retrieve the address of headers_in. Here are the details of the set-up which is working fine:
Apache Web Server: Version 2.0.52
Platform : SunOS 5.10 Generic_118822-30
Thus, there is something different which has happened between the Sun's Solaris Apache Web Server's versions 2.0.52 and 2.0.58 which is making it unable to retrieve the address of the request headers (headers_in).
I am requesting someone to kindly shed light on this difference and let us know if we need to change the way of retrieving the request headers for Solaris Apache 2.0.58.
Thanks,
Atul.

The only way you can achieve it is by running the web server to listen on port 80
Please change the port in your httpd.conf file for the webserver and restart it.
If any other processes are running/using on port 80 on that machine, then please stop them, otherwise you will not be able to achieve your requirement.
Arun

Poor I/O Performance on Solaris - v1.4.1_01

Does anyone have any comments on the following?
It's an I/O analysis done to determine which Java
methods might be used to replace an existing C++
platform-specific file re-compression subsystem.
The system has to handle up to 200,000 files per
day (every day).
Java IO test results for converting ZERO_ONE compressed
files to standard compressed files.
Java 1.4.1, 12-04-2002
The input dataset contains 623,230,991 bytes in 1391 files.
The input files are in ZERO_ONE compression format.
For all tests:
1) an input data file was opened in buffered mode.
2) the data was read from the input and expanded
(byte by byte).
3) the expanded data was written to a compressing
output stream as it was created.
4) repeat 1 thru 3 for each file.
64K buffers were used for all input and output streams.
Note: Items marked with "**" hang at random on Solaris
(2.7 & 2.8) when processing a large number of small files. They always hang on BufferedInputStream.read().
There may be a deadlock situation with the 'process
reaper' because we're calling 'exec()' and 'waitFor()'
so quickly. The elapsed times for those items are
estimates based on the volume of data processed up to
the point where the process hung. This 'bug' has been
reported to Sun.
-- elapsed time --
NT Solaris 2.7 Method
n/a 18 min Current C++ code:
fopen(r) -> system(compress)
19 min 19 min ** BufferedInputStream -> exec(compress)
29 min 21 min 1) BufferdInputStream -> file
2) exec(compress file)
24 min 42 min ** BufferedInputStream -> exec(gzip)
77 min 136 min BufferedInputStream -> GZIPOutputStream
77 min -- BufferedInputStream -> ZipOutputStream
The performance of GZIPOutputStream and ZipOutputStream
makes them useless for any Production system. The 2x
performance degradation on Solaris (vs NT) for these two
streams is surprising. Does this imply that the 'libz'
on Solaris is flawed? Notice that whenever 'libz' is
involved in the process stream (exec(gzip),
GZIPOutputStream, ZipOutputStream) the elapsed time
climbs dramatically on Solaris.

Re-submitted Performance Matrix with formatting retained.
Note: for the "-> system()" and "-> exec()" methods, we write to the
STDIN of the spawned process.
-- elapsed time --
NT     Solaris 2.7 Method
n/a    18 min      Current Solaris C++ code:
                     fopen(r) -> system("compress -c >aFile")
19 min 19 min **   BufferedInputStream -> exec("compress -c >aFile")
29 min 21 min      1) BufferdInputStream -> "aFile"
                   2) exec("compress aFile")
24 min 42 min **   BufferedInputStream -> exec("gzip -c aFile")
77 min 136 min     BufferedInputStream -> GZIPOutputStream("aFile")
77 min --          BufferedInputStream -> ZipOutputStream("aFile")

Howto: Dual-Booting Vista Home and Solaris

Hello.
I searched a lot of forums about this but found nothing. I finally managed to install Solaris on a computer running Windows Vista Home and post my experiences here for people having the same problem.
Known problem: When the MBR of a hard disk is altered (e.g. installing additional operating systems) Windows Vista will not boot any longer.
Reason: Windows Vista uses a checksum of the MBR. If the checksum is not correct it does not boot.
How can you install Solaris anyway?
I did it using the following steps (requires some C programming skills and a C compiler for Windows):
a) Make a copy of the MBR (e.g. by booting the Solaris DVD into the single user shell) onto an USB stick:
dd if=/dev/rdsk/cxtxdxp0 of=/usbdisk/origmbr bs=512 count=1b) Create the Solaris partition and install Solaris
c) Make a copy of the new MBR. This is done the same way as step "a)". Replace "origmbr" by "newmbr".
d) Restore the original MBR. This is done like step "a)" but "if=" and "of=" must be turned around (of=/dev ... if=/usbdisk ...).
(This causes the Solaris partition to be removed; you will not see it in fdisk any more; but do not panic - the data is not deleted)
e) Reboot - Vista will be booted
f) Write the new MBR to the disk. This is where you need a C program. The program must be executed using administrator rights:
#include <windows.h>
#include <stdio.h>
main()
    HANDLE h;
    FILE *f;
    DWORD d;
    char a[512];
    h=CreateFile("\\\\.\\PhysicalDrive0",GENERIC_WRITE,0,0,
        OPEN_EXISTING,0,0);
    // Replace newmbr by the actual file name of the file
    // containing the new MBR
    f=fopen("newmbr","rb");
    fread(a,1,512,f);
    fclose(f);
    WriteFile(h,a,512,&d,NULL);
    CloseHandle(h);
}I also took bytes 0...0x1BD from the original MBR and only bytes 0x1BE...0x1FF (actual partition information) from the new MBR because I heared that Vista does not work with foreign MBR boot loaders.
g) Go to the computer administration (right-click of "Computer" in the start menu) and "administration" and go to the volume manager. Press F5 - now the volume manager will see the Solaris partition. Make any partition the active partition and change the active partition back to the Windows partition - now the checksum of the MBR will be re-calculated.
I do not know if this step is necessary because "diskpart.exe" should also re-calculate the checksum.
h) Start diskpart.exe with administrator rights. Make the Solaris partition (containing Grub) the active partition - now the computer boots GRUB and Vista can be booted.
Note:
The boot information in the system control as well as bcdedit.exe will only work if the Windows partition is active. Maybe the system recovery will also not work.
Martin

Hello.
The main problem is not the fact that GRUB does not boot - this could be easiely solved by overwriting the MBR by the original MBR (so changing from Windows to another OS must be done using a bootable CD or disk).
The problem is that creating an additional partition is not possible. I think if Microsoft wanted to "solve" this "problem" (forbid other OSs to be booted) they were not able to do this because many modern BIOSes create a hard disk partition for their data (e.g. hard disk encryption, finger print stuff etc.). Windows would either not be able to boot on such machines (not wanted by Microsoft) or not be able to recognize that another OS is installed (that can be booted at least by using a boot CD).
I think that Microsoft themself have no interest in forbidding other OSs to be booted. There are a lot of machines running Windows only as secondary OS (e.g. in airspace industry). Microsoft is not interested in not being able to sell a newer version of Windows to owners of these machines.
Martin

Solaris 9 32-bit application 256 descriptors

Hi,
There is a bug in Solaris, a 32-bit application running on 64-bit Solaris cannot open more than 256 descriptors. I read the article from Giri Mandalika http://developers.sun.com/solaris/articles/stdio_256.html. There is a solution for Solaris 10 described in that article. Is there any solution for Solaris 9? Was that solution backported to Solaris 9?
Any hint is appreciated.
Tomas

Hello.
This limitation is not a limitation of the Solaris operating system but of the libc library.
A simple workaround could be:
FILE *myfiles[1000];
int i;
// won't work if more than 256 files are open...
for(i=0;i<1000;i++) myfiles=fopen(names[i],"w");
for(i=0;i<1000;i++) fprintf(myfiles[i],"%u\n",i);
Workaround - NOT TESTED:FILE *f;
int myfiles[1000];
int i;
for(i=0;i<1000;i++) myfiles[i]=creat(names[i],0644);
for(i=0;i<1000;i++)
f=fdopen(dup(myfiles[i]),"w");
fprintf(f,"%u\n",i);
// fclose() will only close the handle duplicate returned by dup() !!
fclose(f);
-- EDIT --
Tested on Solaris 9/Sparc:
- You have to use "ulimit -n" to allow an application to use more than 256 file descriptors (maximum is 1024).
- If more than 256 files are open "dup" and "dup2" will cause an SIGSEGV - obviously a bug in Solaris.
Maybe you can use the following combination instead of using "fprintf":len=sprintf(buffer,...);
write(file[i],buffer,len);
I'm not sure if "write" etc. cause SIGSEGVs when more than 256 files are open.
Martin

Solaris file descriptor question

Hi,
We have an application on Solaris 2.6 and
the shell in which the server runs has a
file descriptor limit of 1024. What does
this mean? Does this mean that every process
from the shell will have 1024 fds? What
is the maximum # of fds that a solaris 2.6
system can provide?
When I run "sysdef", I get:
ffffffff:fffffffd file descriptors
How do I interpret this line?
Is this 64K - some value?
If system limit is 64K and if each
shell has 1024, how are the fds allocated
to the shells?
What I mean is:
say I have 3 shells each with descriptor
limit of 1024, then is the distribution
something like 1024-2047 for shell 1,
2048 - 3071 for shell 2 (i.e. 3072) and
3072 - 4095 for shell 3?
Appreciate any explanation of this anyone
can offer.
thanks,
mshyam

Hi There,
About File Descriptors and Their Limitations:
All versions of Solaris (including Solaris 7 64-bit) have a default "soft" limit of 64 and a default "hard" limit of 1024.
Processes may need to open many files or sockets as file descriptors. Standard I/O (stdio) library functions have a defined limit of 256 file descriptors as the fopen() call, datatype char, will fail if it can not get a file descriptor between 0 and 255. The open() system call is of datatype int, removing this limitation. However, if open() has opened 0 to 255 file descriptors without closing any, fopen() will
not be able to open any file descriptors as all the low-numbered ones have been used up. Applications that need to use many file descriptors to open a large number of sockets, or other raw files, should be forced to use descriptors numbered above 256. This allows system functions such as name services, to work as they depend upon stdio routines.
(See p 368 "Performance and Tuning - Java and the Internet").
There are limitations on the number of file descriptors
available to the current shell and its descendents. (See the ulimit man page). The maximum number of file descriptors that can be safely used for the shell and Solaris processes is 1024.
This limitation has been lifted for Solaris 7 64-bit which can be 64k (65536).
Therefore the recommended maximum values to be added to /etc/system are:
set rlim_fd_cur=1024
set rlim_fd_max=1024
To use the limit command with csh:
% limit descriptors 1024
To use the ulimit command with Bourne or ksh:
$ ulimit -n 1024
However, some third-party applications need the max raised. A possible recommendation would be to increase rlim_fd_max, but not the default (rlim_fd_cur). Then rlim_fd_cur can be raised on a per-process basis if needed, but the higher setting
for rlim_fd_max doesn't affect all processes.
I hope this helps your understanding about systemwide file descriptor max limit in conjunction with shell and per process file descriptor limits.
....jagruti
Deveoper Technical Support
Sun Microsystems Inc.

Logical interface in solaris 10

Hi there,
I need to configure logical interface in a solaris 10 3/05 server. After reading the Solaris 10 IP services manual, I am not quite sure what to do. All the examples and explanation are about using the new subcommand addif of ifconfig. It was not clear in the documentation if the setting logical interfaces via addif will persist across boot.
Can one still configure logical interface in Solaris 10 in a more traditional way like in Solaris 8? In an Solaris 8 server I will do the following.
Let's assume I want to configure in a solaris 8 server a logical interface named hme0:1 with IP address 192.168.20.28 with netmask 255.255.255.0 for hostname host001
# cat /etc/hostname.hme0:1
host001
^D
# echo "192.168.20.28 host001" >> /etc/inet/hosts
# echo "192.168.20.0 255.255.255.0" >> /etc/inet/netmasks
# reboot -- -r
Can one still do that in solaris 10 3/05 server?

Hi there,
I need to configure logical interface in a solaris 10
3/05 server. After reading the Solaris 10 IP services
manual, I am not quite sure what to do. All the
examples and explanation are about using the new
subcommand addif of ifconfig. It was not clear in the
documentation if the setting logical interfaces via
addif will persist across boot.No. No 'ifconfig' command is persistent.
Can one still configure logical interface in Solaris
10 in a more traditional way like in Solaris 8? In an
Solaris 8 server I will do the following.
Let's assume I want to configure in a solaris 8
server a logical interface named hme0:1 with IP
address 192.168.20.28 with netmask 255.255.255.0 for
hostname host001
# cat /etc/hostname.hme0:1
host001
^D
# echo "192.168.20.28 host001" >> /etc/inet/hosts
# echo "192.168.20.0 255.255.255.0" >>
/etc/inet/netmasks
# reboot -- -r
Can one still do that in solaris 10 3/05 server?Absolutely.
You don't need to reboot (you can run ifconfig for this boot and let the files do the work next time) and the -r doesn't do anything with interfaces (expecially virtual interfaces) anyway.
Darren

Installation problem on Solaris

I am trying to install sun one 7.0 on Solaris 8. The install is failing with this error:
ERROR - library load failed with following error: Can't load library: /opt/SUNWappserver7/lib/libinstallCore.so
INFO - End core server uninstallation
anyone know what causes this??
cheers

Looks like Solaris package installation failed and installer reverted to uninstallation sequence. For low level pkgadd log please check /var/sadm/install/logs/Sun_ONE_Application_Server_install.B<timestamp> file (timestamp is date and time of your installation attempt in mmddHHMM format).
Look for any errors in this file. Most likely thing that could have happened is that the installation of Java Help (SUNWjhrt) package failed because you didn't have existing package based J2SE installation on the system. If that's the case, workaround is to either preinstall package based J2SE installation or to selected option to install bundled J2SE that comes with application server.

Fopen limitaion in solaris

Similar Messages

Maybe you are looking for