Re: Incorrect module name and library

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Œ
Hello Mark,

You wrote:
>1)   I created a program (PGM) and bound module MOD into it. I then made a 
>copy of the MOD source and called it MOD_TEST.  I made some changes (not to 
>the interface), created module MOD_TEST, renamed module MOD_TEST to MOD, 
>updated PGM via UPDPGM PGM MOD.

>  Within the program I have an SDS that specifies a *PROC variable.  The 
>value printed is MOD_TEST, not MOD, which is the current name.  This tells 
>me that this value is populated at compile time, not runtime.  Is this the 
>way OPM programs worked?  I seem to recall that it was at runtime.  This 
>behavior was a surprise to me.  I would think that most people would want 
>the current name of the module, not the original name.

You must be using 'old-style' procedures where one module contains one 
procedure which does not use P-specs thus the procedure name is the same as 
the module name.  Think about the following code stored in a source member 
called TEST:

H NOMAIN                                                     
                                                             
D proc2           PR             5I 0                        
D   parm1                       10    CONST OPTIONS(*NOPASS) 
                                                             
P proc2           B                   EXPORT                 
D proc2           PI             5I 0                        
D   parm1                       10    CONST OPTIONS(*NOPASS) 
C                   RETURN    2                              
P proc2           E                                          

Creating a module from this code using the defaults results in a module 
called TEST containing a procedure called PROC2.  What value should *PROC 
contain?  TEST or PROC2?  The correct answer is PROC2.  If I rename the 
module to JUNK the value of *PROC should still be PROC2.  The same rationale 
applies to your code.  You never assigned a procedure name so the compiler 
did based on the module name at the time of compilation.  Just because you 
change the module name after compilation doesn't mean the procedure name 
should change. Ergo, no bug.

>2)  Using a similar scenario as above, where the module was updated via 
>UPDPGM, I ran DSPPGM PGM DETAIL( *MODULE ) and put a 5 next to the module to 
>display the details.  The library displayed is that of the ORIGINAL module, 
>not the current module!  All other information seems to have gotten updated, 
>including the source file / library and member.  This would definitely seem 
>to be a bug to me.

I agree this is a bug but I don't think Toronto are to blame.  The compilers 
come from Toronto but I think the ILE stuff (CRTPGM, UPDPGM, CRTSRVPGM, 
UPDSRVPGM) comes from Rochester.

I tested this on VRM440.  I created three modules in my library (SHC) called 
TEST_UPD1, TEST_UPD2, and TEST_UPD3.  I bound them into a program called 
TEST_UPD.  Then I duplicated TEST_UPD2 into QGPL and issued an UPDPGM 
specifying MODULE(QGPL/TEST_UPD2) all was successful but the library name of 
all modules in DSPPGM DETAIL(*MODULE) remained SHC.  I would expect TEST_UPD2 
to show QGPL.  I then compiled TEST_UPD2 into QGPL and updated the program.  
DSPPGM DETAIL(*MODULE) still showed the library as SHC but the creation date 
and time matched those of the QGPL compilation.  Oops!  Open a PMR with IBM 
support.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---