RTVWSCST to get source for *WSCST QWPDEFAULT in QSYS

[CRPence]

What RTVWSCST invocation(s) will retrieve the source for the *WSCST
[WorkStation Customizing\Customization object] named QWPDEFAULT in QSYS?

Someone implied that IBM [support\service] told them how to effect
the "Subject:", but I have received no response to my request for the
details they were given. So IOW, please do not refer me to that other
open\unanswered discussion :-) unless inferred from testing the poorly
scripted processing yields the answer; I have no access to test those
steps. A message in that other discussion [including the steps of
processing]:
http://archive.midrange.com/midrange-l/201202/msg00547.html

Regards, Chuck

[Christian Bartels]

If I understand it right, QWPDEFAULT is a very basic *WSCST that does not do
much control character conversion other than line feed and form feed. Given
that, I could imagine that RTVWSCST DEVTYPE(*TRANSFORM)
MFRTYPMDL(*WSCSTNONE) results in a source that does pretty much the same as
QWPDEFAULT.

As far as I can see from the output of other manufacturer types and models,
the character conversion EBCDIC to ASCII is not part of the *WSCST object.

Kind regards,
Christian.

"CRPence" <CRP...@vnet.ibm.com> wrote in message
news:ji7ch8$s3b$1...@speranza.aioe.org...

[CRPence]

That is the same presumption I had made in my response in
http://archive.midrange.com/midrange-l/201202/msg00547.html
though I can not confirm; having only v5r3 and no special authorities.

While not obvious from the "Subject:" nor my inquiry, knowing what
defines QWPDEFAULT in this exercise is moot. Only knowing what RTVWSCST
request(s) effects the retrieval of its source is relevant.

So is there any chance you could confirm for me, that the source from
any user-customized *WSCST could be retrieved using the /script/ in the
referenced message; and that *WCSTNONE transform retrieve request? That
is really what I want to confirm... that the RTVWSCST is really coded as
a generic *WSCST source-retrieval function, yet fails to directly expose
the capability to retrieve a /named/ *WSCST object. That is, this is
followup to my final question in:
http://archive.midrange.com/midrange-l/201201/msg00927.html

Regards, Chuck

[Christian Bartels]

This is what I've tried:

In the first step, I've created my own *WSCST object by retrieving the
source of DEVTYPE(*TRANSFORM) MFRTYPMDL(*HP4) and creating my own *WSCST
object from it (let's call it MYLIB/HP4#ORG).

Then I've exectuted the following commands:
RNMOBJ OBJ(QSYS/QWPDEFAULT) OBJTYPE(*WSCST) NEWOBJ(WPDEFAULT)
CRTDUPOBJ OBJ(HP4#ORG) FROMLIB(MYLIB) OBJTYPE(*WSCST) TOLIB(QSYS)
NEWOBJ(QWPDEFAULT)
RTVWSCST DEVTYPE(*TRANSFORM) MFRTYPMDL(*WSCSTNONE) SRCMBR(HP4#NONE)
RTVWSCST DEVTYPE(*TRANSFORM) MFRTYPMDL(*WSCSTCONT132) SRCMBR(HP4#C132)

To clean up afterwards, I've executed:
DLTWSCST (QSYS/QWPDEFAULT)
RNMOBJ OBJ(QSYS/WPDEFAULT) OBJTYPE(*WSCST) NEWOBJ(QWPDEFAULT)

Now I compared my output with the original source using the CMPPFM command;
it turned out that all the sources (HP4#ORG, HP4#NONE and HP4#C132) were
identical.

So the conclusion is: Yes, this method is working, and it does not seem to
matter whether you specify MFRTYPMDL(*WSCSTNONE) or
MFRTYPMDL(*WSCSTCONT132).

Kind regards,
Christian Bartels.

"CRPence" <CRP...@vnet.ibm.com> wrote in message

news:ji8c04$eun$1...@speranza.aioe.org...

[CRPence]

On 27-Feb-2012 04:08 , Christian Bartels wrote:
> <<SNIP>>

> So the conclusion is: Yes, this method is working, and it does
> not seem to matter whether you specify MFRTYPMDL(*WSCSTNONE) or
> MFRTYPMDL(*WSCSTCONT132).
>

Thanks. I see I forgot to suggest to avoid the delete to keep the
original object; i.e. modify the /script/ to /do the right thing/ rather
than DLTWSCST. Oops. But I see that was done, having used the RNMOBJ
instead :-) I suppose, subconsciously, I was just figuring that you
knew best :-) Thanks again.

With that knowledge, I can create a command and a command processing
program that does what RTVWSCST should already be capable of doing; i.e.
retrieving any named WSCST object. And as a command\CPP that does the
work /safely/ [as is reasonable, given the object will temporarily both
become unavailable and go missing,] instead of using the poorly scripted
steps as alluded by the other message thread.

Regards, Chuck