You can license iSockets for commercial use (re-distribution), however the
source code cannot be re-distributed unless the corresponding license fee is
paid per customer or some kind of custom one-time charge is agreed upon.

Bob, could you provide some more detail on the 'license' conditions should we 
decide to purchase a license for iSockets with source code for commercial use 
please?

Would we be entitled to adapt the original source to create a derived version so 
long as we keep your original copyright attribution? Can we add our own 
additional copyright notice to cover any additions and changes we may make? 
Something like "Parts (c)copyright my-company-name 2010...".

Are there any restrictions on distribution in a binary format of the original or 
any work derived from iSockets?

Thanks,

Success! Applying the PTFs allowed all the programs to restore.

Thanks Bob, you de man.

Checked my systems, those PTFs are not installed...

I'll see about getting them...

Thanks Bob.

Its not me, its you, really. 

Do you have the corresponding PTF on your system?

v5r3m0 -> MF41354
v5r3m5 -> MF41734
v5r4m0 -> MF40520
v5r4m5 -> MF42655

I had the same results on my V5R4 machine with the save file downloaded today. 
The save file I downloaded last week would not restore 2 objects, ISOCKVER and
ISOCKETS.  Seems to be going in the wrong direction.

Tried the following on 3 different machines, all have the exact same outcome.

270 v5r3
810 v5r4
520 v5r4

Here is what I entered:

CLRLIB ISOCKETS

RSTLIB SAVLIB(ISOCKETS)    
       DEV(*SAVF)          
       SAVF(QGPL/ISOCKETS) 
       FRCOBJCVN(*YES *RQD)

Here are the results:
PGM CRTISOCK not restored to ISOCKETS.     
PGM DSPIP not restored to ISOCKETS.        
PGM DSPVER not restored to ISOCKETS.       
PGM ISOCKVER not restored to ISOCKETS.     
SRVPGM ISOCKETS not restored to ISOCKETS.  
File QCLSRC in library ISOCKETS restored.  
File QCMDSRC in library ISOCKETS restored. 
File QCPYSRC in library ISOCKETS restored. 
File QDDSSRC in library ISOCKETS restored. 
File QHTMLSRC in library ISOCKETS restored.
File QRPGLESRC in library ISOCKETS restored.    
File QSRVSRC in library ISOCKETS restored.      
File QXMLSRC in library ISOCKETS restored.      
File TWUSER in library ISOCKETS restored.       
17 objects restored. 5 not restored to ISOCKETS.

Here is the F1 on the first error:
                         Additional Message Information                         
                                                                                
 Message ID . . . . . . :   CPF3888       Severity . . . . . . . :   20         
 Message type . . . . . :   Diagnostic                                          
 Date sent  . . . . . . :   05/28/09      Time sent  . . . . . . :   09:50:11   
                                                                                
 Message . . . . :   PGM CRTISOCK not restored to ISOCKETS.                     
 Cause . . . . . :                                                              
     If the object is a database file, an unexpected failure occurred during    
   the restore of a file member.  The member was not restored.                  
     If the object is not a database file, then the conversion needed to make   
   the object compatible with the current system is not possible, so the object 
   was not restored.                                                            
     If the object is a program, module, service program, or SQL package, then  
   either the object may not have the required creation data needed to perform  
   the conversion, or there was an unexpected error. Conversion of these object 
   types during restore is controlled by the Force Conversion on Restore        
   (QFRCCVNRST) system value and the Force Object Conversion (FRCOBJCVN)        
   parameter on the restore command.                                          
 Recovery  . . . :                                                            
     Restore the object from a different save version using the Restore Object
   (RSTOBJ) command, or do one of the following:                              
     -- If the object is a database file, save the job log and the save media 
   or online save file and report the problem (ANZPRB command).               
     -- If the object is a program, module, service program, or SQL package,  
   create the object using the appropriate create command, or restore the     
   object from a saved version which has the required creation data.          

hcedmondson, did you check the joblog for any other messages or hit F1 to see
what the second level message are/were? If so, what were they?

At this point I believe its user-error on your part, but I could be wrong.

If anyone else has a v5.3 machine and would try restoring iSockets onto it, then
report back so we know if you had this same issue, I'd appreciate it.

If the initial restore does NOT work, please try adding:

FRCOBJCVN(*YES *RQD)

to the RSTLIB command.


Download isockets from:

www.iSockets.net

Sorry I wasn't more clear, no, it did not make any difference which parameters I
specified, it still will not restore those programs.

Maybe someone out here has a version of the SAVF from earlier? It would be at
least good to know it's the new hardware causing the problem.

Okay so it worked, right?

I no longer have an older system available otherwise this would be running on
V5R1 (which is all it really needs).

Yup, tried the force conversion parameters, fully relaxed the system value.

I wonder if you'd consider a "frozen" version for the older hardware, assuming
you have access to a machine? I'll be stuck on this hardware in the foreseeable
future.

Are you specifying

  RSTLIB ... FRCOBJCVN(*YES *RQD)

as the error message indicates is required to restore these objects?
If not, try adding it.

Then check the value for your QFRCCVNRST system value.
Its probably 0 or 1, which is an issue for situations like this (for you).

I'm on v6.1 and compiling back to v5r3m0. But regardless, programs on my system
are for the newer Power6 chipset and were re-encapsulated when we moved, and of
course anything compiled  here is also for the new hardware. This may be "the"
issue.

Now there are 5 objects not restored...I double checked, definitely at v5r3.

PGM CRTISOCK not restored to ISOCKETS.    
PGM DSPIP not restored to ISOCKETS.       
PGM DSPVER not restored to ISOCKETS.      
PGM ISOCKVER not restored to ISOCKETS.    
SRVPGM ISOCKETS not restored to ISOCKETS. 

Please download and give the current version of iSockets another try.

I changed the C module in it (used for Base64 encoding) from OPTIMIZE(40) to
OPTIMIZE(10). I also saw no omitted objects this time, when I did the save to
TGTRLS(V5R3M0).

If if you are on a release of V5.3 or later, it should restore.

If it doesn't then I think there's a bug in the i OS system itself.

Here is the full text from the error message:

                        Additional Message Information                        
                                                                              
Message ID . . . . . . :   CPF3888       Severity . . . . . . . :   20        
Message type . . . . . :   Diagnostic                                         
Date sent  . . . . . . :   05/26/09      Time sent  . . . . . . :   12:27:25  
                                                                              
Message . . . . :   PGM CRTISOCK not restored to ISOCKETS.                    
Cause . . . . . :                                                             
    If the object is a database file, an unexpected failure occurred during   
  the restore of a file member.  The member was not restored.                 
    If the object is not a database file, then the conversion needed to make  
  the object compatible with the current system is not possible, so the object
  was not restored.                                                           
    If the object is a program, module, service program, or SQL package, then 
  either the object may not have the required creation data needed to perform 
  the conversion, or there was an unexpected error. Conversion of these object
  types during restore is controlled by the Force Conversion on Restore       
  (QFRCCVNRST) system value and the Force Object Conversion (FRCOBJCVN)       
  parameter on the restore command.                                           
Recovery  . . . :                                                             
    Restore the object from a different save version using the Restore Object 
  (RSTOBJ) command, or do one of the following:                               
    -- If the object is a database file, save the job log and the save media  
  or online save file and report the problem (ANZPRB command).                
    -- If the object is a program, module, service program, or SQL package,   
  create the object using the appropriate create command, or restore the      
  object from a saved version which has the required creation data.           
                                                                              

I tried to restore on both 270 and 810 machines, v5r3 and v5r4 respectively.

Would you consider floating the source if I sign a non-disclosure? <g>

Maybe I can get it to compile that way.

Is it telling that its a conversion issue? 
I wonder if it has something to do with the re-encapsulation for the "new" Power
hardware? We have the latest box and this may be an issue on older boxes. I wonder?

I am receiving the error in regards to the three objects that will not restore 
also.  Exact same message.  And I just downloaded the zip file, and the system 
I am trying to restore on is at v5r4.

Negative, same 3 programs, same error.

The save file does say it's v5r3m0.

Well, I just re-did the build (again) and verified it (again) and it now shows
V5R3. Try downloading it (again) and see if you are successful.

I must have been on drugs that day as it was a mix of v6r1 and v5r3 stuff. Sorry.

RSTLIB SAVLIB(ISOCKETS) DEV(*SAVF) SAVF(QGPL/ISOCKETS)
PGM CRTISOCK not restored to ISOCKETS.                
PGM ISOCKVER not restored to ISOCKETS.                
SRVPGM ISOCKETS not restored to ISOCKETS.             

