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.
A blog devoted to CA 2e (Synon) or CA Plex.
Sunday, March 15, 2009
Sunday, March 8, 2009
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.
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.
Using a Neither MAP input parameter does allow you to set CTL values for additional filtering.
Thanks for reading.
Lee.
Lee.
Sunday, March 1, 2009
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.
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.
Tuesday, February 24, 2009
*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. :-)
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:-
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.
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.
Friday, February 20, 2009
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.
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.
Friday, February 13, 2009
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.
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.
Wednesday, February 11, 2009
Its Product Enhancement Time for CA Plex and CA 2e(Synon)
Not many software companies give you the chance to directly influence the strategic direction of a product you use.
The product team at CA are once again asking us to cast our votes for potential enhancements to the CA Plex and CA 2E (Synon) tools.
This recent communication was sent by Bill Hunt to all PLC (Product Line Community) members. If you are not on the list then you are not in the know.
Join.
See details below.
"Hello CA Plex and CA 2E Community,
User feedback, suggestions and ideas are an important element in our development planning efforts. With this in mind, we would like to invite and encourage you to participate in our annual Enhancement Request Priority Voting program. We are launching this program effective now.
As was also the case last year, we ask that you review the attached list of enhancement requests which our team has reviewed and considered worthy of additional research. There is one list for CA Plex, one for CA 2E - choose whichever list(s) are applicable to you.
From these lists, we ask that you submit your “top ten” priority enhancements from this list:
- Voting is done online:
o For CA Plex: https://www.casurveys.com/wsb.dll/156/PLCPLEX-ERJan2009.htm
o For CA 2E: https://www.casurveys.com/wsb.dll/156/PLC2E-ERJan2009.htm
- You must be a registered member of the CA Plex/2E Product Line Community in order to submit a vote. Use your registered e-mail address and password to log into the voting system.
- The online system is the only manner is which votes will be counted.
- CA Employees are not eligible to submit votes.
- Please do not send your votes via e-mail to me, or Daniel Leigh, or any other CA team member – votes submitted this way cannot and will not be counted into the results.
- Each PLC member is allowed one vote each (if you use Plex and 2E you are able to participate in both surveys)
- If you have colleagues using CA Plex or CA 2E, please encourage them to register for the PLC:
o Go to http://causergroups.ca.com
o Click “Join Today”
o Choose “CA Plex/2E Worldwide PLC Global User Community” in the drop down box indicating which user group to join
o Fill in the required contact information
o It only takes a minute and it costs nothing!
- In addition to the actual enhancement request survey, there are some poll questions included online regarding your overall use of the products, your impression of the PLC program and what events you would like to see or would be likely to attend in the future. We ask that you answer these questions as well; this would be helpful to us and very much appreciated.
- The “voting polls” will be opened Monday 9-February and close on Tuesday 31-March. This should give teams ample time to review the lists and make decisions on which items would be more of a priority to help your CA Plex or CA 2E development efforts in the future.
Our participation as a group in this program last year was excellent, and we hope to get at least as much participation as last time. If there are questions please don’t hesitate to contact me, thank you in advance for helping us understand your needs, and for your continued support of CA Plex and CA 2E. "
JUST DO IT!!!!!
Thanks for reading.
Lee.
The product team at CA are once again asking us to cast our votes for potential enhancements to the CA Plex and CA 2E (Synon) tools.
This recent communication was sent by Bill Hunt to all PLC (Product Line Community) members. If you are not on the list then you are not in the know.
Join.
See details below.
"Hello CA Plex and CA 2E Community,
User feedback, suggestions and ideas are an important element in our development planning efforts. With this in mind, we would like to invite and encourage you to participate in our annual Enhancement Request Priority Voting program. We are launching this program effective now.
As was also the case last year, we ask that you review the attached list of enhancement requests which our team has reviewed and considered worthy of additional research. There is one list for CA Plex, one for CA 2E - choose whichever list(s) are applicable to you.
From these lists, we ask that you submit your “top ten” priority enhancements from this list:
- Voting is done online:
o For CA Plex: https://www.casurveys.com/wsb.dll/156/PLCPLEX-ERJan2009.htm
o For CA 2E: https://www.casurveys.com/wsb.dll/156/PLC2E-ERJan2009.htm
- You must be a registered member of the CA Plex/2E Product Line Community in order to submit a vote. Use your registered e-mail address and password to log into the voting system.
- The online system is the only manner is which votes will be counted.
- CA Employees are not eligible to submit votes.
- Please do not send your votes via e-mail to me, or Daniel Leigh, or any other CA team member – votes submitted this way cannot and will not be counted into the results.
- Each PLC member is allowed one vote each (if you use Plex and 2E you are able to participate in both surveys)
- If you have colleagues using CA Plex or CA 2E, please encourage them to register for the PLC:
o Go to http://causergroups.ca.com
o Click “Join Today”
o Choose “CA Plex/2E Worldwide PLC Global User Community” in the drop down box indicating which user group to join
o Fill in the required contact information
o It only takes a minute and it costs nothing!
- In addition to the actual enhancement request survey, there are some poll questions included online regarding your overall use of the products, your impression of the PLC program and what events you would like to see or would be likely to attend in the future. We ask that you answer these questions as well; this would be helpful to us and very much appreciated.
- The “voting polls” will be opened Monday 9-February and close on Tuesday 31-March. This should give teams ample time to review the lists and make decisions on which items would be more of a priority to help your CA Plex or CA 2E development efforts in the future.
Our participation as a group in this program last year was excellent, and we hope to get at least as much participation as last time. If there are questions please don’t hesitate to contact me, thank you in advance for helping us understand your needs, and for your continued support of CA Plex and CA 2E. "
JUST DO IT!!!!!
Thanks for reading.
Lee.
Friday, February 6, 2009
BLOGGERTUNITY
I have been meaning to write this little post for quite a while. I coined the term many many months ago when I was at my local pub quiz.
Most of you bloggers out there realise that once you start blogging you go one of two ways. You get addicted, it consumes time and you post. Or you have a go for a while and then it peters out as you run out of ideas or opportunities to blog.
This got me thinking about a "bloggertunity". This is an event that leads to the opportunity to blog.
I have checked http://www.dictionary.com/ and the word is not referenced.......Indeed the resultant alternatives leave something to be desired if you ask me.... Look Here.
I then decided to google the term and it came up with "Results 1 - 10 of about 171,000 for bloggertunity. (0.07 seconds)" Number of hits for the term as of 31st January 2009 17:40 NZ Time). So clearly it is going to take a while for the term to catch on. Try typing in Britney or Obama and look at their results for a comparison.
But who knows, in the future this word might be as much a part of everyday language as "googled". Time will be the judge on this one.
How many now? Click the link below to find out?
http://www.google.com/search?hl=en&q=bloggertunity&meta=
I then came across the piece of paper (hence this post) I wrote that night which has a few other interesting blog posts. So with pen and paper in hand you should never pass up on an opportunity to generate content for your blog.
Now, for the regular readers of this blog focused on software development principles and the model driven development tools CA Plex and CA 2E (Synon) you could be forgiven for asking the question "What relevance does this post have to your blog Lee?".
Well you are quite right. The answer is a resounding
"NOTHING, ABSOLUTELY NOTHING."But it was a bloggertunity that I couldn't let pass me by.
Thanks for reading.
Lee.
Saturday, January 31, 2009
2e Development Standards - Screen Functions (Part I)
I guess the last couple of months have been a bit quite on the site. This was due to some holidays on my part and the visit of relative from overseas for 5 weeks. As you may know I live in New Zealand and the Christmas and New Year period is a time of relaxation and recouperation as well as a period of mass and I mean mass national holiday. Many businesses shut down for a compulsory two weeks.
I am now refreshed and ready to finish off those blog posts that I promised at the back end of last year.
Today I want to continue the 2e (Synon) development standards theme. I really want this site to be an extension to your technical libraries. So without further procrastination, I will get on with development standards, tips and gotcha's for 2E screen functions.
Today will shall concentrate on the single record function type PMTRCD. Future posts will cover the remaining single record function types as well as multiple record function types like DSPFIL etc.
If used as designed and thats a big 'IF', then this function should have fields on the screen that are prompts for the user to input some values which are then passed to another function for action. These would typically be a report or a processing program of some description.
But, like everything in 2e, the original design intention and actual use is only limited to the users creativeness. I have used these screen types for edit and display screens, prompts, information windows and even restricted subfiles. They are powerful for a number of reasons but for me the ability to DROP the relations and code a screen from a blank canvas is very satisfactory indeed.
I am now refreshed and ready to finish off those blog posts that I promised at the back end of last year.
Today I want to continue the 2e (Synon) development standards theme. I really want this site to be an extension to your technical libraries. So without further procrastination, I will get on with development standards, tips and gotcha's for 2E screen functions.
Today will shall concentrate on the single record function type PMTRCD. Future posts will cover the remaining single record function types as well as multiple record function types like DSPFIL etc.
If used as designed and thats a big 'IF', then this function should have fields on the screen that are prompts for the user to input some values which are then passed to another function for action. These would typically be a report or a processing program of some description.
But, like everything in 2e, the original design intention and actual use is only limited to the users creativeness. I have used these screen types for edit and display screens, prompts, information windows and even restricted subfiles. They are powerful for a number of reasons but for me the ability to DROP the relations and code a screen from a blank canvas is very satisfactory indeed.
General Pointers
A PMTRCD will typically be used in situations where an EDTRCD or DSPRCD is not applicable or too complex, or will have too much of a processing overhead or the traditional methods highlighted above.
For performance reasons any fields or file-to-file relations not needed should be DROPPED from the device design.
After USER:User Defined Action there is no check for any outstanding errors during the User Defined Action processing. If the function option Repeat=No then function may just exit and any errors will not be reported back to the user. Therefore it is a good idea to do a *Quit if PGM.*Return Code is not *Normal, or *Quit if *PGMERR.
Tip
If the function requires a complex set of fields or file to file relations which is not present on any existing file then consider creating an array with fields set to MAP for the PMTRCD. This is often easier and simpler than basing the function on an existing model file, then using lots of function fields and adding procedural based action diagram checking.
Gotcha's
If the function option Repeat=Yes is set then the PMTRCD just loops back to redisplay the detail screen. It does not execute USER:Load Screen. To make the function execute this user point again call user source 2E Force PMTRCD Reload
A PMTRCD behaves slightly different to an EDTRCD. During the validation cycle there is a *Quit if *PGMERR after USER:Validate Fields.
If the primary key relation check has not been turned off then an automatic prompt is generated to a SELRCD over the based upon file. But unlike other file to file relations there is no opportunity to choose which SELRCD is to be called. This I need to validate as I was unable to replicate at the time of writing.
Hope this helps?
Thanks for reading.
Lee.
Monday, January 5, 2009
Credit Crunch 2009 and IT.
I would suggest that other that Britney Spears in recent months "Credit Crunch" has been the most widely used search term on the google servers. No doubt someone will correct me on this subjective comment.
What does this mean for us in IT over the coming months/years. For sure many companies are going to tighten their belts during 2009. Capital expenditure will probably have processes, procedures and forms redesigned/created for general publication. The good companies started this 12 months ago.
Well I guess there is (as always) both opportunity and risk. Mergers and Aquisitions will continue therefore some consolidation will occur. How you are affected will very much depend on what you do, your role and business etc, your skills and a little bit of luck. There isn't too much you can do if your CEO is Bernard Madoff. But if your company is tight on expenses and hasn't blown the budget in recent months on a hope of business eventuating then you have a tick in the good column.
I list below my 5 top tips to avoiding uncertaintly or unemployment due to the credit crisis.
1. Networking.
Many people have simply rode the good times of the last decade and have largely ignored this simple working practice. We all know the phase "It's not what you know but who you know." Check all your email addresses for old colleagues and make contact. Join professional and social networking sites like LinkedIn and put your profile on the web and reconnect to those old colleagues.
You may go as far as publish a blog. At a minimum your CV should be on your regional major recruitment portal. Employment is changing. People are now being headhunted via these sites and in these times they (recruiters and employers) will perform the data mining rather than incur the costs to advertise. You may be the dream candidate but if the job is not advertised then you will not hear about it.
Subscribe to news feeds for your technologies and industry and get reading. Join forums and post questions and replies therefore becoming known as a regular and reliable contributor.
2. Review and update your CV.
Even if you feel you have the most resilient of employer and the most solid of job prospects at your firm, you should always from time to time review the CV. That technology buzzword from 2005 may not cut it when there are 50 candidates for a job, the search spiders may know it as something different in 2008. Just ask IBM and the rebranding of the AS400, System i, iSeries or Power System.
Read, read and re-read your CV. Tune it to your skills, be honest and review it candidly. Would you employ you? I see too many CV's where the presentation is poor. Spacing, order, typo's are a few of my pet hates.
So update the CV and rehearse in your mind what you would like to project at interview. If the CV doesn't say it then you are unlikely to be be given the opportunity to do so either.
Do not wait until you need your CV. It takes a week or two to polish a decent CV and in a competitive environment like redundancy when many people or made available that next job could be gone before you hit the spell checker toolbar button.
3. Perform a skills review and add breadth to your skill set.
If you are a one trick pony. Learn another one quick. Unless of course you are best of breed then you might be OK. As a developer you are used to change and learning on the job. Make 2009 the year where you spend less time on the golf course and more on training courses and home learning. Understand what is coming in your area and ensure you know it well.
Challenge your employer for a training course. If they refuse? What does this say.......
4. Talk to your boss.
Put simply. Don't panic too much if your company is pretty safe. After all some firms have business models that thrive in these uncertain times. But there is nothing stopping you asking the hard and direct questions of your boss. Any quality manager will already understand the local situation and will have a reply for you if they haven't already addressed this as part of their attrition strategy.
If you don't like what the boss says then ask the bosses boss. Get the answers you need.
5. Cut your expenditure (Work and Home).
There are many things you can do here. Take sandwiches to work. Car pool to work. Reduce mobile phone expenses. Go to the gym instead of the pub to name a few.
All of these will boost your savings a little just in case you are cut. This will increase the amount of time you have a make an informed next career choice rather than a hasty decision and a blot on the CV.
As a Plex/2e developer you are probably slightly more shielded than others. After all, you are not ten a penny people. That niche skillset could help out quite nicely.
So look out for the signs.
Good Luck.
Thanks for reading.
Lee.
What does this mean for us in IT over the coming months/years. For sure many companies are going to tighten their belts during 2009. Capital expenditure will probably have processes, procedures and forms redesigned/created for general publication. The good companies started this 12 months ago.
Well I guess there is (as always) both opportunity and risk. Mergers and Aquisitions will continue therefore some consolidation will occur. How you are affected will very much depend on what you do, your role and business etc, your skills and a little bit of luck. There isn't too much you can do if your CEO is Bernard Madoff. But if your company is tight on expenses and hasn't blown the budget in recent months on a hope of business eventuating then you have a tick in the good column.
I list below my 5 top tips to avoiding uncertaintly or unemployment due to the credit crisis.
1. Networking.
Many people have simply rode the good times of the last decade and have largely ignored this simple working practice. We all know the phase "It's not what you know but who you know." Check all your email addresses for old colleagues and make contact. Join professional and social networking sites like LinkedIn and put your profile on the web and reconnect to those old colleagues.
You may go as far as publish a blog. At a minimum your CV should be on your regional major recruitment portal. Employment is changing. People are now being headhunted via these sites and in these times they (recruiters and employers) will perform the data mining rather than incur the costs to advertise. You may be the dream candidate but if the job is not advertised then you will not hear about it.
Subscribe to news feeds for your technologies and industry and get reading. Join forums and post questions and replies therefore becoming known as a regular and reliable contributor.
2. Review and update your CV.
Even if you feel you have the most resilient of employer and the most solid of job prospects at your firm, you should always from time to time review the CV. That technology buzzword from 2005 may not cut it when there are 50 candidates for a job, the search spiders may know it as something different in 2008. Just ask IBM and the rebranding of the AS400, System i, iSeries or Power System.
Read, read and re-read your CV. Tune it to your skills, be honest and review it candidly. Would you employ you? I see too many CV's where the presentation is poor. Spacing, order, typo's are a few of my pet hates.
So update the CV and rehearse in your mind what you would like to project at interview. If the CV doesn't say it then you are unlikely to be be given the opportunity to do so either.
Do not wait until you need your CV. It takes a week or two to polish a decent CV and in a competitive environment like redundancy when many people or made available that next job could be gone before you hit the spell checker toolbar button.
3. Perform a skills review and add breadth to your skill set.
If you are a one trick pony. Learn another one quick. Unless of course you are best of breed then you might be OK. As a developer you are used to change and learning on the job. Make 2009 the year where you spend less time on the golf course and more on training courses and home learning. Understand what is coming in your area and ensure you know it well.
Challenge your employer for a training course. If they refuse? What does this say.......
4. Talk to your boss.
Put simply. Don't panic too much if your company is pretty safe. After all some firms have business models that thrive in these uncertain times. But there is nothing stopping you asking the hard and direct questions of your boss. Any quality manager will already understand the local situation and will have a reply for you if they haven't already addressed this as part of their attrition strategy.
If you don't like what the boss says then ask the bosses boss. Get the answers you need.
5. Cut your expenditure (Work and Home).
There are many things you can do here. Take sandwiches to work. Car pool to work. Reduce mobile phone expenses. Go to the gym instead of the pub to name a few.
All of these will boost your savings a little just in case you are cut. This will increase the amount of time you have a make an informed next career choice rather than a hasty decision and a blot on the CV.
As a Plex/2e developer you are probably slightly more shielded than others. After all, you are not ten a penny people. That niche skillset could help out quite nicely.
So look out for the signs.
Good Luck.
Thanks for reading.
Lee.
Subscribe to:
Posts (Atom)