Thanks, Steve.

Yes, with the shortened—and different—names, the problem is solved.

I appreciate your time with all this.  Have a great day!

-- Ron Palaniuk

Hi Ron,

Yes, I take your point.

In fact, it didn't take me long to get bored with using the really long names so I shortened them a bit, so the problem should not occur with the names I am using at the moment:

apprList.entity.n

apprList.description.n

apprList.apprCode.n

apprList.apprUid.n

apprList.apprDate.n

apprList.apprTime.n

apprList.orderNum.n

apprList.lastFunc.n

These may change before I'm done but I will publish the final names in the relevant documentation.

Cheers

Hi Steve,

That sounds good about the "verbose" variable names: it will be very clear about what is being described.

The only concern I have with using the same single entry field/variable name as a variable and as an element name in a stem array / compound variable name is that you can get some unpredictable results when accessing the contents of the compound variable.

Being that it sounds like APRV0003 will have the single instance variable/field of "approvalEntity" set to blank, and being that it was implied that a single instance field of  "approvalEntity" in APRV0103 would be set to a value the way it is currently today (so as to not impact existing code in use at various sites), I've put together a simple REXX that hopefully shows my concerns:

/* REXX */                                    
                                              
    drop approvalEntity                       
    drop approverList.                        
                                              
    say approvalEntity                        
    say approverList.                         
                                              
    approverList.approvalEntity.1 = "SECENTTY"
    say approverList.approvalEntity.1         
                                              
    approvalEntity = ""                       
    say approverList.approvalEntity.1         
                                              
    approvalEntity = "ENTITY"                 
    say approverList.approvalEntity.1         
                                              
    approvalEntity = "approvalEntity"         
    say approverList.approvalEntity.1         
                                              
    approvalEntity = "APPROVALENTITY"         
    say approverList.approvalEntity.1         

with output as follows:

APPROVALENTITY               
APPROVERLIST.                
SECENTTY                     
APPROVERLIST..1              
APPROVERLIST.ENTITY.1        
APPROVERLIST.approvalEntity.1
SECENTTY                     

Hi Ron,

thanks again for your thoughts on this, I have enough information to proceed.

I need to ensure that the existing fields remain in use exactly as they are now (so this change doesn't impact anybody else who doesn't need all this new info) - I will not change anything about the  way they are populated. The single instance approval fields will be blank when passed to APRV0003.

The new structure/stem variable approval fields will have a compound stem name consisting of a new identifier followed by their usual name.

e.g.   approverList.approvalEntity.n

etc.

I know that looks a bit 'long winded' for a variable name but it makes things abundantly clear.

We have other functions that use this pattern for REXX variable stem names, e.g. in the PCRT function we pass the site table information in variables that look like:

siteInfo.siteName.n

siteInfo.InstallDate.n

etc.

All the best - Steve

Thanks, Steve, for your response.

Sure, if there is little concern about performance considerations, then that would be great to supply the full list of package approval items during APRV0003 and APRV0103.  This way, the HLLX program can determine the next logical outstanding package approver’s (or approvers’) sequence number (assuming that the hierarchical approval process has been turned on), and determine how many outstanding approvals are left—all without doing an XML services call.

One question that does come to mind during APRV0103:  If the full approval list is supplied via the function data interface during APRV0103, then how will one be able to determine what specific package approval item was actioned upon within CMNAPPLS?  Would looping through the full list of package approval items and checking for a non-blank value in "lastFunction.n" be sufficient to determine which package approval item was actioned upon within CMNAPPLS?

With regard to generating the full approver list information for other approval exit points, I don’t really think that it’s necessary either.  (Worst case scenario, the HLLX developer could opt to perform an XML services call to get additional approval information.)  For these other exit points, I’m assuming that the current REXX variables will continue to be used in the function data interface:

• approvalEntity
• approvalDescription
• approvalCode
• approvalUser
• approvalDate
• approvalTime
• orderNumber
• lastFunction

compared to the new function data interface for APRV0003 and APRV0103 that would be something like the following as a REXX compound/stem variable:

• approvalEntity.n
• approvalDescription.n
• approvalCode.n
• approvalUser.n
• approvalDate.n
• approvalTime.n
• orderNumber.n
• lastFunction.n

If the above structures will be used, then specifically with REXX if (for example) the “approvalEntity” is used as a REXX simple variable in (say) APRV0006/APRV0106, and later “approvalEntity” is used as part of a prefix of the stem variable in APRV0003/APRV0103, then we need to make sure that the value contained within the “approvalEntity” REXX simple variable is cleared/dropped.  Otherwise, the value of “approvalEntity” would become the prefix of the stem variable for “approvalEntity.n” in APRV0003/APRV0103.  (For example, if “approvalEntity” is set to “ENTITY” in APRV0006/APRV0106, and if “approvalEntity” doesn’t get dropped before APRV0003/APRV0103 is driven, then the “approvalEntity.n” reference would really be “ENTITY.n”.)

With regard to setting-up a new field in the function data interface for APRV0003, where the HLLX exit could decide whether (or not) to call the HLLX exit again when redisplaying CMNAPPLS, I think that would be a great feature to add.

I also don’t see a need to drive APRV0003 if the CMNAPPLS panel is about to be displayed in “browse only” mode; I can’t think of any use cases.  If it’s in “browse only” mode, then it is only displaying information and there are no actionable items.  I suppose that if a use case does come up, then another enhancement request can be submitted.

-- Ron Palaniuk