Variable Modules

["PAPWORTH Paul" <Paul.Papworth@xxxxxxx>]

We are getting more and more into ILE RPG programming , and I recently came across the following problem. Is it possible to have a variable that contains the *module to be called  ? , like we did for years with dynamic  program calls. I have seen some suggestions which use the PROCPTR feature but this has been less than clear.

Thanks in anticipation
-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de rpg400-l-request@xxxxxxxxxxxx
Envoyé : vendredi 20 mai 2005 19:01
À : rpg400-l@xxxxxxxxxxxx
Objet : RPG400-L Digest, Vol 4, Issue 555

Send RPG400-L mailing list submissions to
	rpg400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
	rpg400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
	rpg400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RPG400-L digest..."


Today's Topics:

   1. RE: work files in qtemp (Larry Ducie)
   2. RE: File object got deleted!
      (Chaudhary, Sachin (GE Equipment Services,	Consultant))


----------------------------------------------------------------------

message: 1
date: Fri, 20 May 2005 17:33:32 +0100
from: "Larry Ducie" <larry_ducie@xxxxxxxxxxx>
subject: RE: work files in qtemp

Hi Ken,

<snip>
If Larry and I worked at the same company, and he used his utility to take 
over one of my jobs and had it delete an object, then *I* deleted the 
object. If object auditing is turned on and you looked the audit record for 
the deletion, it would show deleted by me. There would be no clue that Larry 
was the one who instigated it, except the program name might show the name 
of his exit program, but even then there would be no way to know from that 
audit record who it was that actually used the utility.
</snip>

...and the deletion of the object caused the application to crash, and the 
company lost $millions? Would you still insist that "you" deleted the 
object? :-)

I agree with you about the way it works, I wont argue that point - on a 
system level it's the user running the job that performs the action. Or 
rather, the action is performed under the user profile that runs the job. 
I've never argued otherwise. The problem here, as you pointed out, is that 
the audit trail is broken - that's the big security concern for me. You'd 
have to prove it "wasn't" you that deleted the object when all evidence 
indicates that you did.

Having said all that, it's been a really useful tool for me over the years 
(whichever way it works). It can still bel useful, even if it's only used as 
a development tool - to help debugging batch jobs.

This is quite a good topic. Makes you think.

Have a good weekend.

Cheers

Larry Ducie




------------------------------

message: 2
date: Fri, 20 May 2005 12:45:40 -0400
from: "Chaudhary, Sachin \(GE Equipment Services,	Consultant\)"
	<sachin.chaudhary@xxxxxx>
subject: RE: File object got deleted!

I got it. Thanks a lot.

-----Original Message-----
From: rpg400-l-bounces+sachin.chaudhary=ge.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+sachin.chaudhary=ge.com@xxxxxxxxxxxx]On Behalf
Of Scott Klement
Sent: Friday, May 20, 2005 3:18 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: File object got deleted!



> 1. Thinking that creating a new file from DDS will lead to recompiling 
> all programs to avoid level check error
[SNIP]
> Creating a duplicate object, to production didn't change the 
> Identifier??
[SNIP]
> Can you explain me?

What does a record format level check do, and why do we need it?

First, understand the problem that it's designed to solve:

When you compile an RPG program that uses an external definition, what it 
does is look at the fields in the file and generate I-specs (yes, the old 
fashioned input specs) in your program for you.

Since these are now compiled into your program, if you change anything in 
the record format, it would read from the wrong positions.

For example, consider the following file:

      A          R TESTFMT
      A            FIELD1        10A
      A            FIELD2        10A

When you compile an RPG program that uses this file, and use an external 
definition, the system will AUTOMATICALLY create the following input 
specs...

       ITESTFMT   NS
       I                                  1   10  field1
       I                                 11   20  field2

If you go back and change the file so tha FIELD1 is 15A instead of 10, 
you now have the following:

      A          R TESTFMT
      A            FIELD1        15A
      A            FIELD2        10A

Now FIELD1 is taking up positions 1-15 and field2 is 16-25. However, 
unless you re-compile your RPG program, it won't know that!  Instead, 
it'll continue to try to read field1 from positions 1-10, and FIELD2 from 
11-20.  That means that FIELD2 in the RPG program will actually read data 
out of FIELD1!

So, IBM insituted record format level identifiers.  The system computes a 
"checksum" or "hash" of the things that are important to the format of a 
record.  These things are the field's name, length, data type, and 
position in the record.

So, in the above example, the record format level identifier would have 
changed, since the size of FIELD1 has changed, and also because the 
position of FIELD2 has changed.

When you compile your RPG program, it reads the external definition and 
generates the input specs as I explained above.  It saves the record 
format level from the file into the RPG program's compiled object.  Every 
time it tries to open that file, it compares the one it saved with the one 
in the file. If they don't match, it knows it's input specs are wrong, and 
aborts the program.  This way, a programmer won't forget to recompile his 
program to generate the correct input specs.

Now that you understand that, why didn't CRTDUPOBJ or re-building the PF 
from source cause the record format level id to be different?  Quite 
simply because the record format was the same. Since it was the same, the 
system generates the same checksum.  The input specs that it would 
generate are identical, so there's no reason for the level id to be 
different.

Make sense?

> 2. How can we know from which AS400 id was this object deleted?. History 
> log (DSPLOG QHST) is no good.

The history log isn't intended for that sort of thing.  If you want the 
system to log who deleted files, you need to turn on object auditing. 
Unfortunately, if the file is already gone, it's too late. You need to 
turn it on ahead of time so that these sort of events are logged.

Do a search for CHGOBJAUD and CHGUSRAUD and you should find more info on 
object auditing.

good luck