Presentation Layer for RM COBOL and PowerCOBOL Migration
in [Cobol]
|
From: Pete Dashwood on 30 Jul 2010 09:35 PRIMA are currently addressing the problems of getting RM COBOL displays converted to .NET or Windows. We are also considering approaches to getting PowerCOBOL screens replaced in the same way. The RM source we have uses field-by-field processing with DISPLAY... AT LINE xx COLUMN yy and we are looking at how best to move this. One solution would be to convert groups of statements like this into a COBOL SCREEN SECTION. This would allow the GETting and PUTting of a complete screen (instead of field-by-field), and also provide separation between the presentation layer and the business logic, which would be much easier to implement for .NET. (Now all I need is some logic to convert a screen section into a .NET Form on an .aspx page... :-)) If anyone is using RM COBOL and would be interested in seeing the results of this migration, or having some of their own code processed through it, please contact me. I can do this really cheaply if we can get some more people who need it. Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 30 Jul 2010 15:22 On Jul 31, 1:35 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > PRIMA are currently addressing the problems of getting RM COBOL displays > converted to .NET or Windows. We are also considering approaches to getting > PowerCOBOL screens replaced in the same way. > > The RM source we have uses field-by-field processing with DISPLAY... AT > LINE xx COLUMN yy and we are looking at how best to move this. > > One solution would be to convert groups of statements like this into a COBOL > SCREEN SECTION. This would allow the GETting and PUTting of a complete > screen (instead of field-by-field), and also provide separation between the > presentation layer and the business logic, which would be much easier to > implement for .NET. (Now all I need is some logic to convert a screen > section into a .NET Form on an .aspx page... :-)) > > If anyone is using RM COBOL and would be interested in seeing the results of > this migration, or having some of their own code processed through it, > please contact me. I can do this really cheaply if we can get some more > people who need it. Field by field accepts usually (in my experience) have validation and processing after each field. In particular the valid entries in one field may depend on what had been determined in earlier fields. Changing to full screen accepts with screen section could produce a completely different UI. I have done conversions from field by field to Flexus SP2 and these required returning to program logic after most entry fields. This can be done in SP2 easily. Screen section can usually do this too, but it is, IMHO, a real pain to control. Converting from field by field to screen section and then to something else is just doubling the workload. Best to do a complete rewrite.
From: Pete Dashwood on 30 Jul 2010 20:38 Richard wrote: > On Jul 31, 1:35 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> PRIMA are currently addressing the problems of getting RM COBOL >> displays converted to .NET or Windows. We are also considering >> approaches to getting PowerCOBOL screens replaced in the same way. >> >> The RM source we have uses field-by-field processing with DISPLAY... >> AT LINE xx COLUMN yy and we are looking at how best to move this. >> >> One solution would be to convert groups of statements like this into >> a COBOL SCREEN SECTION. This would allow the GETting and PUTting of >> a complete screen (instead of field-by-field), and also provide >> separation between the presentation layer and the business logic, >> which would be much easier to implement for .NET. (Now all I need is >> some logic to convert a screen section into a .NET Form on an .aspx >> page... :-)) >> >> If anyone is using RM COBOL and would be interested in seeing the >> results of this migration, or having some of their own code >> processed through it, please contact me. I can do this really >> cheaply if we can get some more people who need it. > > > Field by field accepts usually (in my experience) have validation and > processing after each field. In particular the valid entries in one > field may depend on what had been determined in earlier fields. > Changing to full screen accepts with screen section could produce a > completely different UI. Yes, but it is generally a better approach :-) > > I have done conversions from field by field to Flexus SP2 and these > required returning to program logic after most entry fields. This can > be done in SP2 easily. Screen section can usually do this too, but it > is, IMHO, a real pain to control. > > Converting from field by field to screen section and then to something > else is just doubling the workload. Best to do a complete rewrite. Good points, Richard. A complete re-write is probably more than the code is worth but it has to be an option I guess. It isn't too hard to write a tool that will process the COBOL code and generate the screen section. The actual logic can probably be re-organized by another tool that detects when fields are referenced, but I agree that is a bit more difficult. I want to lever as much as I can in any tools we develop so that I can use them for PowerCOBOL as well, and that is probably colouring my judgement at the moment. Thanks for a fresh viewpoint. Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 30 Jul 2010 23:25 On Jul 31, 12:38 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Richard wrote: > > On Jul 31, 1:35 am, "Pete Dashwood" > > <dashw...(a)removethis.enternet.co.nz> wrote: > >> PRIMA are currently addressing the problems of getting RM COBOL > >> displays converted to .NET or Windows. We are also considering > >> approaches to getting PowerCOBOL screens replaced in the same way. > > >> The RM source we have uses field-by-field processing with DISPLAY... > >> AT LINE xx COLUMN yy and we are looking at how best to move this. > > >> One solution would be to convert groups of statements like this into > >> a COBOL SCREEN SECTION. This would allow the GETting and PUTting of > >> a complete screen (instead of field-by-field), and also provide > >> separation between the presentation layer and the business logic, > >> which would be much easier to implement for .NET. (Now all I need is > >> some logic to convert a screen section into a .NET Form on an .aspx > >> page... :-)) > > >> If anyone is using RM COBOL and would be interested in seeing the > >> results of this migration, or having some of their own code > >> processed through it, please contact me. I can do this really > >> cheaply if we can get some more people who need it. > > > Field by field accepts usually (in my experience) have validation and > > processing after each field. In particular the valid entries in one > > field may depend on what had been determined in earlier fields. > > Changing to full screen accepts with screen section could produce a > > completely different UI. > > Yes, but it is generally a better approach :-) Regardless of whether it is 'better' or not, it is different. If this conversion is being done for a particular company who want to 'modernise' their system then 'different' is much worse because it will mean users being retrained. > > I have done conversions from field by field to Flexus SP2 and these > > required returning to program logic after most entry fields. This can > > be done in SP2 easily. Screen section can usually do this too, but it > > is, IMHO, a real pain to control. > > > Converting from field by field to screen section and then to something > > else is just doubling the workload. Best to do a complete rewrite. > > Good points, Richard. > > A complete re-write is probably more than the code is worth but it has to be > an option I guess. > > It isn't too hard to write a tool that will process the COBOL code and > generate the screen section. The actual logic can probably be re-organized > by another tool that detects when fields are referenced, but I agree that is > a bit more difficult. You would not be able to write a tool to generate screen sections for many of my programs. Many of my programs have different screen layouts depending on several factors. Some may only be slightly different but some others create their screen layouts depending on control files or other mechanisms. But still, you won't be doing mine. You may be working with relatively simple code that could be made into screen sections. > I want to lever as much as I can in any tools we develop so that I can use > them for PowerCOBOL as well, and that is probably colouring my judgement at > the moment.
From: Pete Dashwood on 31 Jul 2010 08:25
Richard wrote: > On Jul 31, 12:38 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Richard wrote: >>> On Jul 31, 1:35 am, "Pete Dashwood" >>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>> PRIMA are currently addressing the problems of getting RM COBOL >>>> displays converted to .NET or Windows. We are also considering >>>> approaches to getting PowerCOBOL screens replaced in the same way. >> >>>> The RM source we have uses field-by-field processing with >>>> DISPLAY... AT LINE xx COLUMN yy and we are looking at how best to >>>> move this. >> >>>> One solution would be to convert groups of statements like this >>>> into a COBOL SCREEN SECTION. This would allow the GETting and >>>> PUTting of a complete screen (instead of field-by-field), and also >>>> provide separation between the presentation layer and the business >>>> logic, which would be much easier to implement for .NET. (Now all >>>> I need is some logic to convert a screen section into a .NET Form >>>> on an .aspx page... :-)) >> >>>> If anyone is using RM COBOL and would be interested in seeing the >>>> results of this migration, or having some of their own code >>>> processed through it, please contact me. I can do this really >>>> cheaply if we can get some more people who need it. >> >>> Field by field accepts usually (in my experience) have validation >>> and processing after each field. In particular the valid entries in >>> one field may depend on what had been determined in earlier fields. >>> Changing to full screen accepts with screen section could produce a >>> completely different UI. >> >> Yes, but it is generally a better approach :-) > > Regardless of whether it is 'better' or not, it is different. If this > conversion is being done for a particular company who want to > 'modernise' their system then 'different' is much worse because it > will mean users being retrained. In this particular case it won't. > >>> I have done conversions from field by field to Flexus SP2 and these >>> required returning to program logic after most entry fields. This >>> can be done in SP2 easily. Screen section can usually do this too, >>> but it is, IMHO, a real pain to control. >> >>> Converting from field by field to screen section and then to >>> something else is just doubling the workload. Best to do a complete >>> rewrite. >> >> Good points, Richard. >> >> A complete re-write is probably more than the code is worth but it >> has to be an option I guess. >> >> It isn't too hard to write a tool that will process the COBOL code >> and generate the screen section. The actual logic can probably be >> re-organized by another tool that detects when fields are >> referenced, but I agree that is a bit more difficult. > > You would not be able to write a tool to generate screen sections for > many of my programs. Be careful before saying "would not". I was told it would not be possible to write tools that can convert cobol file access to RDB, but it has been done, and to-date several thousand programs have been correctly converted by it. Nevertheless, you know your own code and I haven't seen it, so you are probably right.:-) >Many of my programs have different screen layouts > depending on several factors. Some may only be slightly different but > some others create their screen layouts depending on control files or > other mechanisms. > > But still, you won't be doing mine. You may be working with relatively > simple code that could be made into screen sections. Such is indeed the case :-) > >> I want to lever as much as I can in any tools we develop so that I >> can use them for PowerCOBOL as well, and that is probably colouring >> my judgement at the moment. -- "I used to write COBOL...now I can do anything." |