[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTPAPI, RPG and COBOL



   Hi Thomas ;
   I come back to work after a slight break, I will further analyze your
   answer and I'll be back with a detailed reply.
   Thank you for all the interest you have shown to my requests.
   You rock :)

   2016-02-01 7:06 GMT+00:00 Thomas Raddatz <[1]thomas.raddatz@xxxxxx>:

     I am more and more confused. The first thing that confuses me is
     that it appears to me as if you still use the following procedure
     prototype for your end-element callback procedure:
     � D Callback� � � � PR� � � � � � � � � extproc
     (p_callback)
     � D� �userdata� � � � � � � � � � � *� �value
     � D� �depth� � � � � � � � � � � �10I 0 value
     � D� �name� � � � � � � � � � � 1024A� �varying,
     const
     � D� �path� � � � � � � � � � �24576A� �varying,
     const
     � D� �retval� � � � � � � � � � � � *� �value
     � D� �Attrs� � � � � � � � � � � � �*� �dim
     (32767)
     � � � � � � � � � � � � � � � � � � � � const
     options (* VARSIZE)
     The procedure prototype above has been re-formatted from:
     Callback PR extproc (p_callback)
     � userdata * value
     � 10I depth value 0
     � 1024A varying, const name
     � 24576A path varying, const
     � retval * value
     � Attrs * dim (32767)
     � � � � � � � � � � � � � � � � � � const options
     (* VARSIZE)
     This prototype is not the right one to use! It is the one that Scott
     uses internally to either pass a string or a data structure for
     parameter 'retval', depending on the setting of http_XmlReturnPtr().
     That is some kind of a "trick" or "hack". You definitely need to use
     the following prototype as long as you do not call
     http_XmlReturnPtr(*ON):
     � D Callback� � � � PI
     � D� �UserData� � � � � � � � � � � *� �value
     � D� �depth� � � � � � � � � � � �10I 0 value
     � D� �name� � � � � � � � � � � 1024A� �varying
     const
     � D� �path� � � � � � � � � � �24576A� �varying
     const
     � D� �value� � � � � � � � � � 65535A� �varying const
     � D� �attrs� � � � � � � � � � � � �*� �dim(32767)
     � D� � � � � � � � � � � � � � � � � � �const
     options(*varsize)
     Please notice the little difference between your 'retval' and my '
     value'. This parameter must be defined as 'alpa-numeric', bassed by
     'const'. It must not be a pointer passed by value. If you stay with
     the pointer passed by value your pointer will point to the character
     data of the field, prefixed with two length bytes. Most likely that
     is not what you want to get.
     The second thing confusing me is your "COBOL parser (WSPARSER)". Is
     it really a XML parser like Expat or is it a synonym for the end
     element callback procedure?
     I truly do not know Cobol but maybe it would help, if you posted the
     procedure interface (or whatever it must be called in Cobol) of your
     end element callback procedure. Actually error messages "Identifier
     does not exist." is returned when EVAL is used for displaying a non
     existing field, for example EVAL FOOBAA will truly return
     "Identifier does not exist." for your program, because most likely
     there is no field "FOOBAA".
     Thomas.
     -----Ursprüngliche Nachricht-----
     Von: [2]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
     [mailto:[3]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von
     Salaheddine Zaki
     Gesendet: Freitag, 29. Januar 2016 20:35
     An: HTTPAPI and FTPAPI Projects
     Betreff: Re: HTTPAPI, RPG and COBOL

   Hello Mr. Thomas
   First of all, thank your very much for your responssiveness.
   Please note that this is my first confrontation with RPG400. so please
   excuse my ignorance. I am a beginner.
   Indeed, the provided code has been copied from HTTPXMLR4 module I found
   that my specific COBOL parser (WSPARSER) is called after the execution
   of the procedure endElement, and if I understand correctly, it should
   return as back to my parser the following structure:
   Callback PR extproc (p_callback)
   � userdata * value
   � 10I depth value 0
   � 1024A varying, const name
   � 24576A path varying, const
   � retval * value
   � Attrs * dim (32767)
   � � � � � � � � � � � � � � � � � � const options (*
   VARSIZE)
   To further explain the scheme, I have a main COBOL program (titled
   WSCALL) that calls the RPG procedure� HTTP_URL_POST_XML by passing the
   following
   parameters:
   01 WSAA-URL-POINTER POINTER.
   01-WSAA STARTPROC-POINTER PROCEDURE-POINTER.
   01-WSAA ENDPROC PROCEDURE-POINTER-POINTER.
   01WSAA-RETURN-CODE PIC S9 (9) BINARY VALUE 0 01WSAA-SOAP-POINTER USAGE
   IS POINTER.
   01WSAA-OUTPUT-POINTER USAGE IS POINTER.
   01 WSAA-URL-SPLIT.
   � �03 WSAA URL-LEN-PIC S9 (4) BINARY.
   � �03 WSAA-URL-BODY PIC X (100)
   � � � � VALUE "http: //xx.xx.xx.xx: yy / rest / WSNAME".
   01-WSAA URL PIC X (102).
   01WSAA-SOAP-SEND-ENVELOPE PIC X (2500).
   01WSAA-SOAP-LEN PIC S9 (9) COMP-4.
   01WSAA-TIMEOUT PIC S9 (9) COMP-4 VALUE 60.
   01WSAA-USER-AGENT PIC X (64) VALUE "http-api / 1.23".
   01WSAA-CONTENT-TYPE PIC X (64) VALUE "text / xml".
   01WSAA-SOAP-ACTION PIC X (64)
   � � �VALUE "http: //xx.xx.xx.xx: yy / rest / WSACTION".
   To call my specific PARSER WSPARSER, I affected the
   WSAA-ENDPROC-POINTER pointer to the parser through the following
   statement:
   SET-WSAA ENDPROC-POINTER TO ENTRY
   � � � � � � � PROCEDURE LINKAGE "WSPARSER".
   the Calling of the procedure HTTP_URL_POST_XML is as follows :
   CALL PROCEDURE
   � � "HTTP_URL_POST_XML" USING BY REFERENCE WSAA-URL
   � � � � � � � BY VALUE WSAA-SOAP-POINTER
   � � � � � � � BY VALUE WSAA-SOAP-LEN
   � � � � � � � BY VALUE WSAA-STARTPROC-POINTER
   � � � � � � � BY VALUE WSAA-ENDPROC-POINTER
   � � � � � � � BY VALUE WSAA-OUTPUT-POINTER
   � � � � � � � BY VALUE TIMEOUT-WSAA
   � � � � � � � BY REFERENCE USER-AGENT-WSAA
   � � � � � � � BY REFERENCE CONTENT-TYPE-WSAA
   � � � � � � � BY REFERENCE WSAA-SOAP-ACTION
   � � � � � � � � � � � � � � RETURNING WSAA-RETURN-CODE.
   So far everything is going well. through the debugging, I realized that
   my parser WSPARSER is called whenever the parser HTTPXMLR4 reaches the
   end of a tag, in this case, it's the endElement procedure that's
   called, it should return the mentioned structure in top (Callback...)
   So to answer your questions, for me my programme use a single callback
   that's endElement.
   My problem is that my PARSER WSPARSER doesn't receive the Attrs (array
   of pointers), as already explained an EVAL display me out that
   "Identifier does not exist."
   My need is so simple, at the call of my parser I want to get the name
   of the attribute, value and an array containing the atrributs of the
   tag and theirs values.
   Thank you for all.
   Best regards.
   2016-01-29 6:58 GMT+00:00 Thomas Raddatz <[4]thomas.raddatz@xxxxxx>:
   >� � Honestly I am not sure about what you try to accomplish.� How
   many
   >� � callbacks to you use? What do you use the "endElement" callback
   for?
   >� � Actually it is used internally by the HTTPXMLR4 module:
   >
   >
   >� � endElement� � � B� � � � � � � � � �export
   >
   >� � endElement� � � PI
   >
   >� � � root� � � � � � � � � � � � � � �   likeds(elemroot)
   >
   >� � � name� � � � � � � � � � � � � *� �value
   >
   >
   >� � And what is the "Callback" procedure used for? Your example code
   has
   >� � been taken from the HTTPXMLR4 module. It is used to call the
   >� � user-defined end-element callback that has been specified at the
   >� � http_url_post_xml() statement.
   >
   >
   >� � p_callback� � � s� � � � � � � �*� �procptr
   >
   >� � Callback� � � � PR� � � � � � � � �   extproc(p_callback)
   >
   >� � � userdata� � � � � � � � � � � *� �value
   >
   >� � � depth� � � � � � � � � � � �10I 0 value
   >
   >� � � name� � � � � � � � � � � 1024A� �varying const
   >
   >� � � path� � � � � � � � � � �24576A� �varying const
   >
   >� � � retval� � � � � � � � � � � � *� �value
   >
   >� � � Attrs� � � � � � � � � � � � �*� �   �dim(32767)
   >
   >� � � � � � � � � � � � � � � � � � � � �const
   options(*varsize)
   >
   >
   >� � Usually you need to create a callback procedure with the
   following
   >� � interface:
   >
   >
   >� � � �D EndOfElement� � PI
   >
   >� � � �D� �UserData� � � � � � � � � � � *� �value
   >
   >� � � �D� �depth� � � � � � � � � � � �10I 0 value
   >
   >� � � �D� �name� � � � � � � � � � � 1024A�   �varying const
   >
   >� � � �D� �path� � � � � � � � � � �24576A�   �varying const
   >
   >� � � �D� �value� � � � � � � � � � 65535A� �varying
   const
   >
   >� � � �D� �attrs� � � � � � � � � � � � �*�   �dim(32767)
   >
   >� � � �D� � � � � � � � � � � � � � � � � �   �const options(*varsize)
   >
   >
   >� � In case your element values exceeds 64k, you need to call
   >� � http_XmlReturnPtr(*ON) and use the following callback interface:
   >
   >
   >� � � �D valDS_t� � � � �ds� � � � � � � � �   template
   >
   >� � � �D� �p_newval� � � � � � � � � � � *�   �inz(*null)
   >
   >� � � �D� �len� � � � � � � � � � � � �10i 0 inz(0)
   >
   >
   >� � � �D EndOfElement� � PI
   >
   >� � � �D� �UserData� � � � � � � � � � � *� �value
   >
   >� � � �D� �depth� � � � � � � � � � � �10I 0 value
   >
   >� � � �D� �name� � � � � � � � � � � 1024A�   �varying const
   >
   >� � � �D� �path� � � � � � � � � � �24576A�   �varying const
   >
   >� � � �D� �valDS� � � � � � � � � � � � � �   �likeds(valDS_t) const
   >
   >� � � �D� �attrs� � � � � � � � � � � � �*�   �dim(32767)
   >
   >� � � �D� � � � � � � � � � � � � � � � � �   �const options(*varsize)
   >
   >
   >� � Then you pass the procedure pointer of that procedure to the
   >� � http_url_post_xml() procedure. The parser calls your "Callback"
   >� � procedure whenever it encounters a closing element tag. Inside
   your
   >� � callback procedure you can use http_nextXmlAttr() to spin
   through the
   >� � list of attributes like this:
   >
   >
   >� � � �D i� � � � � � � �S� � � � � � �10i 0
   >
   >� � � �D name� � � � � � S� � � � � �1024a� �varying
   >
   >� � � �D value� � � � � �S� � � � � 65535a� �varying
   >
   >
   >� � � �i = 1;
   >
   >� � � �DoW (http_nextXmlAttr(attrs: i: name: value);
   >
   >� � � � � // Do something with 'name' and 'value'.
   >
   >� � � � � // i is increment inside http_nextXmlAttr().
   >
   >� � � �EndDo;
   >
   >
   >� � Thomas.
   >
   >
   >� � -----Ursprüngliche Nachricht-----
   >� � Von: [5]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   >� � [mailto:[6]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von
   >� � Salaheddine Zaki
   >� � Gesendet: Donnerstag, 28. Januar 2016 13:51
   >� � An: [7]ftpapi@xxxxxxxxxxxxxxxxxxxxxx
   >� � Betreff: HTTPAPI, RPG and COBOL
   >
   >
   >� � Hi everybody;
   >
   >
   >
   >
   >
   >
   >� � Based on HTTPAPI library of Scott Klement, and using the example
   of
   >� � calling the Web service CurrencyConvertor (accessible from
   >� � [1][8]http://www.webservicex.net), I developed a COBOL program
   (Similar to
   >� � one provided in the example
   >� �   [2][9]http://scottklement.com/archives/ftpapi/200812/msg00014.html )
   that
   >� � consuming a Local Web Service, except at the level of XML PARSER
   I
   >� � can't get the value of the attribute of the tag. Let me explain:
   the
   >� � XML PARSER parameters are:
   >
   >
   >
   >
   >� � LSAA-DUMMY: Pointer
   >
   >
   >� � LSAA-XML-DEPTH: Pointer
   >
   >
   >� � LSAA-NAME: The name of the XML tag
   >
   >
   >� � LSAA-PATH: The path tag
   >
   >
   >� � LSAA-VALUE: The value of the tag
   >
   >
   >� � LSAA-ATTRS: A pointer that's supposed containing a pointer table
   of the
   >� � attributes and values of each tag (eg <tag1 attr1 = "xxx">
   "yyyy"
   > </
   >
   >� � tag1) -> This is where I have problem.
   >
   >
   >
   >
   >� � The XML PARSER is called after each callback of the RPG
   procedure. And
   >� � it's receives the expected parameters, except in case of a tag
   with
   >� � attribute (eg. attr1) the PARSER receives a null pointer (Eval
   pointer
   >� � gives "Identifier does not exist").
   >
   >
   >
   >
   >� � I think that the problem is at the passing/crossing of
   parameters
   >� � between programs.
   >
   >
   >
   >
   >� � Are Did anyone have already encountered this problem ?
   >
   >
   >
   >
   >� � For full clarification, here are the details of the problem :
   >
   >
   >� � 1-� � � The COBOL program "WSCALL" calls an RPG
   HTTP_URL_POST_XML
   >
   >� � procedure, by passing some parameters like: the URL of the WS,
   the
   >� � TIMEOUT, CONTENT-TYPE, ACTION ... etc (see code).
   >
   >
   >
   >� � CALL PROCEDURE
   >
   >� � � � "HTTP_URL_POST_XML" USING BY REFERENCE WSAA-URL
   >
   >� � � � � � � � � � � � �BY VALUE� � �   WSAA-SOAP-POINTER
   >
   >� � � � � � � � � � � � �BY VALUE� � � WSAA-SOAP-LEN
   >
   >� � � � � � � � � � � � �BY VALUE� � �   WSAA-STARTPROC-POINTER
   >
   >� � � � � � � � � � � � �BY VALUE� � �   WSAA-ENDPROC-POINTER
   >
   >� � � � � � � � � � � � �BY VALUE� � �   WSAA-OUTPUT-POINTER
   >
   >� � � � � � � � � � � � �BY VALUE� � � WSAA-TIMEOUT
   >
   >� � � � � � � � � � � � �BY REFERENCE� WSAA-USER-AGENT
   >
   >� � � � � � � � � � � � �BY REFERENCE� WSAA-CONTENT-TYPE
   >
   >� � � � � � � � � � � � �BY REFERENCE� WSAA-SOAP-ACTION
   >
   >� � � � � � � � � � � � �RETURNING� �   �WSAA-RETURN-CODE.
   >
   >
   >� � 2- 2- After running and receiving / reading the XML response,
   and when
   >� � closing a tag (</ tag>) EXPORT RPG procedure is called, it makes
   a
   >� � callback by completing a structure:
   >
   >
   >
   >� � Callback( root.userdata
   >
   >� � � � � � : rootDepth(root)
   >
   >� � � � � � : [10]element.name
   >
   >� � � � � � : elemPath(root: element)
   >
   >� � � � � � : p_retval
   >
   >� � � � � � : wwAttrAry
   >
   >� � � � � � );
   >
   >
   >
   >� � � � �The structure is defined as follows:
   >
   >
   >
   >� � endElement� � � B� � � � � � � � � �export
   >
   >� � endElement� � � PI
   >
   >� � � root� � � � � � � � � � � � � � �   likeds(elemroot)
   >
   >� � � name� � � � � � � � � � � � � *� �value
   >
   >
   >� � p_callback� � � s� � � � � � � �*� �procptr
   >
   >� � Callback� � � � PR� � � � � � � � �   extproc(p_callback)
   >
   >� � � userdata� � � � � � � � � � � *� �value
   >
   >� � � depth� � � � � � � � � � � �10I 0 value
   >
   >� � � name� � � � � � � � � � � 1024A� �varying const
   >
   >� � � path� � � � � � � � � � �24576A� �varying const
   >
   >� � � retval� � � � � � � � � � � � *� �value
   >
   >� � � Attrs� � � � � � � � � � � � �*� �   �dim(32767)
   >
   >� � � � � � � � � � � � � � � � � � � � � �   const options(*varsize)
   >
   >
   >
   >� � qqq
   >
   >
   >
   >
   >� � 3- Evaluating the wwAttrAry, the result is:
   >
   >
   >� � > EVAL wwAttrAry
   >
   >� � WWATTRARY (1) = SPP: E9AC54183F05AF70
   >
   >� � WWATTRARY (2) = SPP: E9AC54183F05AF90
   >
   >� � WWATTRARY (3) = SPP: * NULL
   >
   >� � WWATTRARY (4) = SPP: * NULL
   >
   >� � WWATTRARY (5) = SPP: * NULL
   >
   >� � .... etc.
   >
   >� � WWATTRARY (500) = SPP: * NULL
   >
   >
   >� � Here is the result of a first table case: EVAL on the table :
   >
   >� � wwAttrAry(1):C 100 ==> "v ® Z�y GREEN"
   >
   >� � the "v" is the name of the attribute, "GREEN" is its value.
   >
   >
   >
   >
   >� � 4- Continuing the execution, the PARSER is called, only the
   LSAA-NAME,
   >� � LSAA-PATH and LSAA VALUE parameters are set.
   >
   >
   >
   >
   >� � Question :
   >
   >
   >
   >� � 1 - How i can get the right parameters return in my COBOL
   program (Get
   >� � all parameters, not only LSAA-NAME, LSAA-PATH and LSAA VALUE).
   >
   >
   >� � 2 - How can i read the content of the table wwAttrAry case by
   case (get
   >� � the values not the pointers adresses)
   >
   >
   >
   >� � Thank you so much for your potential returns.
   >
   >
   >
   >� � Best regards.
   >
   >� � --
   >� � IMPORTANT NOTICE:
   >� � This email is confidential, may be legally privileged, and is
   for the
   >� � intended recipient only. Access, disclosure, copying,
   distribution, or
   >� � reliance on any of it by anyone else is prohibited and may be a
   >� � criminal offence. Please delete if obtained in error and email
   >� � confirmation to the sender.
   >
   > References
   >
   >� � 1. [11]http://www.webservicex.net/
   >� � 2.
   [12]http://scottklement.com/archives/ftpapi/200812/msg00014.html
   >
   >
   ----------------------------------------------------------------------

     > - This is the FTPAPI mailing list.� To unsubscribe, please go to:
     > [13]http://www.scottklement.com/mailman/listinfo/ftpapi
     >
     --------------------------------------------------------------------
     --
     > -
     >
     >
     --
     IMPORTANT NOTICE:
     This email is confidential, may be legally privileged, and is for
     the intended recipient only. Access, disclosure, copying,
     distribution, or reliance on any of it by anyone else is prohibited
     and may be a criminal offence. Please delete if obtained in error
     and email confirmation to the sender.

   -----------------------------------------------------------------------
   This is the FTPAPI mailing list.� To unsubscribe, please go to:
   [14]http://www.scottklement.com/mailman/listinfo/ftpapi
   -----------------------------------------------------------------------

References

   1. mailto:thomas.raddatz@xxxxxx
   2. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   3. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   4. mailto:thomas.raddatz@xxxxxx
   5. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   6. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   7. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
   8. http://www.webservicex.net/
   9. http://scottklement.com/archives/ftpapi/200812/msg00014.html
  10. http://element.name/
  11. http://www.webservicex.net/
  12. http://scottklement.com/archives/ftpapi/200812/msg00014.html
  13. http://www.scottklement.com/mailman/listinfo/ftpapi
  14. http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------