Calling all French 2e Users

Just a quick blog today.

CA, actually Daniel Leigh in particular, is looking for Beta testers for the new 8.5 version of 2e. This time for the french language version.

So all my colleagues in 'Les Bleus' country. You can contact daniel. Just let me know you are interested via the comments feature and I will pass on your details or you can contact him directly at:-

daniel.leigh at ca dot com.

Good luck. There are certainly plenty of great new features in this release to get your creative juices flowing.

Thanks for reading.
Lee.

2e Development Standards - Screen Functions (Part III)

Today we shall take a quick look at the Display File function (DSPFIL).

This is a very commonly used function type in 2e and if my notes are correct there may be a thing or two of interest in this post. However, I guess that this depends on whether you are an ageing old developer like myself or one of the new kids on the block in Bangalore.

But back to the action. Like many other function types the DSPFIL can be used to display data and interact with it in multiple manners. i.e. It can act like an intelligent Select Record and also allow multiple selects. It can also be used to show the contents of an array.

Hold on I hear you say.

"It's a display file and arrays are not files......"

That's true but there are methods to complete this. Nudge me with some comments and I might write up a few examples of code to show you how to achieve this.

Also as the DSPFIL has the CTL (header region) it can be used to provide an interface with a tab look 'n' feel.

Anyhow. Major tip. Take a look at the function options for this function type. In particular, the function option called Re-Process Subfile. Set this on and off and take a look at the action diagram. There will be additional user points and logic added if this is set to Yes. This is just another example of the PODA principle that is taught when you attend training.

PODA stands for Parameters, Options, Design and Action Diagram. The philosphy behind this is simple. The more correct decisions you make at the preceding level i.e. Paramters first, then options (function options) etc the less coding (action diagramming) you will need to do.

2e is quite a neat tool. You should be judging your developers based on the least amount of code required rather than rewarding on a LOC principal (Lines of Code). I think it is fair to say that anyone can write a bad program.

Below are two sections that provide some insight into the function.

General Considerations

The default scan limit is 500. This may not be appropriate for large files. If necessary set the scan limit in USER:Initialise Program to a higher value or even to Maximum. Note: That the scan limit is a model value. If you require a higher number by default (across your model) then I recommend you change the model value YSCNLMT.

Best Practice

Any subfile control selector fields not used should be dropped rather than hidden. This is for performance reasons and avoids the problem of unintentionally deselecting subfile records. To do this simply place enter ‘-‘ against the field from within the EDIT SCREEN FORMAT DETAILS screen.

Multi-part ACP key fields acting as positioners will automatically become selectors if low order fields have data and high order fields are blank. Ensure that you understand the type of data likely to be used for the screen.

Check that the operators used by subfile selectors are appropriate for the function design. Ensure you want EQ, LE, GT or CT for example. Don't assume the default role of these fields.

If a positioner or selector field has mod 10/11 check digit then it may be appropriate to replace with a function field without the check digit. The user does have to enter a valid number to position within a list.

Tip

There is no standard feature to stop the function loading records into the subfile under programmer control. The program continues until subfile page full, scan limit reached or hits end of file. However, you may trick the function to thinking its hit end of file by using a RTVOBJ over the same ACP using a very high key value. This positions the file cursor at end of file.

USER:Process Command Keys has got nothing to do with command keys. Command key processing should normally be added to USER:Process Subfile Control.

Subfile select status field is automatically set to blanks if subfile record processing completes without error.

Gotchas

If F4=Prompt is used on any subfile control selector STS type field then there is no automatic subfile reload and CALC:Subfile Control Function Fields is not executed. User then has to press enter to invoke appropriate selection logic. Function works OK if '?' is used. There is no known workaround for this bug. I would suggest that this is not actually a bug and it is harsh to judge it that way. It is simply because the enter key was pressed for the ? and not the F4 prompt.

