Re: Structured Program Software Packages IMHO

In addition to the points already defined by the ex-SSA employee Mr William Washington III, about the pros and cons of the AS/Set development tool, I would also like to enlighten all those that were not aware of why there are limitations in the rangeof "operation" codes and functions available and consequently the large volume of native code generated in AS/Set as a result, also why it was used to develop BPCS in the long term instead of continuing in the use of native code used in V4.x versions.

You have to travel back a few years to the point in the IT industry when the sharp e end of developement was for Client Server based systems across multiple platforms. The idea of AS/Set as a development tool was to enable SSA to take the basic programming functions like IF, ELSE, etc (common in most languages) and on generation convert as easily as possible to the native code of the respective machine.

This was to provide SSA with a common developement tool for all the platforms at which BPCS was marketed, with the concept of allowing the developer not to have to have an in-depth knowledge of the native code as the higher level code was to be adequate (unlikely you might say but this was the concept).

There is, I am sure all developers are aware certain operation codes in RPG that do not interpret well into language like C and are therefore proprietary to that platform. The AS/Set tool came with the option of the RPG compiler and developer, ADK, and the C based mutation called WDK later UDK and various other acronyms, the point being from the developers point of view AS/Set was AS/Set. In order to achieve the catch all scenarios of potential inefficient coders and eventualities additional volume of code is created.

The tool described by Graham Smith for viewing asset code is most excellent and saves serious time (no sales pitch just experience).

Regards

K. H.