RE: QCMDEXE behavior modification

Vern,

Ascertaining the C-spec created variables:

What I really wanted (originally) was to use the compile list to indicate which file variables are actually referenced in the program. My thought was to use the cross reference in the compile listing. A secondary bonus (based on my lack of foresight) also gave me the C-spec generated variables so that I could add them to the XREF file that I use during the translation. The translation also contains the field sizes and thus I use that information to convert move and adds to 'eval'-less statements ONLY if the size and type match. Else, I leave them alone and make it up to the programmer to modify that move or add spec.

I started this project over a year ago and it has morphed several times with fixes here and there. I probably know enough now not to have to rely on the compile print to get what I need, but since this seems to work (mostly), I don't want to change that part.

If you want to learn even more about it, I'm willing to talk more about it. As you can tell, I like to say things. A lot.

Duane

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Vernon Hamberg
Sent: Thursday, April 23, 2020 12:53 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: QCMDEXE behavior modification

Hi Duane

Some things get submitted - and compiles can be one of those things.
It's a guess on my part, however. I mean, PDM options should not have an effect on the actual CRT commands.

Now RDI does have a setting in what, the Commands subsystem, to run things in batch, hence, a different job.

I wonder about the assumption - QCMDEXE does keep things at the same call level, IIRC, but it doesn't start a different job.

Do you know the job number? Can you DSPJOB using that number?

I'm also curious about doing the compile - C-spec created variables can be ascertained just by scanning the source, right? I've not had reason to look, so I ask, what does the compile give you that is more informative? That would be cool stuff to learn about!

Regards
Vern

On 4/23/2020 10:35 AM, Duane Scott wrote:

I've made an assumption here based on observations, and I may be incorrect (and most likely am), but I have no other explanation. Hopefully, in as kind of a manner as is usually displayed in this group, I can be corrected and put on the right path.

I've created an SQL based RPGLE program that I use to convert RPG IV to RPG Free. In it, I utilize the SYSTEM() function to compile the original source, copy the spooled file to a source file member, and search for various information like c-spec created variables. The problem is that when running the program using the RDI "user action", the compile spool file job number is not the same as the job number of the job that issued the "user action".

I don't know why, but it uses a job associated with my user id, but not one of the current active jobs. Not sure what job that is and why it uses it. Nor do I know how to discover what the spool file job number is.

I believe that this is also an issue with other development environments other that RDI, so I don't think it's an "RDI" problem, but one associated with SYSTEM() and similar. I haven't tried QCMDEXE to see if that is different. Maybe I should?

Any known answers?


Duane

CONFIDENTIALITY NOTICE: This electronic message transmission is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. If you have received this transmission, but are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please contact NALC Health Benefit Plan at 703-729-4677 and delete and destroy the original message and all copies.