CALC:Subfile Record Function Fields is executed before USER:Initialise Subfile Record and therefore you may process a record subsequently deselected. i.e. PGM.*Record Selected.

If any RST input parameter key is also input on device design, and its a file to file relation, then that file validation is deferred until the main validation cycle rather than take place during the load cycle. Any automatic virtuals from the 'Owned by' file will be blank when function is loaded.

An input function field added to RCD format will not automatically check for required value. Even if you set the value to Allow Blank ‘ ‘. This is because the DSPFIL template isn’t designed to have input fields and doesn’t generate the validation routine regardless of how the flag is set or any check conditions. Need to add the code procedurally via the action diagram to force input.

An input function field added to CTL format will not automatically check for required Value. Need to add the check procedurally.

Thanks for reading.
Lee.

Can you feel the momentum that is Ft Lauderdale

Hi all,

I'd like to start this off by writing that I have been on a desert island for the last two months on a meditation course for mid life crisis for balding IT men.

But that wouldn't be true...

or perhaps that I have been on a second honeymoon with my wife and was far too tired to blog :-). But that wouldn't be true........either.

I have however, been very busy at work and the soccer season has started here in NZ so I am playing the beautiful game once more, although i'd preferyou didn't ask how we are doing.

But, even these distractions aren't the reason for my lack of postings in the last 8 weeks.

The true reason is that I have moved my laptop to the study and my 6 year old daughter has discovered the magical world of computing and dominates the machine. I do wonder where she gets it from but I think a new computer is on my shopping list in the next month or two.

How many computers are required in a family home in this day and age? You tube and Britains got talent in particular seem to dominate most of the 15.4' laptop screens in this household.

Anyhow, today is a short post to say that I have a schedule for my weekly posts mapped out and will be adding some highly anticipated 2e tips and tricks over the coming weeks.

Back to this post though.....

The title (of course) is related to the upcoming CA Plex and CA 2E user conference in the USA in September. Take a look at this link www.plex2e.com for more details. I have booked flights, arranged time from work and reserved the hotel room. I have even told the trouble and strife (wife) before I booked this as well. 4 brownie points for me. Shame I am still in arrears on this front.

All I have to do now is to submit my brief for a presentation and............oh yeah!!!!....... get working on it.

This is the highlight of my working year when I get a chance to attend these events, learn great stuff about the products that I use and preach about, socialise with friends and colleagues in the industry both new and old and get to attend a Plex in the city event.

I look forward to meeting many of you over the week that I am there.

Until then take care. Only another 115 days to go. I'm counting them down already.

Thanks for reading.
Lee.

Plex Updates

Wow! What a week.

I, like many of you spent 3 hours on the recent CA Plex/2E webcast marketed as 'Blitz'. For me it was a little more inconvenient as it was from 2am until gone 5am in the morning. To top it off it was a school night as well. Suffice to say, Friday night after a hard days work, I was exhausted.

The result though was worth every last minute of sleep deprivation. I felt energised by what these guys had achieved.

To kick off we had an overview from Bill Hunt with a plug for the 4th Annual Conference in Ft Lauderdale, Florida, USA. Then the action got going.

We were treated to an update for the ADC Austin/Websydian Plex Web Client. Delivered by John Rhodes. This is a plex client delivered out of the box once you have the patterns and web environment setup which is receiving plaudits from around the community.

Then Gary McGeorge from Desynit in old blighty demonstrated their customer solution for a trading desk. The highlights for me were the sheer speed of the screen refreshes, the look of the application using the codejock controls with their YouEye pattern. The ability to split the application over 4 dealer screens and have configurable screen layouts blew me away and was a topic of discussion with one of my Plex introduced friends here in NZ the next day. Well done lads.

I wasn't so chuffed with the screaming baby in the background from one of the attendees of the conference who clearly forgot to mute their phone line. I would suggest in future that each presentation has a slide saying 'Mute that damn line now punk. Do you feel lucky!!!'

