Idea Details

Repeating Group Views with Cardinality 1 - who else uses them? (F57118)

Last activity 03-11-2019 11:32 AM
Anon Anon's profile image
03-19-2015 05:31 AM

Most people use Group Views for their repeating rows. However, it is possible to specify Cardinality 1, or alternatively a 'NON-Repeating' Group View (sometimes called a 'Singleton' Group View).  These are implemented as different things at generation/runtime - a Repeating Group View with Cardinality=1 gives array (or equivalent for the platform) with size/length 1, whereas Non-Repeating Group Views are implemented much like standard views without arrays.

Gen's generators and runtime all understand this, and the developer is largely unaware of the subtle difference (you cannot code logic to manipulate SUBSCRIPT in a Non-Repeating Group View).

However, when it comes to Java Proxies, while the generator behaves consistently with the above description (Repeating Group View with Cardinality 1 results in arrays of length 1), but the Java runtimes (in particular, the initViewData method) gets it wrong and initialises such views as if they are Non-Repeating i.e. normal views without arrays.  This causes the Java to give exception in the IA/OA logic when you call the code using the Java Proxy and thus you cannot use 'Repeating Group Views with Cardinality 1' in Java with Proxies.

The Gen Consistency Check pulls this up as an error, but of course, not many of us actually use the Consistency Checks, and may well have models with Group Views like this, and have had for years - working perfectly in all other environments.

It is not necessarily a simple job to change the Group View Definition to be Non-Repeating, as their may be much logic that deals with SUBSCRIPT, which would be invalid.

So the question is... do other Gen sites uses Group Views like this (Repeating with Cardinality 1), and would the lack of runtime support in Gen's Java runtimes be an issue?  We know this is true for at least one site... but how widespread is it?  Does CA need to fix the Java runtime?

Surely it would be a simple matter to have the runtime fixed?   Is it not a trivial change?


Comments

03-11-2019 11:32 AM

This idea has been moved to "currently-planned". We intend to implement the idea in a future release (or continuous delivery). At this time no target date has been set.

 

Best Regards,

 

Rob Thompson

10-17-2017 03:40 PM

After reviewing this wish-listed idea, I have added a task to our development backlog for analysis, and changed its status to "under review".

 

Regards,

 

Rob Thompson

Product Owner, CA Gen 

05-12-2017 04:26 AM

We use RGVs with card 1. It is an easy way of distinguishing between NULL and SPACES. In servers you cannot define the export views as nullable, which is why we used this technique. We just check LAST-OF to determine if the view is populated or not.  It works just fine when passing the RGV around ABs but as soon as you pass it från a CICS Server to a .NET Proxy it fails because the .net Proxy cannot deal with RGVs with card 1.

I raised a support issue for this and got the same response as IET did, i.e. there is a consistency check error message and therefore it is "working as designed".  I've voted up for this idea.

11-06-2015 05:19 PM

This idea has been wish-listed as it has less than 10 votes but more than 1 and has been in New status longer than 90 days.  If this idea is something you'd be interested in, please vote for it.

03-31-2015 03:07 PM

I believe that there is a way to resolve this with an enhancement that will not change the behavior of the generated application unless the user explicitly decides to do this.  Although there has been a lot of commentary on this idea, no one has currently voted for it (perhaps because I indicated that this was not a bug).  I still believe that this is not a bug but I do think the behavior can be changed and CA will look into doing that if this idea gets enough votes.

03-19-2015 07:23 PM

To correctly answer your question though - I've seen it, not super common, and usually occurs when someone's planned a service that will report back more than 1 item, but when the implementation progressed, found that to not be the case.  It was simpler for them to scale back to 1 to enforce a single uniqueness rather than to change it entirely, including yanking the subscript related code.

03-19-2015 06:55 PM

There weren't too many instances in the customer's models and it is an unusual coding approach. The work was done by the customer, so not too onerous for us ;-)

 

We produced some SQL to identify the culprits. If anyone else is interested, here it is for the CSE. It lists the group view names and the model:

 

select model_name, obj_name from dobj, dmdl

where obj_type_code=165 and obj_char_prop_4='M' and obj_int_prop_2=1 and model_id = obj_model_id

order by 1, 2

 

The SQL could be extended to also show the action block name with a bit of extra work, but this will at least show you if you have any issues.

03-19-2015 06:49 PM

Thanks for the clarification Darius - apologies for reading it around the wrong way.  Seems an even bigger noodle scratcher for me that it won't get fixed then.  Hopefully the workaround wasn't particularly onerous.

03-19-2015 06:47 PM

It was originally raised as a support case and the response was that it will not be fixed and that we should raise an idea instead.

 

Note that the issue is not that you cannot use a singleton group view, just that you get a problem if it is defined as repeating with a max cardinality of 1.

 

In the meantime, for the specific customer situation the workaround has been to change all of the group view occurrences to be non-repeating.

 

If it should not be allowed then perhaps it would be better to prevent the user from setting a group view to be repeating if the max occurrences are <2 rather than reply on a consistency check error since the code generators still generate the code but it fails at runtime on some platforms, which is inconsistent.

03-19-2015 06:28 PM

The problem with this approach is that you're implementing an inconsistent behaviour across environments.  There's too much of that already.

 

Group views of cardinality One are a core of the Gen language.  There's nothing I can find in the documentation saying you shouldn't use them, nor that they aren't supported in all environments (which isn't to say it isn't there, I just can't find it).  The toolset doesn't restrict their creation (like they do with, say, GUI commands).  The generators themselves aren't failing to generate valid code.  And they appear to be supported in all environments, except, apparently, Java proxies.

 

Given the value proposition of Gen is being able to migrate between environments without having to adjust your code, this directly reduces that value.  You can say there's a consistency check, but this is still a bug - it's completely within CA's power to resolve it, there's no dependency on a third party or a limitation of Java, it doesn't impact on the user's generated code, and there doesn't appear, from a user's perspective, to be any reason why this can't be solved.

 

It should be raised as a support case, and CA should treat it as a bug.

03-19-2015 06:14 PM

As there is a consistency check error (not a warning) against doing this and this CC error has been around since God created dirt, I'd argue that this is not a feature of the language and is working the way it is supposed to in C# and Java and not working the way it is supposed to in C and COBOL.  If this idea gets enough votes, we'll remove the CC rule and changing the behavior in C# and Java (but we'll do it in a way that you have to opt-in so as not to change the current behavior).

03-19-2015 06:02 PM

Arguably, this is just a straight up bug, and CA should fix it.  It's a feature of the language, and if it's not working as it's supposed to, they should just fix it.  I'd suggest raising a support issue with CA, provide the test case, and let Sustaining Engineering sort it out.

 

But yes, I've used it, and I've seen it used in a number of places - it's a convenient way to group together related entities into a higher conceptual unit and acts as a good indicator to the consumer of a CAB they should take them all as a group.  It's also the only way you'll ever be able to nest more than 3 levels deep of group views, though I wouldn't recommend anyone do that if they can help it!