ZMF HLLX - the availability of the 3DSKEL variables

Hello
I was wondering if it would be possible to have the 3DSKEL variables available in the HLLX exits
I have written a peace of code that when needed I retrieve the one(s) I need at that moment, but it would be nice that they would be available

The exit will work very often on a function for a package, component belonging to an application. It would be nice that at that moment the 3DSKEL variables for that application would be available in the HLLX 

Thank you
Best regards
Johan

Hi Johan,

To supply the 3-D skel variables to every exit would be a massive undertaking, and it would cost each client to do this in every place that an exit might be called (although we'd probably only do it once per HLLX 'conversation'). And, mostly, this effort would not be used.

As you point out, you can get these variables using a service call from any exit – that's the way it should be done, in general.

However, I understand the need to speed the process up for a frequently invoked exit.

If you tell us which exit you are particularly interested in then we could look at supplying 3-D skel variables for that specific exit (or, maybe for each exit in the same conversation - this would have to be researched to ensure this is viable).

All the best - Steve

Hi Steve,

My apologies for the late reply, but we are in the middle of the final steps of launching a big redesign within the Changeman architecture

I don't fully understand the massive undertaking part. Most of the exits work against a package from which the application can be deducted and then only the 3DSKEL variables for the application would be provided. Once loaded they could remain in memory a bit like the package sys lib is done for a package
Or I'm I misunderstanding the bigger picture here?
Best regards
Johan

Hi Johan,

Unless I have misunderstood, you are asking for a change to every HLLX functional area data interface to include new fields for the 3-D skels.

And every client program would have to be changed to populate these new data fields, just in case (although as I say, this would only be done once at the start of each conversation).

The package syslib 'cache' is actually in the package master - once the expensive process of gathering the package syslib data has been performed we write the results to the pmast from where it can be gathered much more quickly on the next call.

That paradigm does nothing for 3-D skel data (which is already in its final form in the pmast).

Having recently done something like this for the simple expansion of the 'long message' field to 512 bytes I can affirm that that changing the data structure for all HLLX functional areas will be a massive undertaking. Do you need this information everywhere ?

Perhaps you could write this information to the vpool file for use by all subsequent exits.

All the best - Steve

Hi Steve,

Thank you for the swift, reply.

Now I got it, indeed, this would be a massive undertaking. 

The VPOOL isn't a solution either as I have the same issue, at every entry point of the exit I must retrieve them and store them.
I'm going to keep my implementation as is and just use the building block I created to retrieve the one I need

Beside this, now that understand that it is an undertaking process, what is your feeling to have specific package variables available at all locations

eg: workChangeRequest, requestorDept, requestorPhone), packageStatus

:-)

Best regards

Johan