Thanks for the response Nadir,

We have been able to make it work - but I can now see (I think) where the confusion lies. You say in this article that a length association box normally appears. That is not what happens in my case unless I deselect the Detect Length box. And by default that box is checked.

Later on is this article it becomes clear where the discrepancy may lie. There you are talking about a single parm containing both the DS _and_ the length field and apparently if such a structure is used _then_ selecting the box will cause the length field to be detected. I don't have time right now to check this out but I think that is the difference.

This latest change (i.e. the one described in the "updates" document you referenced does not appear to be fully reflected in the main manual or in the tutorial.

I'll have time to tomorrow to check it out further and will see if I can get a handle on the differences.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 21, 2019, at 5:36 PM, Nadir Amra <amra@xxxxxxxxxx> wrote:

I guess no one is understanding me regarding detect field lengths support in iws. Please read the section entitled "Support nested output arrays" in the following article:

https://www.ibm.com/developerworks/ibmi/library/i-integrated-web-services-server/index.html <https://www.ibm.com/developerworks/ibmi/library/i-integrated-web-services-server/index.html>




Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote on 07/18/2019 01:48:22 AM:

From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
To: "Web Enabling the IBM i (AS/400 and iSeries)" <web400@xxxxxxxxxxxxxxxxxx>
Cc: amra@xxxxxxxxxx
Date: 07/18/2019 01:48 AM
Subject: [EXTERNAL] Re: [WEB400] Weird IWS Bug (?)

Booth - I don't know how many more times I have to say this - I KNOW
THIS. I mentioned in the video that I had done it but that it
wasn't worth going back and correcting.

I have a working version and in that (and every version I have
produced other than the one in the video) it was correctly specified
as input - is received correctly by the program and produces the right output.

It is possible that adding const to the definition might cause the
wizard to _default_ to input - but you have always been able to
manually change the setting in the wizard - which is what I do
because in my case having the parm defined as const is not acceptable.

It is "purring" BUT the fact remains that there are two issues with
the tool/documents that remain unexplained.

1) The does say that you must _select_ detect field lengths in order
to control the output length. This is WRONG - the opposite is true.

2) The docs say that the length will not be included in the output -
this is also not true - it is included.

As requested by Nadir I have now applied the latest PTFs and it does
not change anything (apart from adding the interesting "Deploy SQL
as web service" option) the results are as stated above.


Jon Paris

www.partner400.com <x-msg://585/www.partner400.com>
www.SystemiDeveloper.com <x-msg://585/www.SystemiDeveloper.com>

On Jul 17, 2019, at 4:58 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

When using the IWS wizard, in the URL path template(Step 3 of 9)
you list an input parm of /cat/{cat}. Yet in Step 4 of 9 all of the
fields are defined as output. My bet (up to 42 cents!) is that your
troubles lay somewhere within that incongruity. Pure guess, but
my guess is that "cat" and "requestedcat" are the same field? If
so, changing {cat} to {requstedcat} and adding *const option to
requestedcat in RESTSVR4x should make it purr.

My understanding is that the way the wizard knows if a parm is
input or output is from the *const option? or something.



On 7/17/2019 2:31 PM, Jon Paris wrote:
As to *Const - I have no idea why you had problems with it - it
should have zero bearing on IWS - it is just used by the compiler -
it may affect the PCML (not sure about that) but the only thing that
would do is make the wizard only show you Input as an option instead
of Input and Output.


Jon Paris

www.partner400.com <x-msg://585/www.partner400.com>
www.SystemiDeveloper.com <x-msg://585/www.SystemiDeveloper.com>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://urldefense.proofpoint.com/v2/url? <https://urldefense.proofpoint.com/v2/url?>
u=https-3A__lists.midrange.com_mailman_listinfo_web400&d=DwIFAg&c=jf_iaSHvJObTbx-
siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=g49rN3Sgx5wDcfEaku4tkkXeb_mF6EETuPtPudTANEQ&s=F8UKASjpVi6T0a0jy8pYcSxq48YcwGW5BmRgZ_QwjN4&e=
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://urldefense.proofpoint.com/v2/url? <https://urldefense.proofpoint.com/v2/url?>
u=https-3A__archive.midrange.com_web400&d=DwIFAg&c=jf_iaSHvJObTbx-
siA1ZOg&r=1i-jGlz0-JTK1aLHcsU-
ew&m=g49rN3Sgx5wDcfEaku4tkkXeb_mF6EETuPtPudTANEQ&s=vHO9OY5sLD3dbon0iOpOfjjqJH2c_hfp_mgSFPcpA6o&e=
.






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.