This was followed by Soren from Websydian showing us what TransactXML was capable of. I had never seen this before but now I understand what it delivers and with the import facility, how easy it is to implement, I will definitely take a much closer look.

Then we had Marty (MKS) and Chistoph (CM First this is the English link) demonstrate the new features in their respective toolsets that support Plex integration and best practice modelling concepts. I would certainly like to know how configurable the flow that was demonstrated actually is, but it looked like a pretty good start to me.

Finally Bill wrapped up with a sell for the upcoming conference. With the guaranteed weather and content similar to what we saw on Thursday it will be a great event by the looks of it, and I thought Cincinnati was good.

My only disappointment is that the guys at ‘all about’ didn't have a slot. What I have seen of their Plex-XML solution is mind-boggling and the presentation layer is amazing. This is a great solution and I am interested in seeing how this develops. They have recently updated their website to include integration with a rich web editor. Amazing stuff.

Until then.

Thanks for reading.
Lee.

Why bad design sucks! - Part II

Hmmmm,

As I suspected a couple of weeks ago once you open your eyes to a subject and commence blogging about it you have it constantly in the back of your mind. My post on bad systems design and planning has had this affect on me.

I am minding my own business at my local quiz night when a question was read out by the quiz master or perhaps mistress as she is a lady. "What day of the week was Valentines Day in the year 2000?" Now as I am not the romantic type so I certainly couldn't recall this answer based on an event, although a friend 'H' was adamant he knew the day.

I decided the simple solution was the mobile phone calender so I plucked out the phone. It is a reasonably new Motorola Razor phone. So you know the routine, Menu, Organiser & Tools, Calendar. Voila.... The calendar is showing February 2009 (the current month when this event occurred).

"Excellent", I said (I remember the excitement), I can now work it out by counting back. Then I thought what about the leap years? So at this stage I decided to press the previous month button again and again and again working my way back in time faster than Marty McFly in his time machine and I didn't need a flux capacitor.

You get the idea, November 2008 came and went. July 2006 soon appeared but a few more key presses and my phone stopped working. It got as far as January 2005 and it stopped. No message, no nothing.

Bang. Another blog appears out of the blue. And a lot of questions.

Why did it stop at January 2005? How am I going to answer the question? Anyhow another of the team had an older phone that could go back further and we got the answer right in the end. fyi it was a Monday.

This got me thinking a little. What is the upper limit for this phone. After hundreds and hundreds of key presses (1007 to be precise) I got my answer NOVEMBER 2088. December 2099 I can understand as it would have covered a century but NOVEMBER 2088, what a strange limitation.

That works out at 83 years and 11 months or 30,650 days and I can't for the life of me think of a reason why my phone wouldn't be calculating this on the fly. It is not showing holidays. Leap years can be identified by a simple formulae. I certainly can't see a contraint in computing terms that would cause this to occur.

If someone can tell me why the programmer decided to restrict the dates in this way I'd be keen to hear your comments. It might be because they assumed that the phone was made after 2005 and therefore didn't need to go back for storing calendar entries. Fair assumption. But why put it in? Another unneccessary computer programmer/designer limitation I think.

Other friends on the night had different limitations on their phones and a colleague at work with a cool new blackberry had no issues at all with date range restrictions far in excess in both directions that he was prepared to sit around trying to find.

I don't think you have heard the last of the 'Why bad design sucks!' series....... It does worry me that people still impose design limitations.

Thanks for reading.
Lee.

2e Development Standards - Screen Functions (Part II)

Part 2 in the series around screen function types will concentrate on the Select Record (SELRCD) function type.

This is often overlooked as a valuable function as it always appears to be generated on your behalf by 2e when you create a file. However, it has a few useful quirks that require a little thinking and I have often seen everly complicated logic added to them due to a lack of understanding where a simple workaround works quite nicely.

Below I summarise some of the key points when using the SELRCD:-