Bob, cannot get these 3 to restore on v5r3 or v5r4. I've tried every suggestion
in the message. I downloaded the latest SAVF. Any ideas?

 Message ID . . . . . . :   CPF3888       Severity . . . . . . . :   20         
 Message type . . . . . :   Diagnostic                                          
 Date sent  . . . . . . :   05/24/09      Time sent  . . . . . . :   06:38:21   
                                                                                
 Message . . . . :   PGM CRTISOCK not restored to ISOCKETS.                     
 Cause . . . . . :                                                              
     If the object is a database file, an unexpected failure occurred during    
   the restore of a file member.  The member was not restored.                  
     If the object is not a database file, then the conversion needed to make   
   the object compatible with the current system is not possible, so the object 
   was not restored.                                                            
     If the object is a program, module, service program, or SQL package, then  
   either the object may not have the required creation data needed to perform  
   the conversion, or there was an unexpected error. Conversion of these object 
   types during restore is controlled by the Force Conversion on Restore        
   (QFRCCVNRST) system value and the Force Object Conversion (FRCOBJCVN)        

That is an example application with subdirectories on the IFS that I created.
You would change these to your own folder names, such as /home/usrprf and the
generated .txt files would be created there.

What is supposed to reside in the /cozzi/google.txt and /cozzi/http_xml.txt 
files?  I tried to run GETGOOGLE and WEBSERVEX1, but I get the error "No such 
path or directory" on these files.  Are they supposed to reside in the IFS?

I've rebuilt, resaved, and reposted iSockets this afternoon.
Download and give that version a try.
If it doesn't work, try to see if there's more details in the joblog. 
Do you have security restrictions on source restoring or *SRVPGM objects?

The *SRVPGM did not restore, only the *BNDDIR.  My system is at V5R4

The latest version of iSockets requires v5r3, but I may have compiled some of
the example source members at *CURRENT. So don't worry about it. As long as you
get the iSockets *SRVPGM to restore along with the example source members, you
should be good to go.

Check your version and release level.

I am trying to load ISOCKETS but when I do the RSTLIB, I get a whole bunch of 
CPF3888 "not restored to ISOCKETS" messages in the job log (the first few are 
below).  Any ideas?

PGM DSPIP not restored to ISOCKETS.   
PGM GETGOOGLE not restored to ISOCKETS
PGM GETURL not restored to ISOCKETS.

The 64k limit in RPG IV shouldn't matter to iSockets.
I have not tested it, but I use the same technique I incorporated into RPG
xTools to handled up to 16 MB so you should be okay.

Yeah I know about the refresh issue.  I can't seem to stop myself from doing 
it though.  I think its a problem with the forum.  A simple way to stop it 
from happening is to generate a post ID as a hidden field on this form when 
the page is rendered.  That way, when the same post ID keeps re-appearing due 
to a page refresh, they can be ignored.  Or provide a link or button on the 
page to refresh the forum (perhaps its already there and I'm just not seeing 
it).

As for when I tried option 1, I think I did use the data length and not the 
return length.  I'll give it another try and let you know how it goes.

But I have another question.  Have you ever used iSockets to handle a SOAP 
Response that exceeds the 65535 of the buffer?  I know that SOAP isn't a very 
good vehicle for large data sets but I'm just trying to get a feel for my 
options would be in this case.

Thanks!

Jarrod

When calling XML-INTO and using option 1, did you specify the return-length or
just use the length of your data? You can't use anything except the return length.

So my question is, were those extra characters at the end of the returned data,
or following it (based on the length returned to you)?

Hey JAR01.... don't hit F/5 to refresh.... it "reposts"

Good morning Bob!

After game of squash and a good night of sleep I'm back on this and it now 
processes the entire result.  However, it only works with option 2 when I 
specify a second, empty buffer, as the target output of the converted bytes.  
When the same buffer was used, or when I tried option 1, those pesky 
overhanging bytes were still there.  Only instead of being scattered 
throughout the XML, they were all appearing at the end.  The XML-INTO command 
would die when handling the last group of records in the document.

Also, I tripped myself up when I set the from/to CCSID values to 0 before 
sending the SOAP Request.  I was scratching my head for a few minutes 
wondering why I was getting a HTTP 400 error coming back.  As it turned out, I 
was sending an EBCDIC encoded SOAP Request.  Once I changed the <i>from</i> 
CCSID to 0 after the HTTP Request had been made, everything worked out OK.

So it looks like our theory was correct.  Once again, thanks for your help 
with this.  I really appreciate it.

Good morning Bob!

After game of squash and a good night of sleep I'm back on this and it now 
processes the entire result.  However, it only works with option 2 when I 
specify a second, empty buffer, as the target output of the converted bytes.  
When the same buffer was used, or when I tried option 1, those pesky 
overhanging bytes were still there.  Only instead of being scattered 
throughout the XML, they were all appearing at the end.  The XML-INTO command 
would die when handling the last group of records in the document.

Also, I tripped myself up when I set the from/to CCSID values to 0 before 
sending the SOAP Request.  I was scratching my head for a few minutes 
wondering why I was getting a HTTP 400 error coming back.  As it turned out, I 
was sending an EBCDIC encoded SOAP Request.  Once I changed the <i>from</i> 
CCSID to 0 after the HTTP Request had been made, everything worked out OK.

So it looks like our theory was correct.  Once again, thanks for your help 
with this.  I really appreciate it.

In the morning?  Geeze......

Sorry.  Just to update, when I tried passing 0's in for from/to CCSID values I 
was still using the beta service program.  Which probably led to the identical 
error.  I'll re-test in the morning.  

Thanks for all your help today.  I really appreciate it.

Ah... crap!
Drug induced coma? 

I changed the routine, but had been tweaking the conversion routine and screwed it
up by passing in an output length of 0.

Go ahead and give it one more try with the same download link. I reposted it just
now. Sorry and Thanks!

www.isockets.net/ISOCKETSBeta.zip

So the theory is as follows:

You receive some data from the socket.
It is in UTF-8 or CCSID(1208). 
The Recv() only reads in say 32 bytes and then there's another 32 bytes waiting
to be received. But it converts that first 32-bytes from 1208 to CCSID(37). If
that last character was a slip (2-byte) UTF-8 symbol, you're screwed.

So there are two solutions:
1) Have Bobby change the code.
2) Specify no CCSID conversion and buffer up the returned data until its all
finished. Then do the conversion yourself by calling iconv() or the iconv
wrappers provided in iSockets. That way all the data is correctly converted
after it has all been received.

Obviously option 2 is user-work-around.
Option 1 however is now implemented. It works by looping on the Recv() SOCKET
API when the RecvURLData() is called. This looping occurs until either an error
is detected, or zero bytes have been returned, or the user-supplied output
buffer is full. Then the CCSID conversion is performed.


This is only a halfass patch as in theory you could call RecvURLData with a
return buffer (variable) that is too small to hold all the data being returned.
Consequently you could end up right back where you were with a 2-byte value
being converted as a one-byte value. 

This is why the CCSID conversion parameters are set up to accept zeros for both
of them, causing no CCSID conversion to be performed by the iSockets APIs and
leaving the conversion option up to you. This is a better solution in the long
run and one that I would advocate to iSockets users.

Correct.  I first tried the beta version you provided.  Then I tried the other 
method that you onlined.  Both produced the same error.

Another quick update.  I also tried the other method of passing 0's in for 
from/to CCSID values.  This resulted in the same error is the last post.  Any 
ideas?

Okay, but just to confirm, you did NOT do CCSID(0 0) on the receive, you just
used the Beta version without changing your code, right?

While I still think this is still worth looking into, the beta version that I 
downloaded threw an error before reaching the XML-INTO command.  Here's what 
the job log printed out:

