Friday, November 10, 2017


Almost every programming language has at least two kinds of numbers: integers and reals. In the old 16 bit days, an unsigned integer could have a value between 0 and 65535 (that's 2 to the power of 16, less 1), whereas a signed integer could have a value between -32768 and 32767 (215 − 1). In these days of 32 bits, an integer can have a value between −2,147,483,648 (−231) and 2,147,483,647 (231 − 1). An integer does not have a fractional part; for this, one uses real numbers, which have a range of −238 to 238. Whilst real numbers have a much larger range than integers, they are also less accurate: there are certain fractions which are very difficult to store in binary. This lack of accuracy causes problems when real numbers are multiplied, and so some languages store real numbers as 'decimal shifted' integers (i.e. 3.333 is stored as 3333). This is very important for applications which deal with money as no accuracy is sacrificed.

As Priority deals with both monies and stock quantities, it provides integers, reals and decimal shifted integers. As usual, the documentation is not too clear how to use the different types, so this blog is intended to clarify matters, especially with regard to decimal shifted integers. The TRANSORDER (inventory movement) table - as well has other tables - contains a few fields whose name is like QUANT (quant, tquant, cquant); in the table directory screen, these fields are defined as integers with a width of 17.3. This means that they are stored as integers but their values should be shifted three columns to the left in order to obtain their real value; as written above, a quantity of 3.333 would be stored as 3333.

The screen manager knows automatically how to display such fields (3000 would be displayed as 3.00) so the beginning programmer doesn't have to convert anything. The problems begin when one wants to calculate something based on such a field: for example, the value of inventory is calculated by multiplying the amount in inventory by the part's cost. The unaware programmer will write this statement without change: if the amount is 3, then it will be stored as 3000, and multiplying by the cost (let's say 20 shekels/unit) would result in the value of the inventory being 60,000 shekels! Obviously the quantity has to be converted to a real number before multiplying, so one would actually write REALQUANT (TRANSORDER.QUANT) * PART.COST. This will give the desired result, 60 shekels.

The result of such a calculation should be stored in a variable which has been defined as a real. The easiest way to do this in a procedure is to initialise the variable in the following manner:
Sometimes it is necessary to store the result of such a calculation back into a decimal shifted integer: for this one uses the INTQUANT function, which as its name suggests, turns a quant into an int. I've had to use this function recently as I was writing code which creates bills of materials; a quantity field in the interface requires a decimal shifted number which is calculated on the basis of a real number and another decimal shifted number. INTQUANT requires its operand to be a real number, so the easiest way of ensuring this is to include 0.0+ in the expression, as follows:
The variable :COEF has already been defined as a real (for example, this would hold the value of PARTARC.COEF, which defines the number of 'son parts' to its 'father part') whereas :QUANT would be a decimal shifted integer, such as ORDERITEMS.QUANT.

The parser in Priority procedures can be a bit stupid, so one should give it all the help one can by predefining variables. Otherwise one is liable to receive the error message that :VARIABLE has been defined having two different types.

I tend to use REALQUANT when I am writing cursors, so that I know that I am working with a real number; I find this makes life a bit easier. For example,
Basic rule: never write an arithmetical expression using decimal shifted numbers without REALQUANT! That's about all there is to say about INTQUANT and REALQUANT.

Tuesday, November 07, 2017

ERP enhancement management

I spent about three hours on Friday, brainstorming with regard to my research proposal. The results of that thinking appeared in my previous blog entry. On Saturday I spent about the same amount of time looking for introductory papers in three disciplines - organisational change management, engineering change management (ECM) and product management. On Sunday I printed the papers and glanced at them but didn't have much time to concentrate on them.

Yesterday evening, I sat down with the printed papers and my mobile computer, and started reading the papers, extracting the salient points and adding them to the research proposal. I was very pleased to note that one of the papers on ECM contained a five stage model which was very similar to mine. I was able to contrast ECM with my proposed change management discipline and in doing so, I was able to present my model naturally, without feeling that I was pulling a rabbit out of a hat.

After I completed writing up the papers and introducing my model, I looked again at my mentor's post from last week which started this flurry of activity. He suggested looking at stakeholder literature, which is a topic which I hadn't considered. After entering that term into Google Scholar, I was presented with a list of papers from which I chose one, entitled "A roadmap for IT project implementation". This was exactly what I needed, as it provided some choice quotes. There was also room for critical evaluation: this paper deals with project implementation, e.g. implementing Priority, whereas my research is concerned with implementing enhancements, which of course are on a much smaller scale in all respects. Fewer people are involved, the costs are very low and the time span is negligible.

Once I had added a paragraph or two, I realised that I had a complete document which I could send back to my mentor. I was quite surprised that I had managed to implement the changes in such a short time. Now I can focus my time on other activities.

Monday, November 06, 2017

40 years ago

12Nov1971Al Stewart
16Nov1975Richard and Linda Thompson
17Nov1976National Health
6Nov1977Sandy Denny

Above are extracts from the concert log which I used to maintain in the old days, when I went to concerts. The first and last entries are the most interesting, coincidentally on the same date. 

I've written about Heron and this concert before: it was a promotional tour, selling tickets for one old penny! I very much enjoyed their set, which persuaded me to buy their eponymous album (I listen to it to this day and still enjoy it very much). It was this concert which weaned me off rock acts such as Ten Years After; I was much more content to listen to this 'wooden music'.

The last concert on the list is the last time I had the pleasure of seeing Sandy Denny in her brief life. I know that there are plenty of fans who never saw her appear at all, so I should be thankful that I saw her three times - once with Fotheringay, once with Fairport and once on her own (well, with a supporting band of five musicians). To be honest, I remember almost nothing of the music, but fortunately some of the concerts on this tour were recorded; many many years later, we were treated to a cd of one of them. My name appears in the credits of this disc, which was very kind of the producers. My contribution was to send them a copy of my ticket (which was not for the date which was recorded) and an advert for an earlier Sandy record - none of which found their way into the final booklet. I admit that this is not a disc that I listen to - Sandy's voice had almost completely gone.

This concert is also memorable for a more personal reason: I invited a girl to go out with me to this concert and she accepted. I don't remember whether this girl has ever crossed the pages of this blog so I had better introduce her; we had met about a month earlier at the inaugural meeting of the Jewish Society at my university. It turned out that she was in the new intake of my degree course whereas I was a final year student, so we had more than a few things in common. She also didn't live too far from me, in Swiss Cottage, which was a brisk 40 minute walk for me.

The memory which stands out about this girl (for whom I wrote the song 'M') was when I invited her about a month later to the communal house for our Chanuka party. The next morning I phoned her, asking whether she enjoyed herself; we proceeded to have a half-hour chat which left me slightly bemused. I remember saying to someone that her tone was far more friendly than it should have been. A minute later, M phoned and apologised: she thought she had been talking to someone else! Our relationship lasted only about another month, mainly because we had less in common that it might have seemed at first.

Friday, November 03, 2017

More thinking on the page (DBA)

This post is a continuation of a previous post from three weeks ago, so it's best first to read that post before continuing with this one. As the title alludes, I am going to be 'thinking on the page', so I can't guarantee that there will be an ending or any conclusions from what I write, although I certainly hope that there will be.

My mentor was not particularly impressed by my new version of my research proposal, which featured the seven stage model for developing enhancements. I too had certain doubts about this as I had asked him about where the model should be introduced; at the moment, it had a deus ex machina quality about it as it doesn't flow from the limited literature review. The mentor suggested that I not use the model in the proposal, which returns me to the stage I was in a few weeks ago: what is my research question? What are the aims and objectives?

After further cogitation, I am naming the concept which is to be researched as 'ERP enhancement management' (EEM), a term which I don't think exists in the literature. The definition is based on the seven stage model, but I'm going to ignore that for the moment; instead I will define it in terms of what it is not. EEM has similarities to organisational change management (OCM, a well researched topic) in that it affects the organisation and should achieve strategic or tactical objectives; it is also connected with several groups of stakeholders (which is defined as "members of the groups without whose support the organization would cease to exist"). But EEM is concerned with incremental and fairly minor changes, whereas OCM generally is concerned with major changes, often in critical situations. Also, the success rate of OCM is much lower than that of EEM.

There is also similarity to engineering change management (ECM) but differs in several aspects: ECM is generally concerned with the life cycle of a product, and not incremental changes to software. ECM also is much more technical that EEM - I am purposely leaving out all the technical aspects of EEM, leaving only the managerial aspects.

There is also similarity to software product management (SPM), but as its name hints, SPM is concerned with the life cycle of a complete software product and not with incremental change. That said, there may well be lessons to be learnt from a description of how (for example) Microsoft manages changes in Word or Excel (I doubt that I'll be able to find academic papers on this topic). But then again, these are changes to a product which completely ignore the effects of the software upon the organisation and stakeholders.

So it would seem that EEM is a distinct topic about which there appears to be no prior research. So this is a good example of a research gap.

I found a Doctor of Engineering thesis which examines the engineering change management process (William Rowell: 2013, University of Strathclyde); there is no research question, but the aim and objectives are illuminating. The aim: To characterise the variations in the engineering change management process within the product life cycle and explore the relationship between this process and artefact knowledge. Based on the findings from this study, recommendations for improving existing engineering change management practice shall be offered.

The objectives are (briefly):
  1. Synthesise and discuss relevant literature in the field of engineering change management
  2. Present empirical evidence of the activities that are enacted during the engineering change management process
  3. Present the impact of the research in terms of how the results should influence future engineering change management practice
  4. Discuss the benefits and limitations of the research findings and approach used to obtain these findings, offering conclusions and avenues for further research
These objectives can easily be reworded for my purposes. But what is the research question? At the moment, there are two:
  1. By what methods do organisations develop enhancements?
  2. How closely do those methods match the proposed process model?
Clearly, the second question has to be dropped as there is no proposed process model. The first question is in the right direction but needs to be developed a bit more. Going back to Rowell's thesis, his second research question is What types of artefact knowledge are used and created during the engineering change management process and what can be taken from this to improve the engineering change management process? So ...
  1. What are the steps taken by organisations in the ERP enhancement management process?
  2. How can these steps be generalised in order to create a model to improve the process?
That's not a bad beginning. This will require discarding (once again) a fair amount of material which is included in the current version of the proposal. Hopefully, the next version will tighter as well as being refocused; its title will now be Examining the ERP enhancement management process in Israeli SMEs.