In general there should only be one SELRCD record per file, the default. I propose you rename your default select per for to '*SLT filename'. (See posts on naming standards). However, there may be occasions when it is necessary to select by a variety of different styles, or by a different key value. For example, where the primary key is a surrogate#.

These reasons may justify having more than one selection program, probably built over different ACPs. All other selects other than the default must be name SLT name and not *SLT name. This ensures correct ordering in the file. If using a different access path I would name them 'SLT By access path'.

The *SLT function is named this way as it will be used by the generator when building implicit field prompting code. The routine is also used to validate a record existence in relation checking. (The check restirction within functionaity). As such a default select must be first on the file and also never have its parameter interface changed unless the keys to the file changes.

CA:2E always regards the first SELRCD it finds on the model file as the default. If an alternative SELRCD should always be called for certain relation checks then that should be assigned via the Access Path relation settings. This situation might arise when a file refers to itself. E.g. Horse Refers to Horse for Mare and Horse Refers to Horse for Sire. At the relation level for the access path it is possible to set a default select record for each relation. Therefore the ordering considerations for the generator to substitute a select record are Function Level – Access Path Level – File Level (First on alphabetically on file).

The standard SELRCD should only perform a selection facility. That is, X=Select. However, a display option may be necessary in some cases as is F9 to Add a record.

Selection logic is usually performed one entity level at a time. Therefore if the SELRCD is for a lower level entity, e.g. 'Owned by', then the high order part of the key(s) will normally be RST.

The standard SELRCD should not pass back values other than the selected key. Validation and passing back of attributes is best left to standard RTVOBJ functions since the user may bypass a selection prompt and enter key values directly.

The SELRCD should not be modified to do anything unusual. If a user exits with *Exit key the default SELRCD will always exit program with return code Y2U0016='no value selected' and also send the same completion message. This processing should not be altered.

The parameter key values passed back should have NOERROR set. This is because CA:2E does not treat a 'no value selected' exit (Y2U0016) as an error when called implicitly. But it would be an error if called explicitly in an action diagram.

Closedown option should be set in the context that the program would be called.

If a SELRCD is not sufficient because of action diagramming restrictions then a DSPFIL may be used instead. But it should have a naming convention of 'SLT By or filename'. It should follow the same logic that a SELRCD would do, i.e. Same parameter definition and same action diagram style. This is often used if additional processing like F9 = Add is required.

The advantages of the DSPFIL method is it allows increased flexibility. But if you do choose this approach then this function will never implicitly be used and developers need to handle the output parameters. That said you could template this kind of function.

Tip

Using a Neither MAP input parameter does allow you to set CTL values for additional filtering.

Thanks for reading.
Lee.

Why bad design sucks! - Part I

There are many areas of computing that have been let down by poor design.

Actually that may be a little harsh.

However, poor assumptions have definitely led to numerous designs that in hindsight could be considered questionable at best. These decisions have in turn led to systems that have suffered due to higher than anticipated volumes or longer than expected life spans.

A few examples that come to mind are:-

The millennium bug. Everyone knows this story. Developers designed systems in the 60s, 70s and 80s with 6 character dates ie DDMMYY or MMDDYY. The assumption being that storage is expensive and this system won't be around in 20 or 30 years. Well we all know how much effort was involved ensuring that airplanes never fell out of the sky in the late 90's, not to mention the contract rates for COBOL programmers that went with it. So I guess the lesson learned here is short sightedness.

http://www.trademe.co.nz/. Another example I heard about was for a very popular auction trading site here in New Zealand. The founders at a Microsoft TechEd conference a few years ago talked candidly about the early days of the business. They were describing growth of the business and unexpected challenges for the fledgling company.

The site was adding customers at a nice steady state when one day the system stopped working. No more new customers could be added.

They were a little concerned at first. After all they had just added their 32767th customer.

