Solution Option - Content from zFS file inferred from URIMap name

[ijmitch]

This idea is to match the resource against the URIMap and then look for a zFS file in a given directory with the same name as the URIMap.

For example, if you have URIMaps called payroll and HRApps, then the CORS content to be returned would be put in individual files with those names in a directory called "ussconfig/web/optionsresponses".

ie. "ussconfig/web/optionsresponses/payroll" and "ussconfig/web/optionsresponses/HRApps".

If there was no file with the same name as the URIMap, then the existing hardcoded 'not allowed' response would be returned.

[Karagines]

I like the simplicity of this idea. While there isn't a direct link between the URIMap and zFS file, the rule is established and discovery can still be done based on the rule. JSON services using the REST interface or request-response interface would need to define a URIMap explicitly rather than allow a dynamic URIMap. It is small price to pay. As for storage location, we already have the USSCONFIG SIT parameter so it uses an existing configuration location.

[ijmitch]

thank @Karagines ... I was wondering about whether it makes any sense to do this with a wild-carded URIMap, and was thinking like you that it probably doesn't.

I agree that ussconfig would be a more appropriate location under which to define the directory to search.