"iSockets::cvtCCSID() error: 3491 - Argument list too long.   
çèè&|.ä?>>ÁÄÈÑ?>ÄËÁà/ÈÁïÁÀ|ÄÈå(èëÁÊ 
  ÎÁÊ(ÑÄÊ?Ë?ÃÈññëì&?ÏÁÊÁÀâ` ë&+áèì Ëø+ÁÈîÁÊËÑ?> 
  ä/ÄÇÁä?>ÈÊ?øÊÑÎ/ÈÁ_/Ì/ÅÁä?>ÈÁ>Èè`øÁÈÁÌÈÌ_ÄÇ/ÊËÁÈÍÈÃ 
  ä?>ÈÁ>È<Á>ÅÈÇÌ_ÎÁÊËÑ?>Á>Ä?ÀÑ>ÅÍÈÃË?/øá>ÎÁ...."

The crazy characters continue on but you get the idea.  I think the error 
meant the conversion didn't take place at all.

JAR01,

I made a change to the RecvURLData subprocedure.

It now loops until the entire buffer (provided by you) is filled up.
Previously it did one Recv() and then returned. Now it loops until no more data
is read or the buffer is full. So if your buffer is big enough, the CCSID
conversion will be performed all at once for you.

The other option, of course, is as I suggested--passing the from/to CCSID of 0
so that no conversion is attempted at all. Then do the conversion in your own code.

But download this beta test version and restore the *SRVPGM object only. Then
rerun your app and let me know the results.

Thanks.
The beta version of iSockets can be downloaded at this URL:

www.isockets.net/ISOCKETSBeta.zip

Okay, that's clever. Let me noodle on that and see if it would make any
difference. It may make sense to try the SendRecv function which does everything
with its own buffer and then converts everything all at once at the end of the
process.

One way to verify your theory, is to set the from/to CCSIDs to 0 on the
RecvURLData API. Then gather all the data in one big buffer. After you're done,
do the conversion using:

     D m_hConv         DS                  LikeDS(iconv_t) Inz(*LIKEDS)

               hConv = *ALLX'00';
               openCvtCCSID(hConv:nFrom:nTo); // Open CCSID conversion handle

               nBytes = cvtCCSID(hConv:pData:nDataLen:pOutput:nBufferLen);
               closeCvtCCSID(hConv); // Close CCSID cvt handle.

Sorry about the double post again.  Hit my refresh button to see if you had 
replied.

I don’t believe this specific character is produced by isockets itself.  This 
out of place character only appears when dealing with this specific result.  
We found this morning that different results produce different abnormalities 
in the XML.

Your explanation of how the in-place data conversion takes place makes some 
sense now.  I was testing with individual records and stumbled upon another 
example of strange characters in the XML.  Only this time, the response 
content was small and the unwanted characters were showing up at the end of 
the SOAP Envelope tag.  Here's what was printed in the job log:
"... </soap:Body></soap:Envelope> á>ÎÁ%?øÁ"

So, if I understand this correctly, bytes are converted, in place, after they 
are appended to the buffer.  However, the converted EBCDIC content doesn't 
always line up, byte for byte, with the original UTF-8 content.  This 
potentially leaves some data dangling at the end.  As more bytes are appended 
to the buffer, it's not being appended to the end of the EBCDIC converted 
content.  Instead it is simply tacked on at the specified offset which is at 
the end of dangling UTF-8 content.  Does that sound plausible to you?

Thanks again.  I really appreciate the help.

I don’t believe this specific character is produced by isockets itself.  This 
out of place character only appears when dealing with this specific result.  
We found this morning that different results produce different abnormalities 
in the XML.

Your explanation of how the in-place data conversion takes place makes some 
sense now.  I was testing with individual records and stumbled upon another 
example of strange characters in the XML.  Only this time, the response 
content was small and the unwanted characters were showing up at the end of 
the SOAP Envelope tag.  Here's what was printed in the job log:
"... </soap:Body></soap:Envelope> á>ÎÁ%?øÁ"

So, if I understand this correctly, bytes are converted, in place, after they 
are appended to the buffer.  However, the converted EBCDIC content doesn't 
always line up, byte for byte, with the original UTF-8 content.  This 
potentially leaves some data dangling at the end.  As more bytes are appended 
to the buffer, it's not being appended to the end of the EBCDIC converted 
content.  Instead it is simply tacked on at the specified offset which is at 
the end of dangling UTF-8 content.  Does that sound plausible to you?

Thanks again.  I really appreciate the help.

By default, RecvURLData converts from UTF-8 to your job's CCSID.
On a North American System i, this means form CCSID(1208) to CCSID(37).

A X'64' in EBCDIC is the grave accented A. 

Is this character consistently produced by iSockets? 
Where/when is it produced. It could be on the call to iconv() which is performed
under the cover in RecvURLData(). It could be that an ASCII 192 X'C0' is being
sent. This could be a left bracket { symbol. Interesting issue. In looking at
iSockets, I don't see a problem but you never know, iconv() is one of the most
confusing APIs in history (when mapped to RPGIV syntax) so it could be causing
the issue. However, it would cause the problem for much more than just one
character. 

The big difference between RecvURLData and the SendURLData interfaces is that
SendURLData creates a work buffer to convert the data before sending it, whereas
RecvURLData does an in-place conversion. Meaning it converts the UTF-8 to EBCDIC
and uses the same target buffer as is used for input. Basically changing the
data where it stands. 

Very curious...

Hey Bob,

Thanks for your prompt replies yesterday.  I'm quite certain that this character
isn't initially contained in the SOAP Response.  The HTTP Analyzer that I was
using is bound to my network card and captures the response before .NET ever
gets to look at it.  But to remove any doubt I wrote a simple program in Java
that connects to the Web Service over a socket connection.  The bytes received
from the response do not contain the character in question.  To add to this a
little further, this character doesn't exist in the data that we're retrieving
either.

The return buffer has a length of 65535 and is populated with 38968 bytes from
the SOAP Response.  I'm working very closely with the examples that were
provided in iSockets.  I've even left the variable names intact in most places.
 Here's the code that I'm using to populate the buffer:

dou (nBytesRtn <= 0 or (nResponseLen >= %size(szXML)));
	nBytesRtn = RecvURLData(hURL: pXML + nResponseLen:
		    %size(szXML) - nResponseLen);
	nResponseLen += nBytesRtn;
enddo;

As for the declares, I can send you the source of the file if it helps.  Perhaps
you'll be able to identify something that isn't entirely obvious to me.

Also, the hexidecimal value for that character is x'64' and it does appear in
the EBCDIC to ASCII conversion table that you provided.

Thanks again,

Jarrod

Jar01,

I'd like to verify something with iSockets.
Can you provide the hexadecimal value for the character you're identifying? 
In Debug just do this on the debug command line:

  eval  myVar:x

And it'll give you the data in the field in hex.
However, you may want to offset the value to the position where the goofy
character is located.

What's the size of the return buffer that provide to iSockets to receive the XML
from the remote system? 
Can you post the declares and the RecvURLData instructions you're using?

Also, have a look at that character in the conversion table on this page:
http://www.rpgiv.com/rpg-lab/showascii

It may help you track down what's going on.
If the .net app doesn't see it, that's one thing, But if it treats inter-node
characters as blanks (which is not unlikely) then it could be that it is there,
but .net is just ignoring it; whereas IBM parsers tend to be a bit more anal.

Hi Bob,

I've recently started using iSockets to consume a web service but I'm having
trouble with parsing the SOAP Response.

Before going any further it's important to point out a few details about the
service and the data set that is being returned.  The service is simple in that
it only has one parameter.  For the sake of this example let's say that it is an
employee name.  If no employee name is specified, then all employees are
returned.  Otherwise, the service will return a single record for the specific
employee.

When the service is called without specifying an employee, 90 records are
returned.  However, when processing the result, record 36 will cause the
XML-INTO command to fail with the following error:
   "While parsing an XML document, the parser found that the XML document does
not correspond to RPG variable PARM and the options do not allow for this. The
reason code is 5. "

That led me to believe that the problem lies with the data contained in that
record.  I did extensive testing to verify that record 36 was the source of the
problem but the data looked fine.  In fact, if I specify the employee that
corresponds to that record, the XML-INTO does its thing with no complaints.

When I was just about to give up, I noticed something unusual about the content
of the buffer that is populated by the RecvURLData procedure.  There was a
mysterious À character in the XML, outside of any tags (ie.
</close_tag>À<open_tag>).  This obviously isn't well formed
XML.  Also, not surprisingly, this character appears in the same node set that
corresponds to record 36.

I also verified that this character does not exist in the data returned in the
HTTP Response by creating a simple test program in .NET and using HTTP Analyzer
to view the raw content as it was received.  There was no sign of it.

Now to finally get to my questions.  Has anyone experienced any problems when
using iSockets with larger XML documents?  I do not experience any problems like
this with small results.  Also, have you ever seen this À character before?
 Could this be an encoding problem?  The SOAP response is UTF-8 which, to my
knowledge, shouldn't require any specific encoding instructions.

I hope I've provided enough information to give you a proper understanding of
the issue.  If not, let me know and I'll do my best to fill in any gaps.  I
really appreciate any help you can provide because I'm completely stumped by
this one.

Thanks,

Jarrod

I think this question is becoming an FAQ:

No, you don't need HTTP started. You can communicate over any port using
iSockets or regular SOCKETS and the HTTP port (port 80) does not need to be open. 
It happens to be the default behavior for iSockets since that is why it was
written (for web services) however, your local port 80 and HTTP server do not
need to be started.

In a previous post in this thread, Bob asked someone, "Do you have HTTP started
on your AS/400?  If not, you'll see that error," referring to
"gethostbyname(www.google.com) failed. errno(0) There is no error"

If we want to use iSockets to communicate with a server on our internal network,
do we need HTTP started?  Ours is stopped, and corporate folks are very nervous
about providing any possible way for outside folks to access our system.

Sounds like its trying to run in debug mode and go into debug on the ISOCKETS
*SRVPGM.  I don't ship the source for iSockets--yet.

I'm trying to use GetURLData to access a web service on a local server: when I 
run the calling program from WebSphere, I get the error message "Source file 
RPGTOOLS/QRPGLESRC(ISOCKETS) was not found", at *STMT:2100000001 _QRNI_NOMAIN.
I reloaded iSockets today, so it's the current build: am I missing something? 

Hi,

I am trying to post to a secure port with our bank to send credit card 
requests, my question is will iSockets use a Verisgn certificate in the POST 
if i install one in 'Digital Certificate Manager' ?

Thanks & Regards

and.... thanks Bob, your saving me a lot of time.

Hi,

I am trying to post to a secure port with our bank to send credit card 
requests, my question is will iSockets use a Verisgn certificate in the POST 
if i install one in 'Digital Certificate Manager' ?

Thanks & Regards

and.... thanks Bob, your saving me a lot of time.

Thanks for your reply Bob.  We are actually using CCSID 1146.
Regards
James

Yes, I've been there. 
I haven't had time to figure out the issue, but I believe it is a CCSID issue.
Are you using EBCDIC 37 for your job's CCSID? (Just wondering.)

Thanks.

Thanks for your reply but the standard message you described is the one that 
appeared before that one...

OpenURL(www.google.com:80)                                        
inet_addr(www.google.com) failed.                                 
errno(3021) The value specified for the argument is not correct.  

Attempting gethostbyname(www.google.com)                          
gethostbyname(www.google.com) returned 66.102.9.99                

Connecting...                                                           
-1 = OpenURL.connect(3)                                                 
OpenURL.connect() failed. errno(3425) A remote host refused an attempted
  connect operation.                                                    

the IP address returned in the first message (66.102.9.99) is correct for 
google.com and I can ping www.google.com from the command line.

That is a standard message as it tries to resolve to the URL. If you used an IP
directly, you would not see that message. But since 99.1% of URLs are ".com"
style, it first checks the ".com" name, fails, then converts it to an IP address
and checks that. You'll see another message in the jog saying it was successful
shortly after the one you've listed here.

I am getting the following error

Connecting...                                                            
-1 = OpenURL.connect(3)                                                  
OpenURL.connect() failed. errno(3425) A remote host refused an attempted 
  connect operation.                                                     

I have tried many different domains but still having the same problem.  is 
there a domain that I can test it on that is guaranteed to succeed or is this  
another problem something I may have missed?

Thanks

Bob,
I'm using a program called "WebSite-Watcher".
It has a very nice tool called "minibrowser". In it you can see a log of all the
commands sent to a web page when surfing to it.
Maybe you can use this tool to debug iSockets?

WebSite-Watcher can be freely downloaded and used for 30 days from:
http://www.aignes.com/download.htm

Yes. Everything is working like you are describing.
I'm looking into the problem. If you have any suggestions...

Bob,
I have tried your suggestion with the new iSockets you posted.
Added "callp   iSocketsCCSID(0 : 819)" just before the 
"callp     iSocketsOptions('DBG':*ON)" line
to the getgoogle example (changed the domain to "www.uzit.co.il" to check Hebrew
letters) and received the same "bad request" error.
Have you encountered the same error?

I just reposted the *SRVPGM because I forgot to EXPORT the iSocketCCSID.

It seems there's something else wrong. It tried it myself and I'm seeing that
mostly Google.com works but sometimes it does not. 

I have more research to do. :(

I can't compile the program.

This is the error I get:
Definition not found for symbol 'iSocketsCCSID'.

Looking in the service program,
There is no procedure named iSocketsCCSID there.

Try calling the iSocketsCCSID() api before anything else in the GetGoogle example program, as follows:
  

   callp   iSocketsCCSID(0 : 819)


Let me know if this makes any difference.
I've heard that some websites don't recognize UTF-8 and need plain old PC ASCII.

Bob,
I have tried version 1.2 and now I get results from the web site without
changing the job's CCSID. 
However, except from Google's site, every other site I tried returned the same
problem in the output.
Here is the output I received when trying to read index.html from www.cnn.com:

HTTP/1.1 400 Bad RequestDate: Wed, 25 Oct 2006 08:26:40 GMTServer:    
  ApacheContent-Length: 287Connection: closeContent-Type: text/html;
  charset=iso-8859-1<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML          
  2.0//EN"><html><head><title>400 Bad                                   
  Request</title></head><body><h1>Bad Request</h1><p>Your browser sent 
  a request that this server could not understand.<br                     
  /></p><hr><address>Apache Server at www.cnn.com Port                 
  80</address></body></html>                                             

The same "bad request" error is showing in all domains I tried.
This didn't happened with the previous version I tried (iSockets V1R1 - Build
2006-06-15) with changing the CCSID. I have reconfirmed it by trying it again
with the old version.

Sami,
Please download the and try the current version on the iSockets.net website.
I've changed things from CCSID(367) to 1208 (UTF-8), which seems to solve a
number of problems with iSockets.

More on your specific problem...
It turns out there are no mapping tables set up up for CCSID 424 to 367 until
you get to V5R4. Apparently this is what your problem was. 

I have a work around, but it requires that I change the code for iSockets again.
This fix will convert the data from the job's CCSID to something like
CCSID(1200) and then convert it to CCSID(367).  I'm working on figuring out if a
better CCSID should/could be used for TCP/IP, but until today, I had been told
that 367 was the best fit--apparently it is unless you're using 424.

Sami,
I've posted version 1.2 of iSockets to isockets.net
It requires V5R2 of OS.400.

Let me know if it works any differently for you.
Thanks!

I have changed the CCSID of the QRPGLESRC file from 37 to 424 and recompiled the
GetGoogle example. I run the program and it still didn't work. 
I changed the job's CCSID to 37 and run the program again. This time it worked
as before. I.E., changing the source's CCSID and recompile didn't solve the problem.
Maybe a recompilation of the service program should be in order? That, however,
only you can do, Bob.

Bob,
I used your source file in creating my program, so you may be right.
I'll change it's CCSID and try again.

Well, we've made some changes to iSockets and the next "point release" is due to be postest on Thursday.

Are your Source File's CCSID set to 37? If so, then that is the issue too.
The system seems to think that the CCSID of the module is the job's CCSID at runtime--that's an IBM 
design, not my own doing.

Bob,
I did recompile the GetGoogle example with different domains and the only thing 
that made it work is the changing of the job's CCSID from 65535 to 37.
I posted my job's initial settings in my previous message.

I'll look into it. It may be that I'm converting the request from CCSID(0) which
mean use the job's CCSID. However, if the job's CCSID is 65535, then it uses the
job's default CCSID instead. Which in your case is 424.

If you did not recompile GetGoogle or the other examples on your own iSeries
box, then that could be the issue. Is your job set to 424? If not, then simply
recompile the examples and try them again (without setting/changing your job's
CCSID). So do this in a fresh job.

Bob, 
I work in Israel and have tried your iSockets.
For almost 2 days I have struglled with the 'GETGOOGLE' example, trying to make
it work. Tried with different domains, talked with our sys admin (maybe the
problem was with the firewall), but nothing worked.
I stiil haven't been able to receive any response from the domain.

Finally, before giving up, I tried something else.
I changed the job's CCSID to 37 (was 65535) and that made the difference.
The job log showd some thousands of bytes received from the domain.

Here are some of the defaults my system have regarding the language settings:
(taken from dspjob)
Language identifier . . . . . . . . . . . . . . . :   HEB   
Country or region identifier  . . . . . . . . . . :   IL    
Coded character set identifier  . . . . . . . . . :   65535 
Default coded character set identifier  . . . . . :   424   


My question:
Is it necessary to change the job's CCSID to 37 or can I use another way to make
this work?

P.S.
Thank you very much for iSockets and every bit of info you put in the web.

user,

You are seeing the normal message retrieved by iSockets from the system.
It tries to get the socket using the domain name first, then uses the returned IP.
So these "not valid" messages are normal. THe one you need to watch is whether or not the data is 
returned. Which it seems to be based on your joblog messages.

Hello Bob.
I have a problem when doing the GET. It always returns to me that:
“the value specified for the argument is not correct.”
“the description one is not valid.”
But the connection is correct. 
What leaves from the GET this badly written or that step this incorrect one?
Thank's.



**************************************************************
http://192.168.208.50/SPTServiciosWeb/Test1
HOLA, | cómo | estás 
**************************************************************
Call geturldata ('192.168.208.50/SPTServiciosWeb/Test1 ')
OpenURL(192.168.208.50:80)                               
0 = OpenURL.connect(7)                                   
OpenURL(192.168.208.50) returning with socket handle: 7  
GET /SPTServiciosWeb/Test1 HTTP/1.0                      
El valor especificado para el argumento no es correcto.  
El descriptor no es válido.               
SendUrlData sent 37 bytes to socket 7     
Host: 192.168.208.50                      
El valor especificado para el argumento no
El descriptor no es válido.               
SendUrlData sent 22 bytes to socket 7     
                                          
El valor especificado para el argumento no
El descriptor no es válido.               
SendUrlData sent 2 bytes to socket 7      
***********************************************************

escapeXML converts < to ampersand followed by LT and similar. So if you're
already seeing that, then you don't need escapeXML. If you want to do that
(which is recommended by XML standards) then use escapeXML to do that.

I see my post did not work < becomes the ampersand followed by lt, semicolon

Bob,
I have a service program that returns some xml data. I have created a 
webservice to execute the service program. my problem is that while the XML 
looks ok for the part generated by the webservice, the XML I return gets 
messed up < becomes < etc. I have tried many ways around this problem. Will 
your escapeXML correct this situation?

I do not offer Systems Admin, so you should ask this question in the Forum, but
outside of the iSockets section.

When I PING WWW.GOOGLE.COM
I get "Host not Found".Looks like my iSeries is not configured to hit the web. 
But what I should do configure by iSeries to hit web using TCP/IP.......

If the examples don't work, check the joblogs and see what the errors are.
If your iSeries is connected to a network that allows you to go out to the
Internet via TCP/IP it should work. If your network does not allow you to do
that, it will not work. 

Try this command from Command Entry and see if you get positive feedback:

PING WWW.GOOGLE.COM

Here's what I get when I run it on my system:

Verifying connection to host system www.l.GOOGLE.COM at address   
  64.233.161.99.                                                  
PING reply 1 from 64.233.161.99 took 25 ms. 256 bytes. TTL 243.   
PING reply 2 from 64.233.161.99 took 25 ms. 256 bytes. TTL 243.   
PING reply 3 from 64.233.161.99 took 25 ms. 256 bytes. TTL 243.   
PING reply 4 from 64.233.161.99 took 25 ms. 256 bytes. TTL 243.   
PING reply 5 from 64.233.161.99 took 25 ms. 256 bytes. TTL 243.   
Round-trip (in milliseconds) min/avg/max = 25/25/25.              
Connection verification statistics: 5 of 5 successful (100 %).

I am one another like Drew waiting to start with webservices from AS400.
None of the examples work for me.Any help would be greatly appreciated.

Both. I dl'd the save file yesterday & installed it, so I think I'm current. 
The test program doesn't seem to accept the port-in-url format. 
The helpfile for the geturldata function says nothing about port. 

Any pointers on getting started with using web services from an as400?

Do you mean the example program or the subprocedure of that name?

A recent update to iSockets added the ability put the port following the domain
name:  'www.google.com:8001'  Normally the port parameter of the OpenURL
subprocedure is where the port would go. But some people wanted to embed it in
the domain name, so I made that change.

Does GetURLData always uses port 80? I don't see any way to pass a port number 
in. Having it in the url (eg, www.google.com:8001) like the brower accepts 
doesn't seem to work.

Re - problem opening .CHM file:
I finally got it to work by moving it to a non-network drive...

EdMan,

Yup, that's the plan.

Bob,
Silly question, but what happens if I upload the current iSocket srvpgm ? My 
existing code using it shoutl be fine.... correct ? The signature hasn't 
changed(?) has it ?

I have posted a recompiled version of iSockets out there just now.
It contains slightly revised joblog messages when the iSockets debugging
variable is on. It may provide a more clear joblog for those of you having
difficulty connecting with the GetGoogle example program.

Any help would be greatly appreciated ,Thanks

I downloaded the *SAVF on 24-APRIL-2006, Think I am having the latest

I just see only one message and thats it.

The latest version of iSockets logs more than just that one message in the
joblog. Is there anything else that is being logged?

Can somebody help on this ? I am having a AS400 connected to a network. The N/W 
is inside a Firewall. I need to access webservices from RPG. ADMIN instance  
HTTP services are just fine and running.

I'm not a Systems Admin, so you'd have to check with someone who is.

I checked my HTTP server instances are running.

But firewall , yes it is there and we have a proxy server and port number 
configured to get to internet from windows. What should I do or change to 
straighten this out from iseries ?

In Real time any corporate/organistaion is going to a have a their AS400 inside 
a firewall for security reasons.

Do you have HTTP started on your AS/400?
If not, you'll see that error.
If you have it started and have a firewall that blocks certain access, you can
see that error.

I am actually trying to call WebServices from RPG.

But to start with, I tried testing GETGOOGLE Sample, I got the following msg 
from the joblog.

"gethostbyname(www.google.com) failed. errno(0) There is no error"

Any bells ringing ?

Got it, Thanx Bob ...

I musta have fat-fingered something. Anyway got it, and I'll keep you posted on
the POS webservice ...

Thanx again ...

Ty

Ty,

I'm mot sure if you mean check to make sure I compiled at V5R1 or what?

Just in case, I did a DSPSAVF ISOCKETS and it displays that it is at V5R1M0.
I then downloaded it and placed into the iSockets.ZIP file we keep on the website.

Give it another try. 
I don't think anything is different from what was out there after 4:30 PM
yesterday, however.

can you give that another check

Ty

Good luck with the POS system.
Make sure you come back and tell us how great iSockets was.

Hey no problem ...

Thank you for your effort. It's a good system. 

We're getting a new POS system that we're going to feed it with your system.
Save me a WHOLE LOTTA work ...

Thanx.

Ty

Ty,
Repeat after me, "Bob is an idiot!"

Apparently I didn't use my "rebuild iSockets" CL program and just did CRTPGM on
it and savlib without specifying TGTRLS(V5R1M0).

I've fixed it now, it is out there with the V5.1 release on it.
Sorry!

That's what I did. But when I do I get this ...

Message . . . . :   File cannot be restored, displayed, or listed.            
Cause . . . . . :   The file was saved from a more recent release of the      
  operating system or the CD-ROM was not created correctly.  The operation was
  requested for save file ISOCKETS in library QGPL.                           

That's why I was asking if there is a release issue ...

No I problem, I'll just wite my own ...

It don't get much more straight forward than this Ty:

How to Upload/Install iSockets - Instructions
On the iSeries:
CRTSAVF QGPL/iSockets

On the PC, after you have downloaded the iSockets.zip and unzipped it:
FTP QGPL/iSockets
BINARY
NAMEFMT 1
CD /QSYS.LIB/QGPL.LIB
LCD "C:\[directory where you downloaded iSockets.savf]
PUT iSOCKETS.SAVF
QUIT

On the iSeries:
RSTLIB SAVLIB(ISOCKETS) DEV(*SAVF) SAVF(QGPL/ISOCKETS) 

Your restoring the *savf right ? Check the instructions again

Im getting the message "File cannot be restored, displayed, or listed. "

Ive tried both rstobj and rstlib

We're on v5r2 and I got it restored just fine..... what's the problem, maybe 
you have security issues

What is the minimal release level for isockets? Im on 5.2 and cant get it to
restore ...

Thanx

The PostURLData, GetURLData functions are wrappers that do everything in one
procedure. I guess I just didn't think anyone who used this stuff would want to
override the port assignment on those helper functions. 

I've updated the OPENURL function so that it now checks the URL for a trailing port number. 

Meaning this:
OpenURL('www.google.com:1038')

is now the same as this:
OpenURL('www.google.com' : 1038)

So your original code:
     D szDomain        S            128A   Varying Inz('notk400:10048')
     C                   eval      hUrl = OpenURL(szDomain)


Should now work the way you expect it to.

This is in the current build (April 7, 2006).

Your absolutely right, I amended the code as follows: -

     C                   Eval      szPort = 10048
     C                   eval      hUrl = OpenURL('notk400':szPort)

This works fine as far as the OpenURL procedure is concerned.  The problem I
have now is that when I execute the PostURLData, as the first parameter I pass
it the domain name. Previously I was passing it 'notk400:10048', this did not
work as we've already discussed.  However I cannot pass it 'notk400' without the
port but there is no parameter on PostURLData for the port.

I'm encouraged that I'm moving in the right direction, just a few last hurdles
to cross.

As ever, your help is greatly appreciated.

Thanks
Steve

That's a PORT ID. It does not get coded like this:

'notk400:10048'

It is passed as the second parameter of the OpenURL function.

  OpenURL('notk400' : 10048)

Did you read the documentation?

Thanks

I attempted to use the GetGoogle as an example and got the same list of errors.
As you suggested this suggests a problem connecting through our server to the
www.  However, as I'm trying to use a web services app on our own server I
attempted using that address to connect to. The following code was changed in
GetGoogle: -

     D szDomain        S            128A   Varying Inz('notk400:10048')
     C                   eval      hUrl = OpenURL(szDomain)

notk400:10048 is the network address that I'm trying to connect to on our server.

I'm getting the following messages: -

inet_addr(notk400:10048) failed. attempting gethostbyname(notk400:10048)
  errno(3021) The value specified for the argument is not correct.      
gethostbyname(notk400:10048) failed. errno(0) There is no error.        
HURL = -1     

As you suggested the first message may  be misleading. The second message is
confusing, on one hand it's saying it's failed, on the other hand 'errno(0)
there is no error' is telling me it's been successful, however it's still
returning -1.

Thanks for you help so far, any more ideas?  

Steve

SteveB,

The first error is just an error before trying the second way of connecting.
It is not unusual. In fact, I get it as well.

The rest indicates that something else is wrong.
Do you have the HTTP service started on your machine? Do you have a firewall
running are you inside/outside of a DMZ? If so, all these things can impact what
you are doing.

Try the GetGoogle example first. If it works, you should be okay, if not, then
it is probably a networking issue--and we all know, that is what the guy with the
cables is for.

Hi 

I'm attempting to use your program WEBSERVEX1 by way of an example before using
isockets in our applications.  The procedure PostUrldata is returning -1, in the
job log I'm getting the following messages: -

inet_addr(www.w3schools.com) failed. attempting gethostbyname(www.w3schools.com)
errno(3021) The value specified for the argument is not correct.               
                                
OpenURL(www.w3schools.com)connect() failed. errno(3425) A remote host refused an
attempted connect operation.                                                   
            
OpenURL(www.w3schools.com) Failed. errno(3425)
NBYTES = -1                                                               

It looks to me that it does not recognise the url www.w3schools.com, and hence
cannot open it.

I understand the principles but am struggling to put them into practice, and it
would be nice to get the example working before progressing further.

Any help greatfully appreciated.

Does your service work similar to paypal?
If not, then I can't help.

If you go to the isockets.net homepage and scroll down, you'll see the actual
PayPal routine that I use--modified to remove the user codes and security bits.

-Bob

 Bob,
Sorry to be a pain. We are trying to do the same thing, process paypal 
transactions only using Cardinal's Sentinel as a go between. When you send 
your https request to paypal are you using the default port or are you 
specifing a port say in the openURL?  Thanks in advance

I haven't tested iSockets with HTTPS (SSL) connections.
There is a slew of completely different APIs that IBM provides for SSL that just
are not the same as most other platforms. 

I use HTTPS with paypal.com and iSockets. But it is a one-way thing. I post a
HTTPS://www.paypal.com request, but don't wait for a reply. They in turn, send
my CGI program a response. This allows the web server to use its built-in SSL
stuff and bypass coding all those secure sockets layer APIs IBM requires.

So if you can reconfigure your stuff to work like that, you can make it work. If
not, I don't see a near-term solution.

thanks, that fixed the problem with the help text. Another question, I tried 
using the PostUrlData with a HTTPS site and when it tries to do the OpenUrl 
the program just locks up. Do I need to do something different to get the 
PostUrlData to work with a HTTPS connection? I'm guessing it has something to 
do with the port number needing to be something other than 80.  Thanks

This is typically a networking issue.
Read the following article on the topic:

http://support.microsoft.com/kb/902225/

FYI, I've also posted the isockets.chm file as a .ZIP so you can download it and
extract it onto your local PC without going through the usual routine.

Bob, 
I'm trying to access the help file and when I open it, I get an action 
cancelled screen like you would get for a webpage on the right side, even 
though it is showing the help index on the left. Happens whether I try and 
open it from the isockets web page or save it to my desk top and open it.  
Thanks in advance

Bob, 
I'm trying to access the help file and when I open it, I get an action 
cancelled screen like you would get for a webpage on the right side, even 
though it is showing the help index on the left. Happens whether I try and 
open it from the isockets web page or save it to my desk top and open it.  
Thanks in advance

iSockets for RSS feeds.

You can use iSockets to read RSS feeds from websites. Just write an RPG IV
routine that you call at start up of an RPG program. Go out to the RSS field URL
and grab the XML.

Then if you're using OS/400 V5R4, RPG IV has the XML-INTO opcode that allows you
to  extract the XML from the RSS feed. Lots of "buzz words" but pretty easy at
the end of the day.

I've updated the iSockets helptext file and also added a few more joblog
messages (when debugging is turned on) to the service program itself.

Sounds like a configuration issue. Do you have DNS set up on your box?
I don't do systems-admin so don't expect much help beyond asking this
question, from me.

Hi Bob
Tried again as downloaded

call geturldata  ('www.google.com/index.html   '   )       
gethostbyname() failed. errno(0) There is no error.  
OpenURL(www.google.com) Failed. errno(0)   

Pgm comes back without bombing (it still bombs if:   /index.html  
is not included on the call )

Debug values if they help:
PHTML = SPP:FCAF6AD13B003180
NBYTES = -1     
SZDOMAIN =  'www.google.com                                      
SZPAGE =    '/index.html         

Same problem with getgoogle
call       GETgoogle                                         
gethostbyname() failed. errno(0) There is no error.

Sorry about the stress Bob. Where can I/What can i look at on
our system 

The socket isn't opening on the OpenURL() statement in the example program.
So then it tries to do a SendURLText to a socket ID of -1, which fails...
I don't think the examples check for a bad socket return values... 
Maybe I need to look at them again.

I can't test it with www.rpgiv.com since it is blocked from within
my machine due to a networking configuration issue.

I've added more logging information to the GetURLData example just now.
Try it again with the Feb 21 build (now on the website).
It should tell us more specifically where you're having a failure.

Did you try the "getgoogle" example program?

Hi Bob
Thanks for reacting so quickly. 
Sorry. Not getting any further (I'll blame myself first)
New version downloaded today (German machine??) and called without any 
recompling. 
 
 call geturldata ('www.rpgiv.com/index.html ')        (<- with blank)         
 GET        /index.html HTTP/1.0                       
 The input value for the arguement is not correct. 
 Descriptor not valid.    
 Descriptor not valid.    
 SendUrlData sent -1 bytes to socket -1       
 Host: www.rpgiv.com 
 The input value for the arguement is not correct.
 Descriptor not valid.    
 Descriptor not valid.    
 SendUrlData sent -1 bytes to socket -1       

 The input value for the arguement is not correct. 
 Descriptor not valid.    
 Descriptor not valid.    
 SendUrlData sent -1 bytes to socket -1       
 Pointer not valid for given position.

 Then a break off with dump at 
 00008600 in GETURLDATA 

 Same happens in Debug mode 
 - can't even follow through in debug into ISOCKETS as i get the m
essage

File QRPGLESRC in library RPGTOOLS with member ISOCKETS not found.
(Tried creating this library and putting a copy of the souce file/member into 
it to get further but it didn't help)

Do we only have a RPG-Problem or do we have something wrong with:
TCP-IP/HTTP/Apache/Version on the AS400?

Thanks Michael 

I posted a new build of iSockets tonight (2/20/2006) that includes a new example
program. This one is named WebServEx1 (Web Services Example 1).

Call it as follows:

call  webservex1  parm(xx)

Where xx is a numeric value of degrees. The program calls a web services routine
that converts the value from Celsius to Fahrenheit. It returns the Fahrenheit 
in XML.

If you have OS/400 V5R4, then you can use XML-INTO opcode and %XML to extract
the converted value.  All that is done in the example, but uses conditional
compiling to insert the XML-INTO code.

I don't have access to V5R4 so if anyone is able to test it, that would be great.

Michael,

Download the current build (uploaded rescently) and see if you still get the
same results.

If so, post the joblog messages you get after you run it.

Hi Bob
Trying to get the isockets-download to run. I seem to be having Sri's problem
- pity he didn't say how he fixed it.
All 3 of the pgms - GETGOOGLE/GETURL/GETURLDATA - as downloaded and not 
recompiled or anything bring back a -1 value in  hUrL after the 
OpenURL -- am working in debugmode.
Same errors messages/job log entries as for Sri (other than in German).
HTTP is running on Port 80.
I'm connected to the network via VPN which shouldn't make any difference?
Version is 
  iSockets V1R0 - Build 2006-02-10      

I'm lost for an idea
Thanks Michael

The helptext is now available online at www.isockets.net

Sri,
The response is up to the web services provider.
For example, Google has an interface/API you can call using iSockets that will
return XML data. FedEx will return package tracking informaiton in XML
format, as will UPS. 

But, no, you can't "ask for" XML instead of whatever the service is going to return.

When we use paypal, we use iSockets to accept the transaction, turn it around
and send it back to them (their way of confirming that we got it) and then they
send the response back as plain text. We just have to look after the HTTP header
they send for the data.

Hi, 

I finally made GetUrlData work. 
Response i get back from the url is in HTML form. 
How can i get response back in xml form. 

I am not sure if i am asking the right question or not. If iseries using 
geturldata is trying to get response from a webservice, response should be in 
xml. 

Jim,

There is a pending HTTP header that can be used for authorization but its format
depends on what security model is being used. I think the following should work.

Authorization:  user  cozzi:rosebud\n

For example:

     C                   callp     SendUrlText('Authorization:  user ' +
     C                                         %TrimR(szUser) + ':' + 
     C                                         %TrimR(szPwd) + '\n')

Then send your "GET" request and follow everything with with the
extra linefeed (\n), then you're ready to receive.

Let us know if this works.

Here's a new example, I just wrote and tested on my machine.
It is called "Get Google". 

It is in the download section:

http://www.rpgiv.com/cgi-rpg/viewsrc?FILE=QRPGLESRC&LIB=RPGLAB&MBR=GETGOOGLE

Is there a way to pass a user id and password to the functions?  I hope to
interact with a secured apache server running on the iseries that authenticates
through a validation list.  The OpenURL function returns a result of 3 the
SendURLText function returns 61.  The RecvUrlData returns the following in
szhtml:(the special characters are cr/lf)
HTTP/1.1 401 Authorization RequiredDate: Mon, 06 Feb 2006 
19:42:58 GMTServer: ApacheWWW-Authenticate: Basic realm=
"LAW7T"Content-Length: 205Connection: closeContent-Typ
e: text/html; charset=ISO-8859-1<!DOCTYPE HTML PUBLIC "-
//IETF//DTD HTML 2.0//EN"><HTML><HEAD><TITLE>401 Authoriza
tion Required</TITLE></HEAD><BODY><H1>Authorization Requir
ed</H1>Unauthorized - authentication failed.</body></html>
I get the same results through a browser when I cancel out of the authentication
window.  
Any suggestions would be greatly appreciated.

CALL PGM(GETURLdata) PARM('www.google.com/index.html ')
Descriptor not valid.                                  
SendUrlData sent -1 bytes to socket -1                 
Descriptor not valid.                                  
SendUrlData sent -1 bytes to socket -1                 
Descriptor not valid.                      
Recv -1 bytes from sock -1                 
Closing socket -1                          
GetUrlData www.google.com returned 0 bytes.

This is what i see in my joblog. 
I am not sure if i am missing something. Any help is greatly appreciated. 

Thanks

Yes, I don't like the GetURL example. The GetURLData is probably the one you
want to use. It uses a built-in subprocedure to do what GetURL attempts to do in
example code.

Thanks Bob for your quixk response on this. 
I complied GetUrl as GETURLTEST in my library made no changes just compile. 
What should i do to ensure proper port is open and system picks up the port 
that it is suppossed to use. 

Thanks
Sri

Sri,

Not sure what GetURLTest is (did you write it?) but when I call the included
GetURLData with the same parameter, I get this:

CALL PGM(GETURLdata) PARM('www.google.com/index.html')
SendUrlData sent 26 bytes to socket 0                
SendUrlData sent 2 bytes to socket 0                 
Recv 1380 bytes from sock 0                          
Recv 1367 bytes from sock 0                          
Recv 0 bytes from sock 0                             
Closing socket 0                                     
GetUrlData www.google.com returned 2747 bytes.       
HTTP/1.0 200 OK                                      

Looks pretty good to me.
If you merely cloned the GetUrlData program, then what else might be wrong
is that you don't have proper port open on your system.
Make sure you have the current version. The one I used to run the above test
is as follows:

>> call isockver                    
   iSockets V1R0 - Build 2006-01-23

Hi Bob, 

Never worked on sockets and web services before. Found your code and downloaded 
it to give it a try. Right then our team decided to have a proof of concept so 
that Iseries can consume a web services. 
I did the following to see what i get back in the return value. I am getting 
the following in joblog. Help Please. By the way great and wonderful work. 
CALL PGM(GETURLTEST) PARM('www.google.com/index.html')  
Descriptor not valid.                                   
SendUrlData sent -1 bytes to socket -1                  
Descriptor not valid.                                   
Recv -1 bytes from sock -1                              
Closing socket -1

Yep, you need to have an HTML page returned to you, so what's happening is the
HTTP request is asking for a page with no name. So you get crap.

Try: www.google.com/index.html

It should work.
FYI, the GetURL program is just an example, and not written for production
purposes. The "parser" I wrote in the GETURL program (you have the source for
that) to look for the html page you're requesting only works when you do things
perfectly.

Bob,

I'm a first time caller and a big fan.  

Thanks for all your efforts to promote the AS/400 -- iSeries -- i5.

I recently loaded iSockets on my model 170 running V5.2.

I called iSockets/geturl ('www.google.com ') and got this program message.
As detailed below, there appears to be a message percolating to the surface 
that 
got stuck on the spellings of OPENURL and OpenURL.

Can I do anything about this?

Is this a problem caused by differences in operating system versions?

Thanks in advance for any help with this problem.
+-------------+
Command Entry                       
S1032CRM 
                                                          Request level:   1   
All previous commands and messages:
   ? C                                                                         
     Application error.  CPF2479 unmonitored by QRNXIE at statement            
       0000000021, instruction X'0000'.                                        
   > call isockets/geturl ('www.google.com ')                            
     Call stack entry not found.                                               
     The call to OpenURL ended in error (C G D F).                             
   ? C                                                                         
+-------------+
Additional Message Information                         
Message ID . . . . . . :   CPF2479       Severity . . . . . . . :   40         
Message type . . . . . :   Escape                                              
Date sent  . . . . . . :   02/02/06      Time sent  . . . . . . :   11:56:28   
Message . . . . :   Call stack entry not found.                                
Cause . . . . . :   Call stack entry OPENURL, specified for the send, receive, 
  move or delete message operation, could not be found in the call stack.      
Recovery  . . . :   Change the call stack entry name or be sure the specified  
  entry is in the call stack when doing the requested operation.               
+--------------+
                              Display Call Stack
                                                            System:   S1032CRM 
Job:   QPADEV000Y     User:   GREG_MBS       Number:   954727                  
Thread:   00000251
Program
Rqs    or
Lvl    Procedure   Library     Statement        Instruction
       QCMD        QSYS                            0469
     < PEP_WF303R  MENULIB
       WF303R      MENULIB     0000000379
       USER_MENU   MENULIB     0000000748
       DO_C2OPT    MENULIB     0000001602
       system      QSYS        0000000006
       QCMDEXC     QSYS                            0129
  1    QPGMMENU    QSYS                            0560
     < PEP_GETURL  ISOCKETS
       GETURL      ISOCKETS    0000007500
       OpenURL     ISOCKETS    0000028500
     < lException  QSYS        0000000021
     < ndleCallFc  QSYS        0000000007
     < _DFT_ERROR  QSYS        0000000002
       _QRNX_INQ   QSYS        0000000017
       InqMsg      QSYS        0000000004
       QMHSNDPM    QSYS                            0988
       QMHSNINQ    QSYS                            00ED
       QMHDSEXT    QSYS                            00FB
       QDMACCIN    QSYS

I just finished the second article on iSockets for MCPressOnline.com's RPG Developer newsletter.
It will be out next week along with the RPG IV enhancements piece I did for V5R4.

There should be no difference in /free and normal RPG IV coding/use of iSockets.

Thanks Bob! Worked great. I had a problem running it in Free Format. But 
Formated RPGLE ran without any problems!  Thanks again!

That's Great!

Now go tell your friends, so that everyone starts using iSockets. 

-Bob

OK great, that seems to have done the trick.  I was able to see the entire 
source from your index.html in the variable szHtml.  Worked like a charm. 
Thanks Bob.

WHen the recv() function is called, it reads up to the number of bytes specified
on the buffer-length parameter. 

If fewer bytes are ready, it reads the bytes that are ready and returns.
You need to continue to read until a value of zero is returned, or an error
occurs (i.e., returns -1).

Here's how I changed the GetURL example:

 C                   dou       nBytes <=0                                
 C                   eval      nBytes =                                  
 C                                RecvUrlData(hUrl:pHtml:%size(szHtml))  
 C                   if        nBytes > 0                                
 C                   callp     joblog(%subst(szHtml:1:nBytes))           
 C                   endif                                               
 C                   enddo                                               

I also updated the iSockets GetUrldata() function so that it does a similar thing.

The new version of iSockets with these changes is Build 2006-01-23 and later.

To check the version you have installed, call the iSocketsVer program.
Then press F10 from CMD Entry to see the low-level messages in the joblog.

But the bottom-line is that if you want to use iSockets in your applications,
you have to keep reading until you get a zero-value returned (or -1 if an error
is returned).

I see the problem....

I just went into debug mode and walked through the following call:

>> callp geturl  'www.google.com/index.html'

And it returned everything from "HTTP/1.0 200 OK" through the </html> tag.
The joblog showed this:
SendUrlData sent 48 bytes to socket 3  
Recv 2747 bytes from sock 3            
Closing socket 3                       

I then ran this test:

>> call geturl 'www.rpgiv.com/index.html' 

And again everything was returned just fine, with the joblog displaying this:

SendUrlData sent 47 bytes to socket 3  
Recv 16533 bytes from sock 3           
Closing socket 3                       

Since I was in debug mode, the process of receiving the data from the remote
location took longer ( I had to step through the code to get to the RecvURLData()
function. So always had a successful result.

But now I ran the tests again, not in debug mode and wrote out the results to a 
log file. And I see the same things you both are seeing.

I will look into it and post a not when I have this fixed. I'm sure its just a 
timing issue and in the RecvURLData, I will have to loop around and get more data.

I believe I ran into a similar problem as Jim Taylor.  I recompiled GETURL in 
debug mode and when I got to the line: eval      hURL = OpenURL(szDomain) The 
value of hURL was '3'.  The value of szDomain was 'www.rpgiv.com' and szPage 
was ' /index.html ' so I have no idea where the '3' came from.  Dump says Pgm 
status: 00202, Statement in error 00007800, RPG Routine: RecvURLD, Message 
Data: Receiver value too small to hold result.  My lame guess is that perhaps 
I'm not re-compiling correctly.  I compile as CRTBNDRPG, PGM=ISOCKETS/GETURL, 
ACTGRP=QILE, BNDDIR=ISOCKETS/ISOCKETS, DBGVIEW=*SOURCE.  I call with CALL PGM
(GETURL) PARM('www.rpgiv.com/index.html').  We are hoping to use this to 
retrieve html code from our external site (for headers footers etc) to use in 
our RPG CGI pgms that we server from the AS/400 for web forms.  This seemed 
like a good way to do this rather than maintain this html on two platforms.  
Anyway, I know nothing of Sockets programming so I highly suspect "user 
error".

The last line of the varable szHtml in debug mode is this 

1381   'r>      <td class="lc_wedge"><img src="/share/i            '   
1441   '                                                            '   


That is about the 20th line of the website (HTML Code) (There are 341 lines for 
this page)  

Please let me know if I cand send you anything.  Thanks!

Then if you're only getting 1428 bytes, you have to see what was recieved.
Was it everything from the page? Remember, HTML isn't that big, so you could get
a few dozen, a few hundred or a few thousand bytes.

Can you dump or use debug and look at what you're getting back and verify what
it is?

 -- Sorry for the many posts. I hit refresh.. Sorry ----

I have the nBytes defined as 15 S 0   and szHtml defined as 4096 A

The number of bytes returned will be (in the example below) equal to %size(szHtml)

What is the size you've declared the return field?

Q:  RE:  Can I use iSockets to read a webpage into my RPG IV program?

I tried using the simple routine have you have shown on this page as an 
example, but I only receive the first 1428 Characters of the webpage. 

I have nBytes defines as 15 S 0. 

Any Ideas?  Thanks.

I was running GETURL as it came in the save file.  I was in debug mode, stepping
through each line.  The halt occured at line 78 (RecvURLData).  I will download
the latest file and review the docs.

Another thing to try,

Recompile the RPG program example and when you call it, add a blank to the end
of the URL. That's the way it tries to figure out where the URL ends.

I have to go to a client all day today, so I'll look at this tonight.
Please give me specifics. Are you calling the example app that was included? Did you write your own? etc.

Thanks.

Where you in debug mode?

Anyway, can you post you call to GetURLData... the docs for that are just in the
/COPY today. Next weeks issue of my eNewsletter will contain the docs for that
interface.

There is a program named GetURLData that may do what you want.

YOu have to remember, some websites don't allow this kind of random access to
their pages.

Besides restoring the library, is there any other setup or configuration needed?

I called geturl in debug, passing 'http://www.google.com' as the parameter.  Up
through lines 75 and 76 (OpenURL and SendURLText) everything is fine but when
RecvURLData is executed, a halt occurs in isockets.  Since I don't have that
source I can't tell you where the error occured, but I have the following lines
in the job log:

Descriptor not valid.                                              
SendUrlData sent -1 bytes to socket -1                             
Descriptor not valid.                                              
Recv -1 bytes from sock -1                                         
Receiver value too small to hold result.                           
File QRPGLESRC in library RPGTOOLS with member ISOCKETS not found. 
                                                                   
Last request at level 4 ended.                                     

Any suggestions would be greatly appreciated.

Should be.
What web services?

I just reviewed the Google Web Services API and it seems to be based on SOAP.
Effectively you would use OpenURL to open to the base domain.
Then you would use SendUrlText() to write the POST to google, along with the XML
you've created for the SOAP request/message.

Is it possible to use this service program to call the google web service ?

iSockets Version 1.0 is now available for free download.
Visit www.iSockets.net

Look for the article on iSockets on Wed 18 JAN 2006 at:
www.MCPressOnline.com/midrangedev

Q: What utility procedures are available in iSockets?

A: There are two general purpose tools in iSockets. Both have been ported from
RPG xTools, but do not require xTools (iSockets is free).

(1) Character conversion between CCSIDs. It is important to be able to convert
between CCSIDs when doing Web Services. Why? Because you are not using the Web
Server on the iSeries. Normally the web server would convert from EBCDIC to ASCII,

The utility that does this conversion is the iconv() API. iSockets wraps the
iconv() API along with the corresponding iconv_open() and iconv_close() APIs to
allow you to use them much easier.

For example, iconv() works by first setting up a conversion environment. Rather
than create that environment each and every time iconv() is called, the
environment is created once, and then released when you are finished with it.
This gives you better performance that other methods for conversion.

iSockets includes the following wrappers for iconv():

  openCvtCCSID(hConv : fromCCSID : toCCSID)  // Start the iconv environment.
  cvtCCSID(hConv : fromData : nLen : toData : toLen)  // cvt to the target CCSID.
  closeCvtCCSID(hConv)  // Close the iconv environment.

This approach allows you to open multiple iconv() conversion environments at the
same time.

The second utility included with iSockets is the encodeURL and encodeURLComponet
APIs. These subprocedures properly encode a URL string that may need to be sent
to a remote web server. 

Q: Can I use iSockets to read a webpage into my RPG IV program?

A: Yes. You open the website and specify the page you want and then receive the
response. The response will be the webpage's HTML. You need to insure that your
receiver variable is large enough to hold the entire webpage. An auto-extend
user space might be a good choice in this style of application.


Here's a simple routine to do that:

   C                   eval      hUrl = OpenURL(szDomain)                     
   C                   eval      nBytes=SendURLText(hUrl:'GET http://'+       
   C                                    szDomain+szPage+' HTTP/1.0\n\n')   
   C                   eval      nBytes =                                     
   C                                RecvUrlData(hUrl:pHtml:%size(szHtml))     
   C                                                                          
   C                   callp     CloseURL(hUrl)                               
                             
This assumes the szDomain field contains an address like "www.rpgiv.com" and
that  szPage contains a webpage such as "/index.html".

After this routine is performed, the field szHTML will contain the html from the
requested webpage, the raw HTML, just like a browser would receive. So all the 
HTML tags and whatnot will be in the szHTML field.

iSockets is a free service program written by Bob Cozzi that allows you to more
easily connect an RPG IV program with a web services infrastructure. You no
longer need to know and write with SOCKETS to perform this kind of task from
within RPG IV.

You can download iSockets from www.rpgiv.com/isockets or go to isockets.net

iSockets is a service program that includes several helper functions to make
connecting to Web Services easier. Some of the functions include:

OpenURL - Open a URL or IP address.
SendURLData - Send raw data (bytes) to the open URL.
SendURLText - Send text strings to the open URL.
CallURLpgm - Call a CGI program on the web server.
RecvUrlData - Receive a reply back from the web services.
CloseURL - Close the open URL.

In addition, there are several conversion tools to help manipulate the data you
would normally send and receive from a web services website, including:

EncodeURI - Encode (sometimes called "escape") a parameter being sent to a CGI
program on the web services system.

UnEncodeURI - Unencode (sometimes called "unescape") a string of data received
from a CGI program on the web services system.

CvtCCSID - Convert between different CCSIDs.