The issue was that in the early versions of their database they hadn't considered the domain of this particular field to carefully. i.e. the size. They had reached the limit for the integer field type on their platform. Now that the site is the most successful site in New Zealand and has made the creator a multi-millionaire, I am sure they have used at a minimum a long integer. The lesson learned here would be factor your wildest assumptions into your database designs.

www.Virtualrugby.co.nz. A sports predictions site here in NZ that has just rebranded again with another sponsor but suffered the ignominy of poor application performance and a whole host of players unable to access the site. On one occasion I was advised that the server was unable to make a connection because the limit of 111 connections had been reached. This is for a site that had over 100,000 active participants the previous year. I will go as far as suggesting the infrastructure suppliers arrangement may have changed as a result of the sponsorship change. Hopefully they'll get it sorted.

The lesson learned here. Never underestimate your audience and your processing peaks. Most of all ensure that your test systems have a reasonable subset of data to stress a mass participant application. Three guys in a room pressing the submit button as often as possible is not load/stress testing.

IPv6. Another in a long line of bad designs, or is it? It is alleged that we are to run out of IP addresses in the next few years. Some claim that this is the millennium bug of the 2000's. If it is and given the age of computing in general, we might have a few more yet. Sounds not too different to the 100 year storm scenario that happens every 4 years in these days of global warming.

I guess this one could have also been avoided but the caveat once again was when IP addressing got going the internet was quite young and connected devices were at a far lower number than they are today. Lesson earned! What do you think?

......

With all these though, IMHO it was human expectations that were at fault or shortcuts being taken to save a few bytes here or there. My advice to all application developers is to ensure that all your applications have database fields that are capable of supporting data sets beyond your wildest dreams. And to ensure that your application architecture is fit for purpose.

Bad design really does suck. Ask your end user(s).

Thanks for reading.
Lee.

p.s. I titled this Part I as I guess that now I have finally got this off my chest there will be other scenarios out there that will jump out shouting - BLOGGERTUNITY. Actually, one has just emerged but I will save that for another day.

*Arrays can be quirky in 2e

Hiya,

I have just become aware that *Arrays do not support the correct ordering sequence for negative index values. This has been referred to CA Support (2nd Level) for investigation.

My scenario is an array that is ordered based on a difference between two values. For the purposes of a meaningful example lets pretend that our array is a league table for the English football premier league (Soccer to some). If your game is rugby or another sport then you can draw your own comparisons.

The scenario is that after 2 games of the season I have 5 teams on 4 points. These teams are place 1 to 5 on the table. Let's further embelish this example and assume that my team, Tottenham Hotspur (Spurs) are at the top. :-)

Team	Points	GD (Goal Difference)
Tottenham	4pts	+78
Liverpool	4pts	+5
Everton	4pts	0
Wigan	4pts	-4
Chelsea	4pts	-8
......
Arsenal	0pts	-78

Apart from the obvious good start by Wigan and the strange GD for two games. I believe the example table to be a fair reflection of the real world. With Tottenham at the top. COYS. Blue and White army. Stand up if you hate Arsenal.

If I were to create an *array in DESCENDING order with the keys of Points and GD. My array would sort itself as follows:-

Team	Points	GD (Goal Difference)
Tottenham	4pts	+78
Liverpool	4pts	+5
Everton	4pts	0
Chelsea	4pts	-8
Wigan	4pts	-4
......
Arsenal	0pts	-78

The arrays doesn't handle the negative sign and although it preserves the negative sign it is unable to sort it. Note the order of Chelsea and Wigan.

Until this is fixed, a simple workaround I have used is to *ADD an arbitary figure to the GD to ensure it is a positive value. In order not to blow a limit (as over a season a team can be -100) I need to cater for a higher number so I chose 10,000 for the *array as an offset.

At the point of display which happens to be a DSPFIL I simply deduct 10,000. Simple workaround. Hopefully, simple solution that will be fixed some time in the future. Another option which I contribute to my colleague Chris Koloszar is to do the 10,000 offset for the key and leave the original value as an attribute of the array also.

