CA 2E r8.6: Enhanced Array Support

[Simon_Cockayne]

Hi,

I recevied a question this morning, regarding the interplay between Enhanced Array Support and CRTOBJ and RTVOBJ function types.

I thought I would reproduce and share a snippet from the building Applications guide: Appendix B: How to Create a Deployable Web Service Using a Multiple-instance Array:

"Important! As a CA 2E developer, you need to understand the architectural distinction between the two mechanisms to manipulate array data, despite the ability to use a common structural definition:
■ Data can exist and be modified in an array by using database functions (Create Object – CRTOBJ, Delete Object –DLTOBJ, Change Object – CHGOBJ, and Retrieve Object – RTVOBJ) based over the *Arrays file. However, this array data cannot be accessed by the *MOVE ARRAY function.
■ Data can also exist and be modified in a multiple-instance array parameter (in the PAR context) and in the ARR context by using the *MOVE ARRAY function. However, that array data cannot be accessed by database functions (Create Object – CRTOBJ, Delete Object –DLTOBJ, Change Object – CHGOBJ, and Retrieve Object – RTVOBJ) based over the *Arrays file."

You can find the full appendix with the r8.6 documentation, available on line here:
https://support.ca.com/cadocs/1/CA%202E%20Release%208%206%2000-ENU/Bookshelf.html

Cheers,

Simon

Simon Cockayne
CA Technologies
Principal Software Engineer
CA Subject Matter Expert
Tel: [phone]
[e-mail]

[Anon Anon]

I'll confess that I'm the one who asked Simon the question.

My question bolied down to:
If I use a crtobj built over an array to load records into an array and define that same array as an output parametere using the new functionality - will the array I have populated be passed to the calling function?

Simon's answer boiled down to - No.

In my opinion this is a shame as this would seem a much better way to implement arrays as parameters.

Under version 8.5 we have developed a number of web services where we have needed to return a list of data entries. We have done this by loading a standard 2E array (typically using a rtvobj over a database table) and adding a single line of source to the generated code that adds ym01 (the RPG variable for the multiple occurence data structure that holds the array) to the external parameter list. This has worked fine.

I can improve things slightly under version 8.6. I can add the arrays as an output parameter. To get the data moved to the output parameter I just need to add a line of user source that moves the variable containing the internal array to the variable containing the external array. I'll have wait and see what the generated code looks like to know whether the user source can be generic or will have to be different for each program.


In my opinion the amount of coding needed to use the move array command (even with the all option) is to great to change our programs to use it. If the array could be passed in or out of the rtvobj over the database table then we could replace the crtobj of the array with a *move array to achieve much the same thing.

It seems a shame to have changed from viewing an array as a special kind of file with limited scope to viewing an array as a special kind of variable.

cheers
Harry

[Deactivated User]

Hi Harry,

I think you are overlooking what is happening here. The array support added in 8.6 is hopefully the starting point for future functionality, given in a very reasonable timescale. Full support across all function types would have taken way longer to implement, and we would all be wating for 8.6 for a lot longer. I guess they could have done the CRTOBJ/RTVOBJ/DLTOBJ/CHGOBJ functions, but that would have been useless if we couldn't use these functions from any External function, right?

By allowing EXCEXTFUN and EXCUSRPGM to define the new arrays in the parameter interface, you can natively build function without the need to change the source code after generation, and expose these functions as Web Services.

As someone who has been asking for this support for a long time, I think that the 2E team is taking the right route. They have added functionality that can actually be used, reducing the effort to implement result sets in Web Services, while adding the Impact Analysis of these exposed interfaces, something which you are lacking with your User Source route. A much better place than we were with 8.5!

Sure, the coding required is a little more than can be done with some source code, but it is native 2E code, and provides all the great impact analysis functionality that makes 2E such a great development tool.

I am hoping that the new array support will grow into support across all function types.

Looking at the positive rather than the negative...

Crispin.

[Anon Anon]

Hi Crispin

I get that CA have done what they have done and that the 8.6 version is better than 8.5. So I'm not complaining so much as shaking my head in disappointment at the way they have chosen to implement this and sharing how I am planning to utilise it.

Back when arrays were first introduced to 2E I was a bt frustrated - these weren't real arrays - I couldn't access an individual element directly, I had to go through the database functions to get to it. But I see that was a hang over from my 3GL days. Arrays in 2E are a special kind of file not a special kind of variable. Thus one accesses them using database functions and they can be used when needed within the external function.

