In article <64dd2dF2att2eU1@[EMAIL PROTECTED]
>,
Pete Dashwood <dashwood@[EMAIL PROTECTED]
> wrote:
>
>
><docdwarf@[EMAIL PROTECTED]
> wrote in message
news:frr1an$ok8$1@[EMAIL PROTECTED]
>> 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 Unsup****ted
>> Dementia Leave - given 1) above, what value(s) in which field(s) etc.?
>>
>> 3) Employes of the Midwestern Division who qualify for Unsup****ted
>> 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?
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 weeks... 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
|
