Home > Archive > Cobol > March 2008 > [OT] Business Requirements Analysis... Sort Of
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[OT] Business Requirements Analysis... Sort Of
|
|
|
|
So... yesterday I get an e-mail of a forward to a response to a forward of
a reply to a forward of an FYI to a forward of... etc, going back about
two months... with the question of 'Can you do something about this?'
My response is 'I'm not sure what is wanted. If someone can tell me,
clearly and unambiguously:
1) Selection criteria - out of (n) employees we need to look at the ones
which have (condition or (combination of conditions))
2) Output requirements - for the employees whose data satisfy 1) above we
need to see (fields)
3) Date span - we need this information for (start period - end period)
.... then I should be able to tell you if this is something I can put
together quickly or if it will take a while longer.'
The response was surprisingly to-the-point, given the organisation...
along the lines of 'For all the employees of the Midwestern Division
who qualify for Unsupported Dementia Leave that left the organisation and
received Miscellaneous Graft and Corruption payouts from October 2006 to
the present we want to see name, separation date, amounts paid out and
(some other stuff)'.
And so... I've sent off my response. What follows are some almost
verbatim quotes:
(note - this is a shop that runs on files, not on a database)
1) Employees of the Midwestern Division - what value(s) in which field(s)
in what file(s) indicate an employee of the Midwestern Division?
2) Employes of the Midwestern Division who qualify for Unsupported
Dementia Leave - given 1) above, what value(s) in which field(s) etc.?
3) Employes of the Midwestern Division who qualify for Unsupported
Dementia Leave that left the organisation - given 1) and 2) above, what
value(s) in which field(s) etc... you might begin to sense a pattern here.
.... and the final sentences were:
If all the data you request can be found in a single file (e.g., the
Paymaster) then this will be a moderately cumbersome task.
If multiple files need to be matched and merged for only single pay
periods this will be a cumbersome and time-consuming task.
If multiple files need to be matched and merged for multiple pay periods
then this will be a cumbersome, time-consuming and unwieldy task.
.... and the response will not be, I believe... a pleasant thing to see.
DD
| |
| Pete Dashwood 2008-03-19, 6:55 pm |
|
<docdwarf@panix.com> wrote in message news:frr1an$ok8$1@reader2.panix.com...
>
> So... yesterday I get an e-mail of a forward to a response to a forward of
> a reply to a forward of an FYI to a forward of... etc, going back about
> two months... with the question of 'Can you do something about this?'
>
> My response is 'I'm not sure what is wanted. If someone can tell me,
> clearly and unambiguously:
>
> 1) Selection criteria - out of (n) employees we need to look at the ones
> which have (condition or (combination of conditions))
>
> 2) Output requirements - for the employees whose data satisfy 1) above we
> need to see (fields)
>
> 3) Date span - we need this information for (start period - end period)
>
> ... then I should be able to tell you if this is something I can put
> together quickly or if it will take a while longer.'
>
> The response was surprisingly to-the-point, given the organisation...
> along the lines of 'For all the employees of the Midwestern Division
> who qualify for Unsupported Dementia Leave that left the organisation and
> received Miscellaneous Graft and Corruption payouts from October 2006 to
> the present we want to see name, separation date, amounts paid out and
> (some other stuff)'.
>
> And so... I've sent off my response. What follows are some almost
> verbatim quotes:
>
> (note - this is a shop that runs on files, not on a database)
>
> 1) Employees of the Midwestern Division - what value(s) in which field(s)
> in what file(s) indicate an employee of the Midwestern Division?
>
> 2) Employes of the Midwestern Division who qualify for Unsupported
> Dementia Leave - given 1) above, what value(s) in which field(s) etc.?
>
> 3) Employes of the Midwestern Division who qualify for Unsupported
> Dementia Leave that left the organisation - given 1) and 2) above, what
> value(s) in which field(s) etc... you might begin to sense a pattern here.
>
> ... and the final sentences were:
>
> If all the data you request can be found in a single file (e.g., the
> Paymaster) then this will be a moderately cumbersome task.
>
> If multiple files need to be matched and merged for only single pay
> periods this will be a cumbersome and time-consuming task.
>
> If multiple files need to be matched and merged for multiple pay periods
> then this will be a cumbersome, time-consuming and unwieldy task.
>
> ... and the response will not be, I believe... a pleasant thing to see.
>
LOL!
I guess you have to give them credit for an interesting turn of phrase...
:-)
I'd translate this as:
"You're not expecting us to actually KNOW or UNDERSTAND what's in our data
are you? Do you have any idea how tiresome it is for us to have to respond
to requests like this? Good grief!... someone may actually have to find out
where data is stored and put together an Easytrieve or something... We don't
come here to work, you know, and being asked to do something that might
actually result in work is simply unreasonable. We don't know which fields
are the ones you need, we don't know where they are stored, and if it turns
out to be across several files there might actually be a few hours work
involved for somebody...even if it's all on ONE file there is still work
involved. You don't REALLY want to do this, do you?"
Must be fun to work in such an organization.
Pete.
--
"I used to write COBOL...now I can do anything."
> DD
>
| |
| Robert 2008-03-19, 9:55 pm |
| On Wed, 19 Mar 2008 12:35:35 +0000 (UTC), docdwarf@panix.com () wrote:
>
>So... yesterday I get an e-mail of a forward to a response to a forward of
>a reply to a forward of an FYI to a forward of... etc, going back about
>two months... with the question of 'Can you do something about this?'
>
>My response is 'I'm not sure what is wanted. If someone can tell me,
>clearly and unambiguously:
>
>1) Selection criteria - out of (n) employees we need to look at the ones
>which have (condition or (combination of conditions))
>
>2) Output requirements - for the employees whose data satisfy 1) above we
>need to see (fields)
>
>3) Date span - we need this information for (start period - end period)
>
>... then I should be able to tell you if this is something I can put
>together quickly or if it will take a while longer.'
>
>The response was surprisingly to-the-point, given the organisation...
>along the lines of 'For all the employees of the Midwestern Division
>who qualify for Unsupported Dementia Leave that left the organisation and
>received Miscellaneous Graft and Corruption payouts from October 2006 to
>the present we want to see name, separation date, amounts paid out and
>(some other stuff)'.
>
>And so... I've sent off my response. What follows are some almost
>verbatim quotes:
>
>(note - this is a shop that runs on files, not on a database)
>
>1) Employees of the Midwestern Division - what value(s) in which field(s)
>in what file(s) indicate an employee of the Midwestern Division?
>
>2) Employes of the Midwestern Division who qualify for Unsupported
>Dementia Leave - given 1) above, what value(s) in which field(s) etc.?
>
>3) Employes of the Midwestern Division who qualify for Unsupported
>Dementia Leave that left the organisation - given 1) and 2) above, what
>value(s) in which field(s) etc... you might begin to sense a pattern here.
>
>... and the final sentences were:
>
>If all the data you request can be found in a single file (e.g., the
>Paymaster) then this will be a moderately cumbersome task.
>
>If multiple files need to be matched and merged for only single pay
>periods this will be a cumbersome and time-consuming task.
>
>If multiple files need to be matched and merged for multiple pay periods
>then this will be a cumbersome, time-consuming and unwieldy task.
>
>... and the response will not be, I believe... a pleasant thing to see.
select name, separation_date, dirty_money
from employees emp,
(select employee, sum(amount_paid) as dirty_money
from payroll_detail pd
where debit_account = '6969'
and payment_date between to_date(20051001) and sysdate
group by employee
having dirty_money > 0) crook
where crook.employee = emp.employee
and emp.separation_date is not null
and emp.division in
(select division from divisions where division_name like 'Midwest%')
and emp.start_date >
(select min(start_date) from employees where name like '%Dwarf%')
-- Query preparation time: 5 minutes
| |
|
| In article <64dd2dF2att2eU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:frr1an$ok8$1@reader2.panix.com...
[snip]
>
>LOL!
>
>I guess you have to give them credit for an interesting turn of phrase...
>:-)
>
>I'd translate this as:
>
>"You're not expecting us to actually KNOW or UNDERSTAND what's in our data
>are you?
Mr Dashwood, quite the opposite... I'm using 'our' and 'we' to include the
user, not exclude. We're all in this together, remember?
>Good grief!... someone may actually have to find out
>where data is stored and put together an Easytrieve or something...
Actually, Mr Dashwood, it is worse than that. In one file there can be a
field called CODE-A which contains the same data which are in another file
named CODE-B... almost. The first file uses a structure like:
01 INDICATOR-CODE.
05 CODE-A PIC X(5)
05 SUBSECTION-CODE PIC X(5).
.... while the second file contains
01 INDICATOR-CODE.
05 SUPERSECTION-CODE PIC X(5).
05 CODE-B PIC X(5).
.... and this, of course, is not documented because it had to be done Just
That Once... and when a user asks for CODE-A broken out by SUPERSECTION an
unwary programmer can spend days working out slicing, dicing, mixing and
matching until A Greybeard says 'Oh... in those two files CODE-A and
CODE-B are always the same, you need only to work with the second file'.
'Finding out where the data are stored' can equate to 'having seven-to-ten
years' worth of experience on that given subsystem'... a bit long to wait
to satisfy a user request, even by Glass House High Priest standards.
>We don't
>come here to work, you know, and being asked to do something that might
>actually result in work is simply unreasonable.
I cannot speak for a 'we'... but yes, I come there to do *my* job and, as
mentioned in another posting, walk the fine line between Getting The Job
Done and Not Doing Someone Else's Job.
>We don't know which fields
>are the ones you need, we don't know where they are stored, and if it turns
>out to be across several files there might actually be a few hours work
>involved for somebody...even if it's all on ONE file there is still work
>involved.
Mr Dashwood, there's the rub... it could not be in 'one file', since data
are stored in separate files for each pay-period... and HMIGRATEd off-line
after a few w s... oh, and the naming conventions aren't constant across
pay periods, either; some pay periods can contain two files (the A1 and
the B1) or just one file (the A1). Finding out what files there are,
HRECALLing them, setting up JCL during the HRECALL to deal with a
forty-or-so dataset concatenation... never mind coding the actual program
or SORT to deal with it... gets a bit... cumbersome, as noted above.
>You don't REALLY want to do this, do you?"
No, Mr Dashwood. Presenting the plain and unvarnished facts of the case,
that it might, possibly, be more than a simple pass through a dataset and
format and done... that it might involve a bit more work and analysis than
a mere 'lemme see'... is not, in my book, discouragement; it is making the
user a partner in the task.
>
>Must be fun to work in such an organization.
As with any place else... sometimes I find that it is, sometimes I find
that it isn't. It is called 'work', not 'play'... although when it
happens that I have fun others say my work is better. Strange how that
works, eh?
DD
| |
|
| In article <s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@4ax.com>,
Robert <no@e.mail> wrote:
>On Wed, 19 Mar 2008 12:35:35 +0000 (UTC), docdwarf@panix.com () wrote:
[snip]
[snip]
[color=darkred]
>select name, separation_date, dirty_money
> from employees emp,
> (select employee, sum(amount_paid) as dirty_money
> from payroll_detail pd
> where debit_account = '6969'
> and payment_date between to_date(20051001) and sysdate
> group by employee
> having dirty_money > 0) crook
> where crook.employee = emp.employee
> and emp.separation_date is not null
> and emp.division in
> (select division from divisions where division_name like 'Midwest%')
> and emp.start_date >
> (select min(start_date) from employees where name like '%Dwarf%')
>
>-- Query preparation time: 5 minutes
Amount of time spent carefully reading what preceded query preparation
time: not enough to catch a clear and unambiguous note.
DD
| |
| Pete Dashwood 2008-03-19, 9:55 pm |
|
"Robert" <no@e.mail> wrote in message
news:s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@
4ax.com...
> On Wed, 19 Mar 2008 12:35:35 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
> select name, separation_date, dirty_money
> from employees emp,
> (select employee, sum(amount_paid) as dirty_money
> from payroll_detail pd
> where debit_account = '6969'
> and payment_date between to_date(20051001) and sysdate
> group by employee
> having dirty_money > 0) crook
> where crook.employee = emp.employee
> and emp.separation_date is not null
> and emp.division in
> (select division from divisions where division_name like
> 'Midwest%')
> and emp.start_date >
> (select min(start_date) from employees where name like '%Dwarf%')
>
> -- Query preparation time: 5 minutes
<Applause> Nice solution, Robert. Now spend another five minutes reading the
statement of the problem, which explains why the above is useless... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2008-03-20, 3:55 am |
| On Thu, 20 Mar 2008 01:01:37 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@4ax.com>,
>Robert <no@e.mail> wrote:
>
>[snip]
>
>
>[snip]
>
>
>Amount of time spent carefully reading what preceded query preparation
>time: not enough to catch a clear and unambiguous note.
All ya gotta do is write a schema defining the flat files and define it as an ODBC data
source. If there are multiple files, concatenate them with copy command, in JCL, or write
a view containing a UNION.
| |
|
| In article <qtt3u35t5f16ej8v6loh3pfnf3v5d3f392@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 20 Mar 2008 01:01:37 +0000 (UTC), docdwarf@panix.com () wrote:
>
>'Midwest%')
>
>All ya gotta do is write a schema defining the flat files and define it
>as an ODBC data
>source. If there are multiple files, concatenate them with copy command,
>in JCL, or write
>a view containing a UNION.
That's just the kind of response I'd expect from a Manager, Mr Wagner...
are you considering a career-change?
(actually... I found out Just The Other Day that they *do* have a 'Reports
Group' just for situations like this and the Reports Group does...
something-or-other with an Oracle loading of the files I interrogate with
COBOL and DFSort.
My tech lead said that the users have expressed a preference for putting
these requests into my hands... because I seem to Get More Done. Go
figure, eh?)
DD
| |
|
| In article <64dsgbF2asnp6U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Robert" <no@e.mail> wrote in message
> news:s6f3u3dlalc0i5g0jq4gtilg43kke5nm0o@
4ax.com...
[snip]
[color=darkred]
[snip]
[color=darkred]
>
><Applause> Nice solution, Robert. Now spend another five minutes reading the
>statement of the problem, which explains why the above is useless... :-)
It has already been said, elsewhere, something about how those with only a
hammer see all problems as nails... I recall something like this happening
a few years back, where I posted a problem and received a response of 'All
ya gotta do is issue an SQL query like...', hence my attempt to avoid such
this time by the parenthetic note above.
Shows how well *that* worked, yep.
DD
| |
| Robert 2008-03-20, 6:55 pm |
| On Thu, 20 Mar 2008 09:17:47 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <qtt3u35t5f16ej8v6loh3pfnf3v5d3f392@4ax.com>,
>Robert <no@e.mail> wrote:
>
>That's just the kind of response I'd expect from a Manager, Mr Wagner...
>are you considering a career-change?
My parents were married.
>(actually... I found out Just The Other Day that they *do* have a 'Reports
>Group' just for situations like this and the Reports Group does...
>something-or-other with an Oracle loading of the files I interrogate with
>COBOL and DFSort.
>
>My tech lead said that the users have expressed a preference for putting
>these requests into my hands... because I seem to Get More Done. Go
>figure, eh?)
Users SHOULD ask for a general purpose query screen that THEY can run without running the
bureaucratic gauntlet every time. If I were working there, I'd sell them the idea, then
write it for them.
I did that in the Good Old Days. My query program turned into DYL240, which became DYL280,
now called Quick Job.
| |
|
| In article <12s4u31plmj6csf7fgbji575cq3b3nee9t@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 20 Mar 2008 09:17:47 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>My parents were married.
Punchline #862: Your mother's husband is buried in Penobscot, Main. Your
father just landed a seven-pound trout.
>
>
>Users SHOULD ask for a general purpose query screen that THEY can run
>without running the
>bureaucratic gauntlet every time.
In my experience, Mr Wagner, people don't always do what they 'SHOULD'
(caps original).
>If I were working there, I'd sell them
>the idea, then
>write it for them.
When I started on this contract there was a fellow who expressed a similar
desire; he was told it would be better to address this after the main
project went live.
After Go Live a bunch of consultant/contractors/hired guns were given
their walking-papers... he was one of them.
DD
| |
| Robert 2008-03-20, 6:56 pm |
| On Thu, 20 Mar 2008 14:36:56 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <12s4u31plmj6csf7fgbji575cq3b3nee9t@4ax.com>,
>Robert <no@e.mail> wrote:
>
>In my experience, Mr Wagner, people don't always do what they 'SHOULD'
>(caps original).
>
>
>When I started on this contract there was a fellow who expressed a similar
>desire; he was told it would be better to address this after the main
>project went live.
>
>After Go Live a bunch of consultant/contractors/hired guns were given
>their walking-papers... he was one of them.
This illustrates why software technology in some mainframe shops has not changed in 20
years. It's not because workers are lazy or uninformed, nor because opportunities are
absent. It's because management blocks change. They do it to retain hegemony over users.
Cracks in the wall appear when users learn their counterparts can run a query in five
minutes. They learn the other company is using Agile, Java and LINQ, then tell top
management all their problems will be solved by switching to new technology. In truth,
they could get the same with old technology. The difference wasn't technology, it was IT
management's refusal to change.
Some managers welcome change. After my system went live last month, they extended me six
months to improve it. I'm now working on improvements like the above.
| |
| Clark F Morris 2008-03-20, 6:56 pm |
| On Thu, 20 Mar 2008 08:23:20 -0600, Robert <no@e.mail> wrote:
>
>I did that in the Good Old Days. My query program turned into DYL240, which became DYL280,
>now called Quick Job.
DYL260 was expanded to DYL280 by DYLAKOR which bought out by ? which
was bought out by CA. I believe it is now Vision Results. Quickjob
was another predecessor of DYL280. If the COBOL standards committee
wanted to see a good way of doing report writing they should have
looked at DYL280 which made Report Writer look dumb.
Clark Morris
| |
|
| In article <t995u3lods5e970rbvqrgnuqr0bl8ucu1i@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 20 Mar 2008 14:36:56 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>
>This illustrates why software technology in some mainframe shops has not
>changed in 20
>years. It's not because workers are lazy or uninformed, nor because
>opportunities are
>absent. It's because management blocks change. They do it to retain
>hegemony over users.
I might agree with your statements, Mr Norris... but I'd quibble with
words like 'sotfware technology', 'mainframe' and 'retain hegemony'.
Let's see... from
<http://groups.google.com/group/comp...4f?dmode=source>
--begin quoted text:
I am not sure if this is the cause or it is the difference between 'if it
ain't broke, don't fix it' and 'let's take it apart to see how it works!'
A buddy o' mine used to be Materials/Inventory Manager for a jewelery
manufacturer... he could never understand folks who considered inertia to
be valuable, in and of it'sself. After a meeting where things got a
bit... heated a VP took him aside and asked, seriously, what the problem
was... after all, in his (the VP's) department they'd been doing things
exactly the same way for the past twenty years.
'Where's your passion for work?', asked my buddy, 'Where do you strive to
do something more, where to you work to make things better?'
'You don't understand', said the VP, 'we've been doing the exact same
thing for the past twenty years.'
The VP could not understand why anyone would not see this as a Very Good
Thing.
--end quoted text
[snip]
>The difference wasn't
>technology, it was IT
>management's refusal to change.
It might have something to do with a given organisation's attitude towards
risk and reward, Mr Norris. If errors are not tolerated - remember the
buzz-word phrase a decade or so back of 'We can't afford not to get it
right the first time'? - then the surest way to keep a job is to not waste
money or time on things that might not work.
>Some managers welcome change. After my system went live last month, they
>extended me six
>months to improve it. I'm now working on improvements like the above.
I was contracted at my present site in November '03 for a project that
went live in May '05... I think I posted my Musings After Go-Live here.
There was, of course, a massive dismissing of consultants... and since
then there's been a steady leakage of personnel, folks retiring and not
getting replaced, other folks getting fed up with an eternal heaping-on of
More Responsibilities and nobody (as far as I can see) getting hired on.
Meanwhile, the customer list continues to get larger (up about 25%, we
started with about 60,000, we're now at a hair under 75,000... and just
starting go-live on a new phase to bring in another 13,000 or so).
DD
| |
| Robert 2008-03-21, 3:55 am |
| On Thu, 20 Mar 2008 23:57:39 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <t995u3lods5e970rbvqrgnuqr0bl8ucu1i@4ax.com>,
>Robert <no@e.mail> wrote:
>
>I might agree with your statements, Mr Norris... but I'd quibble with
>words like 'sotfware technology', 'mainframe' and 'retain hegemony'.
>Let's see... from
><http://groups.google.com/group/comp...4f?dmode=source>
>
>--begin quoted text:
>
>I am not sure if this is the cause or it is the difference between 'if it
>ain't broke, don't fix it' and 'let's take it apart to see how it works!'
>
>A buddy o' mine used to be Materials/Inventory Manager for a jewelery
>manufacturer... he could never understand folks who considered inertia to
>be valuable, in and of it'sself. After a meeting where things got a
>bit... heated a VP took him aside and asked, seriously, what the problem
>was... after all, in his (the VP's) department they'd been doing things
>exactly the same way for the past twenty years.
>
>'Where's your passion for work?', asked my buddy, 'Where do you strive to
>do something more, where to you work to make things better?'
>
>'You don't understand', said the VP, 'we've been doing the exact same
>thing for the past twenty years.'
>
>The VP could not understand why anyone would not see this as a Very Good
>Thing.
>
>--end quoted text
I was taught as a lad growing up on the options floor that there is a somewhat constant
ratio between risk and reward. If a hypothetical stock were flat-lined, its beta would be
zero and an option on it would return no more than a T-Bill.
In real life, I've noticed people are poor at risk assessment .. in both directions. Some
like Enron are reckless, causing catastrophic failure. Many more are overly risk-averse,
and thereby miss opportunities. They look for guarantees and investments that are a sure
thing. The insurance industry, in large part, is fueled by its customers' poor risk
assessment.
Mr. Norris lets them compensate by taking vicarious risks.
>
>It might have something to do with a given organisation's attitude towards
>risk and reward, Mr Norris. If errors are not tolerated - remember the
>buzz-word phrase a decade or so back of 'We can't afford not to get it
>right the first time'? - then the surest way to keep a job is to not waste
>money or time on things that might not work.
The surest way to lose an IT job is to use obsolete technology. It may not bite you this
decade, but it will eventually.
>
>I was contracted at my present site in November '03 for a project that
>went live in May '05... I think I posted my Musings After Go-Live here.
>There was, of course, a massive dismissing of consultants... and since
>then there's been a steady leakage of personnel, folks retiring and not
>getting replaced, other folks getting fed up with an eternal heaping-on of
>More Responsibilities and nobody (as far as I can see) getting hired on.
>Meanwhile, the customer list continues to get larger (up about 25%, we
>started with about 60,000, we're now at a hair under 75,000... and just
>starting go-live on a new phase to bring in another 13,000 or so).
I would think the risk is lack of scalability. 25% isn't much of an increase. My phase of
the current project added fourteen million active customers. My previous project for
another company added a similar number. In both cases, the company added a Big Unix box to
handle the increase.
| |
| Robert 2008-03-21, 3:55 am |
| On Thu, 20 Mar 2008 20:25:43 -0300, Clark F Morris <cfmpublic@ns.sympatico.ca> wrote:
>On Thu, 20 Mar 2008 08:23:20 -0600, Robert <no@e.mail> wrote:
>
>
>DYL260 was expanded to DYL280 by DYLAKOR which bought out by ? which
>was bought out by CA. I believe it is now Vision Results.
DYLAKOR was founded in the late 60s by Wild Bill Newcomer, who 'borrowed' my program from
Tabulating Consultants Inc (TCI). Something happened to Bill and the company was taken
over by his daughter, Carole, who sold it to Sterling in 1983. Sterling was acquired by CA
in the early 2000s.
DYL240 was a JIT compiler. It read the input script and spit machine language into memory,
then executed it. It ran very fast, usually faster than an equivalent Cobol program.
DYL260 was a complete rewrite in which they improved the language but also turned it into
an interpreter. It ran as slowly as interpreted Basic. They should have written a
compiler, as EZYTRIEVE did.
> Quickjob
>was another predecessor of DYL280.
I see CA renamed Quickjob to Vision Sixty. There is also Vision Inquiry for database
queries.
> If the COBOL standards committee
>wanted to see a good way of doing report writing they should have
>looked at DYL280 which made Report Writer look dumb.
| |
|
| In article <seg6u3heplqhmesj0bo9lrjade00te571l@4ax.com>,
Robert <no@e.mail> wrote:
>On Thu, 20 Mar 2008 23:57:39 +0000 (UTC), docdwarf@panix.com () wrote:
>
[snip - attributions appear to have gotten mangled]
[color=darkred]
>
>The surest way to lose an IT job is to use obsolete technology. It may
>not bite you this decade, but it will eventually.
It has been suggested, Mr Wagner, that a Fairly Sure Way to lose a job -
IT or otherwise - is to recommend solutions which may, in fact, work but
with which one's Corporate Superiors are unfamiliar or uncomfortable.
>
>I would think the risk is lack of scalability. 25% isn't much of an increase.
One would not know that by the Management Milestones newsletters that get
circulated... but I think it was Twain who spoke of a chicken cackling as
though she'd laid an asteroid.
>My phase of
>the current project added fourteen million active customers. My previous project for
>another company added a similar number. In both cases, the company added a Big Unix box to
>handle the increase.
I offered my skills to the Oracle side of the house at one point... and
they were accepted, too... and then it was discovered that this would be a
violation of a contract they held with the Anderoids.... errrr,
Accenture... and so, back to the Big Iron for me.
DD
| |
| Howard Brazee 2008-03-21, 6:55 pm |
| On Thu, 20 Mar 2008 18:25:23 -0600, Robert <no@e.mail> wrote:
>This illustrates why software technology in some mainframe shops has not changed in 20
>years. It's not because workers are lazy or uninformed, nor because opportunities are
>absent. It's because management blocks change. They do it to retain hegemony over users.
I suspect some do it for that reason.
But others do it because their job isn't to make sure technology is
current. Their job is to provide support for the business without
costing too much.
The CEO sees IS as a huge expense. He grudgingly allows increases in
non-revenue producing technology to provide security and to meet
government needs. But what he really cares about is stuff that gives
an obvious benefit to his bottom line.
That might be "giving salesmen an accurate inventory while in a
customer's office". But it's not "having the most current
compiler".
And the CIO needs to make the CEO happy.
| |
| Howard Brazee 2008-03-21, 6:55 pm |
| On Thu, 20 Mar 2008 23:52:28 -0600, Robert <no@e.mail> wrote:
>The surest way to lose an IT job is to use obsolete technology. It may not bite you this
>decade, but it will eventually.
I disagree. The surest way to lose an IT job is to fail to give your
employer a good return on his IT investment.
Of course one can define "obsolete technology" to fit in to this. But
that's not what most techies mean when we use this term.
| |
| Robert 2008-03-21, 6:55 pm |
| On Fri, 21 Mar 2008 09:22:20 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <seg6u3heplqhmesj0bo9lrjade00te571l@4ax.com>,
>Robert <no@e.mail> wrote:
>
>[snip - attributions appear to have gotten mangled]
>
>
>It has been suggested, Mr Wagner, that a Fairly Sure Way to lose a job -
>IT or otherwise - is to recommend solutions which may, in fact, work but
>with which one's Corporate Superiors are unfamiliar or uncomfortable.
True, when suggestions come from an employee or contractor. Suggestions carry more weight
when they come from an Outside Expert such as the author of an airline magazine article.
That's where most CEOs get ideas about computer technology.
>
>One would not know that by the Management Milestones newsletters that get
>circulated... but I think it was Twain who spoke of a chicken cackling as
>though she'd laid an asteroid.
Here we have charts proudly boasting of achievements such as five minute average query
response and monthly crashes reduced from 100 to 90.
>
>I offered my skills to the Oracle side of the house at one point... and
>they were accepted, too... and then it was discovered that this would be a
>violation of a contract they held with the Anderoids.... errrr,
>Accenture... and so, back to the Big Iron for me.
Reminds me of F-100 companies where executive decisions were made like a word association
game. I'll say a word or phrase, you tell me the first brand name that comes to mind.
Ready?
Computer: IBM
Business computer: mainframe
Database: Oracle
Network: ummm, either IBM or phone company
Secure business network: IBM
Trusted quality expert: Arthur Anderson (now Accenture)
Computer project management: Deloitte & Touche
Payroll system: Peoplesoft
They not only leased the product but also paid the maker big bucks for on-site experts.
They didn't need high-priced executives; they could have gotten the same decisions from an
average man-on-the-street.
At Sears, they wanted to go with Oracle. A VP scheduled a meeting with Larry Ellison to
sign papers. When he arrived, Larry had something more important to do. The BSD (big
swinging dick) retaliated for the snub by switching to Informix. Forget man-on-the-street,
they could have gotten the same decisions from a kindergarten kid.
| |
| Robert 2008-03-21, 6:55 pm |
| On Fri, 21 Mar 2008 07:46:05 -0600, Howard Brazee <howard@brazee.net> wrote:
>On Thu, 20 Mar 2008 18:25:23 -0600, Robert <no@e.mail> wrote:
>
>
>I suspect some do it for that reason.
>
>But others do it because their job isn't to make sure technology is
>current. Their job is to provide support for the business without
>costing too much.
Generally, newer technologies cost less.
>The CEO sees IS as a huge expense. He grudgingly allows increases in
>non-revenue producing technology to provide security and to meet
>government needs. But what he really cares about is stuff that gives
>an obvious benefit to his bottom line.
You want to be in a department the CEO regards as a revenue producer, not in one he
regards as an expense. There is a huge disconnect between funds allocation and technical
need.
For example, in vertically integrated oil companies, exploration gets all the money they
want. Ih the pharmaceutical industry, research and discount calculation get lots of money,
because the CEO thinks they are revenue producers. At the other end of the scale, customer
service is almost universally perceived to be a money sink.
As a rule of thumb, ask whether management would consider offshoring your job to India. If
the answer is yes, the CEO thinks you're an expense; if the answer is no, you're an asset.
>That might be "giving salesmen an accurate inventory while in a
>customer's office". But it's not "having the most current
>compiler".
The CEO is an expert at making high-quality widgets or marketing widgets. He or she
doesn't know how to manage a computer department. Outsourcing works because it brings in
IT professionals who allocate funds more rationally than a widget expert.
>And the CIO needs to make the CEO happy.
What REALLY makes the CEO happy is a 20-40% reduction in cost. Outsourcers can deliver
that, an ass kissing CIO cannot.
| |
| Howard Brazee 2008-03-24, 6:55 pm |
| On Fri, 21 Mar 2008 17:23:02 -0600, Robert <no@e.mail> wrote:
>
>What REALLY makes the CEO happy is a 20-40% reduction in cost. Outsourcers can deliver
>that, an ass kissing CIO cannot.
Outsourcers kiss ass as much if not more than CIOs. And the salesmen
often don't get paid based upon long term accurate projections of
costs - so they promise whatever the CEOs want.
| |
| Robert 2008-03-24, 9:57 pm |
| On Mon, 24 Mar 2008 07:40:55 -0600, Howard Brazee <howard@brazee.net> wrote:
>On Fri, 21 Mar 2008 17:23:02 -0600, Robert <no@e.mail> wrote:
>
>
>Outsourcers kiss ass as much if not more than CIOs. And the salesmen
>often don't get paid based upon long term accurate projections of
>costs - so they promise whatever the CEOs want.
On cost plus contracts they have an incentive to bid low and then run up the cost. That's
bad for the client, good for workers.
On fixed price contracts they have an incentive to bid accurately and then minimize cost
(by cutting corners, pushing for unpaid overtime, offshoring). That's good for the client,
bad for workers.
Most contract workers don't know the terms of the contract they're working under. They
should. If they ask, they're often told it's none of their business, which sounds better
than the middle manager admitting he doesn't know either. It is their business.
|
|
|
|
|