All that was missing for creating web services is a way to extend the reach of the array. Being able to pass the array as a parameter. I'm fairly confident that enabling the existing 2e array to be used as a parameter would have been easy to implement - much easier thatn this whole move array functionality.

When you were asking for the ability to pass an array as a parameter were you thinking you would get something along the lines that I am suggesting above? Or were you thinking that CA would create a whole new kind of variable that needed to be forced into 2E bit by bit?


I'm thinking about what would be next to do. My main requirement for an array parameter is to supply a list of data to a web service. Thus I would want to be able to have one of these new arrays as an out put parameter to a database rtvobj - I could then replace the existing array crtobj with a *all move array. This seems feasible enough.

My second requirement would be to have an array as an input parameter - where the web app has filled in a grid and the set of lines is passed in at once. I would build a rtvobj over that input array - but how does one do that? CA have said that a rtvobj over an array is not the same array thatis the parameter. Would passing the arrray as a parameter to the rtvobj mean that the rtvobj would use the parameter array rather than the internal array? That seems rather confused.

Or are they thinking we will in the future continue to write our own do loops (something an ex colleague of mine always considered a sign of a 3GL language) and then do a *all move array to loval variables before we can then use the array contents to do something useful?

cheers Harry

To answer your direct question - I don't see much point in adding arrays as parameters to crtobj/chgobj/dltobj.

[Deactivated User]

Hi Harry,

I worked closely with the 2E development team through the Alpha Sprint process (something I highly recommend you get involved in). All of these things were discussed (believe me, I am a very NEEDY 2E developer). When the first pass of the MOVE ARRAY function was given out for testing, there was no ALL support. I pointed out that this was extemely limiting and would be a big problem as arrays changed. You see the results of that conversation.

I completely agree that it would be a lot easier to have a RTVOBJ over a file that passed back an array. But the 2E team know that's what I think.

I completely agree that a mechanism for processing a passed array without having to build your own loops is something that would make this a lot more powerful. But the 2E team know that's what I think.

I really cannot talk to what the future holds in this area, only things that I have asked for, and all I do is remain hopeful that we will see this area of the tool become stonger.

One thing you should consider is post your thoughts in the Ideas section (tab at top of this forum). This is where the 2E team get a lot of their input for product direction.

Maybe my crtobj/chgobj/dltobj excample was a little off point, and perhaps the RTVOBJ would have been better, to get my point across. After all, a RTVOBJ that could return an array as a parameter would not be particularly useful without the corresponding parameters being available for the EXCEXTFUN that called it.

I am sure there were very good reasons for separating the original array functionality from the new Multiple Instance Array functionality, I'll leave that for someone in the 2E team to answer, if they feel the need :)

I really do not think the implementation is disappointing. It can do what it set out to do, provide result sets for Web Services. Sure, the technology is young, and needs to grow, but I think a lot of what is currently being manually coded to handle the processing of the result set (either loading or reading of) could be fairly easily modelled using a new function type, RTVARR - Retrieve Array - to process the array, and by adding RTVOBJ to the allowed function types for ARR parameters.

I guess we have to wait and see what the future holds.

Crispin.

[Anon Anon]

Hi Crispin

That's fair enough. I haven't got anything n particular to add at the moment. When we get 8.6 installed (not a priority at the moment) I'll post an addendum to report how well my planned approach worked.:smile

cheers Harry

[Anon Anon]

Hi,

Thank you Harry for spotting the elephant in the room and Thank you Crispin, as always, for your valuable and supportive input. Very much appreciated.

Please note that what appears to occur from an external point of view does not always mirror what actually occurs within the internals. As you know, 2E is
fundamentally based on a data driven design. As stated within this thread, array support was implemented as a 'special kind of file' (in 1992).

Within the internals, this presented a number of challenges. Being that 2E is data driven, one of the challenges at that time was that all of the generators
(for all of the function types and for all of the different field types) needed to be modified. This resulted in massive programming modifications which needed
to occur in many places in order to support the 'new special kind of file' (i.e. array support). Another challenge was that the generated implementation for RPG
was completely different than the generated implementation for COBOL. In all of the different generations between RPG and COBOL, in my opinion, there is not
a more vast difference in generation than the difference that is generated for the array support.

Overhauling the original array support would have resulted in a lot more code modifications (thus, pushing out the release date significantly) and exponentially
increasing the risk of product stability for both the new feature and the existing array support that has been in use for the last 20 years.

We, in development, believe that we have implemented the correct approach with r8.6.


Thanks,
Mark


Mark Ronayne
CA Technologies
Senior Software Engineer
Tel: [phone]
Fax: [phone]
[e-mail]