Re: RDi Compile and CMD Analyzer -- WDSCI-L

Gad,

I have tried several different ways of compiling from RDi and no matter
what I do, QDEVTOOLS/QRSEEXEC is the program that "runs" the CRTXXX
command. Disappointing.

Even compiling in batch, which submits a separate job, will not help you
because even in that case, IBM does NOT simply submit the command to the
job queue like they should have done, they had to submit a call to their
program which then runs the CRTxxx command. Kinda throws a wrench into
something that should be as simple as submitting a command to be executed.

So you're down to trying to write a layer between IBM and your
pre-compiler, or altering HOW the pre-compiler is run.

Stu

On Mon, Jan 25, 2016 at 1:15 PM, Stuart Rowe <rowestu@xxxxxxxxx> wrote:

Gad,

You said:
The Exit program is indeed called (judging by the relevent QZRCSRVS job's
joblog)
But it fails to replace the original CMD
(CRTBNDRPG/CRTRPGMOD) with the special CMD that fires the CPP to execute
the "pre-compiler" .

Are you saying that your exit program is intended to REPLACE the command
string being executed with another? You'll never be able to do that, since
(as Michael pointed out) the RDi server-side program runs in the *SYSTEM
state and IBM will not allow you to alter the command string in that case.
The exit program will run, but you will NEVER be able to replace the
command string on output. You should probably be executing your
pre-compiler from within the exit program, then letting the command "just
happen". Do you need to generate temporary source members and all that,
then create your objects, or is it just library list manipulations? It
matters. Library list manipulations you can do in-line, no biggee, but
switching source members on the fly wil require altering the command string
(which you cannot do).

Stu

On Mon, Jan 25, 2016 at 1:06 PM, Stuart Rowe <rowestu@xxxxxxxxx> wrote:

Gad,

You have some serious debugging to do. You will have to step through the
pre-compiler to see why it is NOT doing its job. It is being called, as
you verified, but something is keeping it from doing what it should be
doing. A poorly coded assumption based on JOB NAME perhaps? Remember, PDM
submits jobs with the name of your member on it, as in 113223/GAD/PGMNAME.
RDi, on the other hand, names the submitted job after the JOB DESCRIPTION
attached to your user profile, like 112233/GAD/GADJOBD. See the
difference? If you are basing your operation off the job name to get the
membe rname, oops, you need to not to that and parse the CRTxxx command
instead.

I'm not saying that's your problem, as I cannot see your code, but it
will be something "environmental" like that I'm sure. Probably will turn
out to be easy, once you sit and watch it run!

Stu

On Mon, Jan 25, 2016 at 1:03 PM, Stuart Rowe <rowestu@xxxxxxxxx> wrote:

Michael Quigley,

Yes, the exit program ARE called when the calling program runs in the
*SYSTEM state. They are always CALLED, you just cannot change the command
on output if the caller runs in *SYSTEM state.

Stu

On Mon, Jan 25, 2016 at 12:41 PM, Gad Miron <gadmiron@xxxxxxxxx> wrote:

Hi Michael

Thanks,
it's getting a little late in the evening so I (hopefully) will try your
CMD tomorrow.
Just a quick one though,
The CMD Analyzer Exit PGM is indeed called so the API does seem to work.

Gad

On Mon, Jan 25, 2016 at 8:28 PM, <MichaelQuigley@xxxxxxxxxx> wrote:

Indeed RDi does simply invoke the CRTBNDRPG/CRTRPGMOD/etc. commands.

But

unfortunately it does this within the QRSEEXEC program which runs in
*SYSTEM state. The command analyzer APIs are not called in that case.

I know this would require modifying each developers installation

(sounds

like a case for 'Push to client'), but you can try it as an

experiment.

Here's a simple command RDIEXEC and CL RDIEXECP to try it:

CMD PROMPT('RDI Execute Command') TEXT('RDi

Execute +

Command')

PARM KWD(CMD) TYPE(*CHAR) LEN(5000) MIN(1)

VARY(*YES +

*INT4) CHOICE('Command string')

INLPMTLEN(512) +

PROMPT('Command to execute')

Create the command with:

CRTCMD RDIEXEC PGM(RDIEXECP) SRCFILE(yoursourcefile)

PGM PARM(&CMDPARM)

DCL VAR(&CMDPARM) TYPE(*CHAR) LEN(5000)
DCL VAR(&CMDLEN) TYPE(*INT) LEN(4) +
STG(*DEFINED) DEFVAR(&CMDPARM 1)
DCL VAR(&CMD) TYPE(*CHAR) LEN(4996) +
STG(*DEFINED) DEFVAR(&CMDPARM 5)

DCL VAR(&QCMDEXCLEN) TYPE(*DEC) LEN(15 5)
DCL VAR(&QCMDEXCCMD) TYPE(*CHAR) LEN(4996)

DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(512)
DCL VAR(&MSGID) TYPE(*CHAR) LEN(7)
DCL VAR(&MSGF) TYPE(*CHAR) LEN(10)
DCL VAR(&MSGFLIB) TYPE(*CHAR) LEN(10)

CHGVAR VAR(&QCMDEXCLEN) VALUE(&CMDLEN)
CHGVAR VAR(&QCMDEXCCMD) VALUE(%SST(&CMD 1 &CMDLEN))

CALL PGM(QCMDEXC) PARM(&QCMDEXCCMD &QCMDEXCLEN)
MONMSG MSGID(CPF0000)

RCVMSG MSGTYPE(*LAST) MSGDTA(&MSGDTA) MSGID(&MSGID) +
MSGF(&MSGF) SNDMSGFLIB(&MSGFLIB)
SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF)

MSGDTA(&MSGDTA)

RETURN
ENDPGM

Create the program with:

CRTBNDCL RDIEXECP SRCFILE(yoursourcefile)

In RDi, open whatever you want to compile, click on 'Compile', then
'Compile' from the sub-menu, then 'Work With Compile Commands...'

Give the command a label like 'Execute Command', the command should

then

be (for a bound RPGLE program) 'RDIEXEC CMD(? CRTBNDRPG &O/&N
SRCFILE(&L/&F) OPTION(*EVENTF)) /* DBGVIEW(*SOURCE) */

Specifying OPTION(*EVENTF) will allow the compiler to populate the
necessary information for the RDi Error List. I've appended a comment

of

DBGVIEW(*SOURCE) which I believe is also required for RDi to properly
process the compile. I've prefixed the basic command with a question

mark

which will cause the actual compile command to always be prompted.

You may

not want that in a production set up, but this should quickly tell you
whether your CMD analyzer exit program is being called.

The whole process could be developed a lot further, but this at least
tests the concept. (RDIEXECP should run under *USER state and

therefore

the CMD analyzer should be called.) I would test it here, but I don't

have

the authority to register the required exit points. If the concept

works,

I could probably get our administrator to buy into it and handle the
registration for me.

I hope this helps,
Michael Quigley
Computer Services
The Way International
www.TheWay.org

"WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx> wrote on 01/23/2016

01:00:02 PM:

----- Message from Gad Miron <gadmiron@xxxxxxxxx> on Sat, 23 Jan
2016 16:38:36 +0200 -----

To:

"Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries" <wdsci-l@xxxxxxxxxxxx>

Subject:

Re: [WDSCI-L] RDi Compile and CMD Analyzer

Thanks you all guys

I followed your advice regarding the Compile on-line,
RDi now compile on-line all right but the issue with the CMD

Amalyser

Pre

compiler
is not solved.

Way back when I devised the CMD Analyzer method I just could not

fathom

all

the parameters involved in CRTBNDRPG or CRTRPGMOD (and I wanted the
programmers to use the CMDs they are familiar wthh) so I looked

around

for

another way and with the help of Bruce Vining managed to use the CMD
Analyzer.

I thought (wrongly I guess) that RDi simply invokes the

CRTBNDRPG/CRTRPGMOD

so naturally I expected this thing to work.
Well, back to the drawing board.

Thanks again
Gad

--
This is the Rational Developer for IBM i / Websphere Development

Studio

Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.

--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.