This week, I continue the coverage of validation lists and validation list entries, which I began in the June 11 issue of this newsletter. In that article, I discussed the basics of validation lists and the anatomy of validation list entries, and I also provided new validation list commands. I recommend reading the article, if you haven’t already. A link is provided at the end of this article.
As I’ve demonstrated in my earlier contributions to this column, you’ll often build the validation list APIs and functions directly into your applications. You can also find links to these articles at the end of this article. However, while developing and testing these applications, you’ll often need to create, change, verify, and remove validation list entries to make sure that everything works the way you’ve designed and planned. This is where the Add Validation List Entry (ADDVLDLE), Verify Validation List Entry (VFYVLDLE), Change Validation List Entry (CHGVLDLE), and Remove Validation List Entry (RMVVLDLE) commands I present today can offer some assistance.
Each validation list entry command also constitutes an interface to, and example of, the equivalent validation list entry API and can be employed as a starting point for your own use of these APIs. I think it is fair to say that the validation list API documentation, and the data structures defined for the API input and output parameters, at times can be quite challenging. Hopefully, these examples will provide a shortcut, should you need to code these APIs yourself. Only the data structure enhancements added to RPG IV in recent releases have made it possible to define the data structures exactly as they were designed by IBM’s API programmers.
To show you an example of this complexity and how it matches the RPG IV data structure facilities, I’ve included a walkthrough of one of the validation list entry API data structures from a previous article. Let’s look at the Add Validation List Entry API parameter data structure that specifies the entry’s attribute data, Qsy_Attr_Info_T. Currently, this data structure primarily supports the ability to define whether a validation list entry’s encrypted data is allowed to be stored in a decryptable form, a concept I explained last time.
By default, if you don’t submit this data structure on the API call, this attribute is set to zero, which will prevent you from retrieving the encrypted data from the validation list. You’re faced with the challenge of defining this data structure correctly and initializing this attribute to ‘1’ in order to make the encrypted data retrievable.
Articles on Apis 