Cyrillic characters
in [Cobol]
|
Prev: 20 things Taft doesn't know about COBOL... WAS: 20 Things YouMight Not Know About COBOL
Next: Documenting COBOL WAS: Re: Flow chart generators
From: Anonymous on 27 Oct 2009 10:25 In article <7kn7biF3b6ubdU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >I have a client who uses it, and modifying Toolset Transformation for him >was quite an exercise... every scriptlet had to be identified and processed. >(fortunately they are tagged in the .PRC file... but there is no easy >automatic way I could find to add them back to the project once they are >modified. His people do it manually, cutting and pasting them out of the >Migration Environment and back into the PowerCOBOL project... it is very >unsatisfactory in my opinion but they don't seem to mind.) This is similar to something I ran across the other day. Awaaaaaayyyy back when (2005 or so) I wrote a utility-job using DFSORT to do something then derided as 'nice, but not needed'. A week or so back someone came to my cube... with a copy of that report in his hand. Now it was Very Useful but... he wanted a second report, Just Like the First BUT... selecting a sub-set, sorted/broken differently and certain data blacked out. While chatting with him about the request I discovered that he received the Original Report via hardcopy... AND THEN RE-TYPED CERTAIN DATA FOR CERTAIN GROUPS BY HAND INTO EMAILS TO BE SENT TO... someone in the groups to deal with it. I cringed. I had been taught, e'er-so-long ago, that 'data are to be entered once and only once' (EXCEPT for projects requiring double-entry accuracy, where one operator's keying-in was compared to a second's and discrepancies down to the typo were researched and clarified before final submission). I toyed with the idea of adding an IEBGENER step to send the output of the New Report directly to this fellow... .... and told him I could do it IF and ONLY IF he could give me not a 'named' email address (john.smith(a)anycompany.nothere. etc.) but a 'positional' email address (rejects.teamlead(a)anycompany. etc). He looked confused for a moment and I jumped in with the explanation of 'people come and go but positions remain... you could be hit by a Mac truck tomorrow but - more or less - there'll always be a team lead for this project team. *People* should not get regularly-scheduled production reports, *positions* should.' (no, this is not Standard Practise at this site... but it is a lovely idea, I'd say) DD
From: Pete Dashwood on 27 Oct 2009 20:38 docdwarf(a)panix.com wrote: > In article <7kn7biF3b6ubdU1(a)mid.individual.net>, > Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > [snip] > >> I have a client who uses it, and modifying Toolset Transformation >> for him was quite an exercise... every scriptlet had to be >> identified and processed. (fortunately they are tagged in the .PRC >> file... but there is no easy automatic way I could find to add them >> back to the project once they are modified. His people do it >> manually, cutting and pasting them out of the Migration Environment >> and back into the PowerCOBOL project... it is very unsatisfactory in >> my opinion but they don't seem to mind.) > > This is similar to something I ran across the other day. Awaaaaaayyyy > back when (2005 or so) I wrote a utility-job using DFSORT to do > something then derided as 'nice, but not needed'. The shortsightedness of non-IT people is often a cause for me grinding my teeth... I guess it is understandable. Most jobs people do, they cope with the immediate problems and that is enough. For IT people we are trying to obviate future effort at the same time as solving the current problem. I'm sure most people here have experienced the resistance when the need to capture something is not immediately obvious, but you know in your bones it will be needed further down the track, even if you can't explain immediately how and why. 'Nice, but not needed' is a phrase which most system developers and designers have come to dread... I usually combat this by saying: "maybe not needed TODAY, but if we do this now it will save a large amount of time and effort later and the effort to do it now is minimal." Quite often I lose on this one and, invariably, down the track, it becomes necessary and is a lot more trouble to retrofit than if we had done it in the first place... > > A week or so back someone came to my cube... with a copy of that > report in his hand. Now it was Very Useful but... he wanted a second > report, Just Like the First BUT... selecting a sub-set, sorted/broken > differently and certain data blacked out. > > While chatting with him about the request I discovered that he > received the Original Report via hardcopy... AND THEN RE-TYPED > CERTAIN DATA FOR CERTAIN GROUPS BY HAND INTO EMAILS TO BE SENT TO... > someone in the groups to deal with it. Aw, Man! Doesn't your heart just go out to them... :-) > > I cringed. I had been taught, e'er-so-long ago, that 'data are to be > entered once and only once' (EXCEPT for projects requiring > double-entry accuracy, where one operator's keying-in was compared to > a second's and discrepancies down to the typo were researched and > clarified before final submission). I toyed with the idea of adding > an IEBGENER step to send the output of the New Report directly to > this fellow... > > ... and told him I could do it IF and ONLY IF he could give me not a > 'named' email address (john.smith(a)anycompany.nothere. etc.) but a > 'positional' email address (rejects.teamlead(a)anycompany. etc). > > He looked confused for a moment and I jumped in with the explanation > of 'people come and go but positions remain... you could be hit by a > Mac truck tomorrow but - more or less - there'll always be a team > lead for this project team. *People* should not get > regularly-scheduled production reports, *positions* should.' > > (no, this is not Standard Practise at this site... but it is a lovely > idea, I'd say) It is a very sensible idea. Places I have worked where they do this (particularly in smaller companies) refer to them as "hat" addresses. (Somebody must wear the team leader's hat for example. Often in a small company, a single person may wear multiple hats. Probably the most common hat address is info(a)anycompany.com). Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 28 Oct 2009 10:40 In article <7kpi55F39f65cU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >docdwarf(a)panix.com wrote: [snip] >> This is similar to something I ran across the other day. Awaaaaaayyyy >> back when (2005 or so) I wrote a utility-job using DFSORT to do >> something then derided as 'nice, but not needed'. > >The shortsightedness of non-IT people is often a cause for me grinding my >teeth... I guess it is understandable. Most jobs people do, they cope with >the immediate problems and that is enough. For IT people we are trying to >obviate future effort at the same time as solving the current problem. I'm not sure what you intend by an 'IT person', Mr Dashwood, but in my experience IT folks are about the same as any others: one in ten has 'The Touch' and the other nine are just kind of getting along, praying that they don't get found out. >I'm >sure most people here have experienced the resistance when the need to >capture something is not immediately obvious, but you know in your bones it >will be needed further down the track, even if you can't explain immediately >how and why. In the case at hand it was not even 'the back of my neck told me'. Consider: a bunch o' data comes in from Source A. Another bunch o' data that's supposed to match the first, more-or-less, comes in from Source B. The two bunches o' data are to be sliced, diced, chopped, prettily decorated with herbs (this is a Financial System so I avoided use of 'garnished') and sent back to Source A for further processing. Two sets of data from two sources in a Financial System which are supposed to match... wouldn't it be nice to see all from A that aren't on B and vice-versa? I've seen/done that at so many other places o'er the decades that doing it for my current client was in-my-sleep stuff. > >'Nice, but not needed' is a phrase which most system developers and >designers have come to dread... I usually combat this by saying: "maybe not >needed TODAY, but if we do this now it will save a large amount of time and >effort later and the effort to do it now is minimal." Quite often I lose on >this one and, invariably, down the track, it becomes necessary and is a lot >more trouble to retrofit than if we had done it in the first place... I liken this to a non-IT discipline with which more folks might be familiar: 'It is easier to put in the bathrooms when you are building the house than it is to put them in after you've taken residence.' (there was a six-P alliteration I was taught that began 'Prior Planning Prevents...') When such things arise in COBOL programs I've picked up the habit of coding for them... and then placing a 'D' in column 7 and including *SOURCE-COMPUTER. IBM-3090 WITH DEBUGGING MODE. SOURCE-COMPUTER. IBM-3090. .... where it should be. In this case it was a DFSORT job which I kind of slipped into the Production stream... didn't cost much to run, nobody noticed the extra stack of paper except for Ops. I was later notified 'in the hallway' that the 'nice, but not needed' person moved into a different job-position her replacement almost immediately asked if such a thing could be done. [snip] >> While chatting with him about the request I discovered that he >> received the Original Report via hardcopy... AND THEN RE-TYPED >> CERTAIN DATA FOR CERTAIN GROUPS BY HAND INTO EMAILS TO BE SENT TO... >> someone in the groups to deal with it. > >Aw, Man! Doesn't your heart just go out to them... :-) Not really... but that may be a sign that I am not easily moved by folks who court keying-errors so freely. They seem not to know that the keypunch-girls are very busy and that costs are so high I'm allowed only two compiles per day (three if I can come in at night and hang out with the Ops crew)... and don't get me started on what they're callin' 'music', neither... buncha durned *noise*, 'f'ya ask me. [snip] >> He looked confused for a moment and I jumped in with the explanation >> of 'people come and go but positions remain... you could be hit by a >> Mac truck tomorrow but - more or less - there'll always be a team >> lead for this project team. *People* should not get >> regularly-scheduled production reports, *positions* should.' >> >> (no, this is not Standard Practise at this site... but it is a lovely >> idea, I'd say) > >It is a very sensible idea. Places I have worked where they do this >(particularly in smaller companies) refer to them as "hat" addresses. A lovely bit of terminology and one that I might appropriate in future; since you source the quote imprecisely ('(p)laces I have worked where they do this') I will follow suit and say 'At some places these are called 'hat' addresses (etc)'). DD
From: HeyBub on 28 Oct 2009 12:31
Pete Dashwood wrote: > > Your Eastern European clients are running Windows, or will it be a > virtual Windows environment? (I heard that Eastern Europe is very > fond of Linux... ) > Real Windows. There are, I think, two reasons: 1. Linux is much like the Celtic warriors hired by English kings of old as mercenary warriors: They did a few things and did them well, there were (relatively) cheap, and they were completely incomprehensible. You just didn't want them, you know, to actually RUN things. 2. The difference in price between Windows and Linux in Central Asia (not Eastern Europe) is nil. |