My main concern is for those of you that have negative values but have yet to discover them.

I will post updates as I hear back from CA.

Thanks for reading.
Lee.

UPDATE HISTORY
==============

2:54pm (Same Day). I have had some quick responses from CA (Very impressed - Thanks Lynn). CA claim this to be working as designed. I am countering that it is a bug and was designed incorrectly. I hope that this will be fixed and I will keep you all updated.

What do you think?

Next Day - Referred to development not a trivial fix but I am confident it will be a good look over. Thanks.

Goopression

I thought I'd have a little whinge today about Google. Well not Google themselves. I think that they are a great innovative company who have transformed how we all interact with the internet and for that, I am grateful. I do remember the early days with Compuserve dialup and prior to that premium phone bulletin boards and usenet groups.

But recently I have been exploring business ideas of my own. When I say recently. Like most IT guys I have been pondering the 'garage' project, aka the 'killer app' for years.

We can all use google to research our ideas, get an idea of the validity of the idea i.e. any competitors that may be lurking in the wings etc.

However, today, I am suffering for "Goopression". Google depression!!! This means that your killer idea (no matter how you search for it) has already been taken. The domain has gone, as has your enthusiasm for your idea. This feeling really sucks.

You see, as much as the internet can be an inspiration to us all. One quick google of an idea and all of a sudden you are depressed......Someone else has stolen your idea. Sorry - got there first.

Now for sure. If it is a good idea (which I believe I have) backed up by a great business plan you may well achieve your aim. You will remember the number of search engines that were around pre-google...... Just don't be surprised if your killer idea has already been considered, invented or patented.

That all said, if you are having the ideas in the first place then one day that killer app/idea will happen. Just be prepared for a little disappointment along the way courtesy of our friends from Google.

Thanks for reading.
Lee.

My top ten tips for a software developer

I was updating the blog and getting a few advance posts in place for February 2009. Thanks Blogger.com for the neat features of scheduling blogs that you introduced last year. This saves me a lot of hassle in remembering to post pre-written content and also allows for me to have a blog day every now and then.

Anyhow, I was also reading a few "Top Ten" advice lists that were sent to me over the years by a trusted colleague called Jim. I always take the time to read these and he generally only sends over meaningful content and this time was no different.

This did get me thinking a little so I thought I'd write one and see if he agrees.

I have blogged in the past about what I believe makes a good developer.

Today, I'll issue my Top Ten tips for developers covering both work and life. In no particular order apart from number 10.

1. Always be on the look out for the next big thing (in IT) and see if you can get in early enough to actually ride the wave rather than be left behind frantically trying to swim there.

2. If you find something you like doing and the opportunity is there to continue doing it, then continue to do it! Don't be bullied into career progression if it is not for you. My old boss once said to me that there is a difference between earning and dying. Words of wisdom for everyone.

3. Always test your code no matter how trivial the change. You have no come back if you didn't test a change you have made, fullstop.

4. The ten minute tasks always seem to take a day, or two.

5. Never assume anything when it comes to user requirements or management reporting.

6. Never under estimate the desire of the testing team to see you fall on your developer sword.

7. Never code if you are drunk as you will need to recode the next day. Also never ever ever ever ever ever return to the office if you are inebriated. You will start to talk about 'Pink Screen' technology and how one day you will be everyones boss or worst case scenario, you will set off the fire alarm with a toaster and cause an evacuation of a 21 storey building. Again, certainly no come back here, you are on your own. Believe me, these are true stories......

8. Remember good quality applications and systems have corners. You simply can't cut them.

9. Remember it takes 20% of the time to build 80% of what the user sees and interacts with. The remaining 80% is making sure that they don't break anything.

10. Never compile a top ten list and not have a decent one for point number 10.

Thanks for reading.
Lee.