Increase size of IFS file received in http_url_post

["Stoicescu, Adriana" <astoicescu@xxxxxxxxxx>]

Sender: "Stoicescu, Adriana" <astoicescu@xxxxxxxxxx>

We have included in our application a call to http_api_post in order to send
and receive XML documents. The problem is that the received IFS file is
truncated in either case, the file created by your API or the file created
before calling the API. We have checked your source and we cannot find the
spot where we could increase or specify the file size or the method of doing
it.
Could you please help us?
Adriana Stoicescu
Analyst-programmer
UTI, United States, inc.


-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Friday, February 11, 2005 8:50 AM
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: Authorities in the IFS (DCM)

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


> We are experiencing some difficulties in authorities in the IFS which
appear
> to be random, but I am sure they are not.
> We use Scotts httpapi in ssl mode, which in turn evokes a usage of the
DCM.
> The path to the DCM is:
> /QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.kdb

That's the path of the key database in the *SYSTEM certificate store. 
You're right that this is part of the DCM, but it's not all of it.

> Changing the *PUBLIC authorities for server and default fixes the problem.
>
> My question is, why do we not get this error for all Users ? Our
experience
> is something like 50/50 get/do not get/ the error.

Is it possible that these other users are using certificates that are not 
in the *SYSTEM certificate store?

Another thought: Maybe they've got group access to the file?  Every file 
in the IFS has 3 levels of authority:  Owner, Group & Public.  You said 
that the file is *PUBLIC *EXCLUDE, so that rules out "Public".  And they 
can't ALL be the owner of the file.  So, that leaves group...

You can use QShell to see who the owners are and what their level of 
authority is:
   STRQSH
   ls -l /QIBM/UserData/ICSS/CERT/SERVER/DEFAULT*

This should show something like:
  -rwxrwxr-x  1 QSECOFR QSYS 110080 Oct  8 17:54
/QIBM/UserData/ICSS/CERT/SERVER/DEFAULT.KDB
  -rwxrwxr-x  1 QSECOFR QSYS   5080 Aug  5  2004
/QIBM/UserData/ICSS/CERT/SERVER/DEFAULT.RDB

In this example, the owner is QSECOFR and the group is QSYS.  At the start 
you see '-rwxrwxr-x'  that indicates the permissions for the three 
different classes of users.  The first 3 'rwx' is QSECOFR's permissions to 
the file.  He's got read, write and execute.  The next 3 are QSYS's 
authorites 'rwx' again, meaning read/write/execute.  The last 3 are the 
public's authorities. 'r-x' means read & execute (but not write!)


> There may be something else that affects the access to default.kdb other
> than the authorities I have described above.
> I note that QSYS retains all rights. Is it possible that some users are
> adopting QSYS ?

Adopted authority won't work in the IFS.  However, user profile swapping 
would work. Or, having QSYS assigned as their group profile or a 
supplemental group would also work.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------