From: Anonymous on
In article <7s5m5eFc1bU1(a)mid.individual.net>,
Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>docdwarf(a)panix.com wrote:
>> In article <7s420vFav7U1(a)mid.individual.net>,
>> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>>
>> [snip]
>>
>>> The most memorable case of this in my experience was in Spain when
>>> IBM told a client that 3270 screens in conversational mode cannnot
>>> be automatically refreshed. (The client wanted a chief dealer's
>>> screen to be automatically updated when other dealers did a deal.).
>>> They were right; it says so in the manual...
>>>
>>> I provided a solution and 2 weeks later IBM were invited to a demo
>>> where screens were automatically updated without Enter needing to be
>>> pressed, exactly as the client required.
>>>
>>> The IBM guys were shocked and claimed I must have modified their
>>> software and it could no longer be supported by them.
>>
>> [snip]
>>
>>
>>
>> We have different approaches, Mr Dashwood; after hearing 'You must
>> have modified our software' my response would have been 'I have not
>> done so and I find it insulting, unprofessional and unimaginative for
>> you to blatantly misrepresent the facts demonstrated here in an
>> effort to cover your lack of knowledge by impugning, belittling and
>> attempting to dismiss my skills by asserting such a thing. I will be
>> more than willing to supply sample code as soon as your check clears
>> the bank.'
>
>Well, I DID tease them a little bit before revealing the solution. :-)

As I said, Mr Dashwood, we see it differently. As I see it you had a set
of skills and experiences which could be combined in a manner which
generated a solution which someone else - in this case IBM, an
organisation which has a rather large profit-motive - could use to make
money.

No problem there... you want to make money from my abilities, *I* want to
make money from my abilities. Works both ways, I'd say.

(Note that this is for another party involved. IBM, I believe, was not
collecting your timesheets nor paying for your invoices. If your Boss
wants to give away trade secrets then that's his concern; under most
contracts I've worked *anything* I've developed for the paying client is
the paying client's property.)

>
>My Boss was grinning ear to ear at their amazed gasps as terminals around
>the room started pinging, without anybody touching them.
>
>I didn't want to alienate them too mch because I would be moving on and the
>customer would need their support after I was gone.

If 'playing by the same set of rules as you do' is seen as 'alienating'
then a request for explanation - in as public a setting as possible - is a
reasonable attempt to clarify the groundrules from which all members of
the team are working. After all, We're All In This Together, right?

(they absolutely *hate* it when their own buzzwords are thrown back at
them, or so I've noticed)

[snip]

>And it wasn't really a lack of knowledge (they completely understood the
>solution once it was revealed); rather, a lack of imagination...

They may have had all the pieces, Mr Dashwood, but they did not know how
you managed to put them together. If OCO (Object Code Only) is good
enough for their programs them it is good enough for yours; give them the
load modules and say 'it's all in there'.

DD
From: Bill Gunshannon on
In article <hjk7i7$lb9$4(a)reader1.panix.com>,
docdwarf(a)panix.com () writes:
> In article <7s5l9hF6q8U1(a)mid.individual.net>,
> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>>Richard wrote:
>>> On Jan 25, 11:28 am, "Pete Dashwood"
>>> <dashw...(a)removethis.enternet.co.nz> wrote:
>
> [snip]
>
>>>> As the site in question doesn't HAVE grep or an equivalent facility,
>>>> for them, it is a nightmare.
>>>
>>> If it doen't have grep or equivalent then _everything_ is a nightmare.
>>
>>Perhaps...:-)
>>
>>You'd be amazed the number of sites that actually function without tools a
>>"good" site would take for granted.
>
> As recently as 1996 I had a contract in an IBM mainframe shop where
> ABEND-Aid was not available and core-dumps had to be read.

I remember clearly from my days doing COBOL in an IBM 360 environment
(actually, VM370) and reading core-dumps from an IBM was easy and
very useful. The best I ever worked with and I have worked in a
lot of different environments. I could easily take it right back to
the offending source statement.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999(a)cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
From: Howard Brazee on
On 25 Jan 2010 15:14:29 GMT, billg999(a)cs.uofs.edu (Bill Gunshannon)
wrote:

>> As recently as 1996 I had a contract in an IBM mainframe shop where
>> ABEND-Aid was not available and core-dumps had to be read.
>
>I remember clearly from my days doing COBOL in an IBM 360 environment
>(actually, VM370) and reading core-dumps from an IBM was easy and
>very useful. The best I ever worked with and I have worked in a
>lot of different environments. I could easily take it right back to
>the offending source statement.

I remember liking having ABEND-Aid, but having everything on-line
makes core-dumps easier to use.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison
From: Michael Wojcik on
Pete Dashwood wrote:
>
> 1. Imagine you have a couple of thousand COBOL programs, all written in ANSI
> 74 procedural COBOL. Almost every one of these programs makes static calls
> to a number of subroutines (say there are around 20 of these subroutines).
>
> ...
>
> For reasons connected with a new environment, you need these routines to be
> dynamically called, but you cannot change all the calling programs. (In
> fact, the client has insisted that the calling program code must remain
> EXACTLY as it is.)
>
> Can you get to a dynamic environment WITHOUT recoding or amending the
> calling programs?

In MF COBOL, I'd just repackage the called programs as dynamic-load
modules (ie, as DLLs on Windows or CSOs on Unix). No source changes
necessary.

If source changes *were* necessary in the COBOL environment, this
would seem to be a simple matter of shimming. (Rename called program
"A" to "A-dynamic" or some such thing. Create a new "A" that does the
dynamic call to "A-dynamic". Old caller calls the new "A" shim.) Am I
missing something?

> 2. You are replacing a service routine (a called program, not in COBOL) with
> a new routine, in COBOL. ...
>
> But, p2 can vary in length (it is a record buffer). It could be defined in
> the working storage of each calling program as anything from 20 to 8000
> bytes....
>
> You might think it is pretty easy to pass a record length or some other
> clue) as another parameter. Nope. The same rules as above; you cannot
> modify the existing code, and it doesn't have a "p2-length" in its parameter
> list.
>
> Clue: You MIGHT be able to derive the p2 length from an existing
> "dictionary", accessible by your new program.
>
> Any thoughts on how the called program could be coded to accommodate these
> requirements?

There isn't enough information in the problem.

Either the length of the buffer is available out-of-band, or it isn't.
The problem says it "MIGHT" be available from a dictionary. That's not
a useful statement. It might be available from magic computer elves,
too; but either we don't have to accommodate the case where it is not
available from that source, in which case the problem is solved, or we
do, in which case we are no closer to a general solution.

In some environments the information might be available from the
environment in some fashion. We don't know if that's the case here,
since the problem doesn't specify it.

Other metadata might be available in the buffer or the other
parameters. Again, the problem doesn't specify.

In short, this second problem reduces to "datum X may not be
available; how do you acquire datum X?". Clearly underdetermined.

The phrasing of the problem does open one possibility:

> Your called routine has to update this buffer; if you set a wrong length in
> the Linkage section you will immediately crash on a storage violation as
> soon as you try to write the record back.

I'll assume any other access idiom, such as reference modification,
would be equivalent to "set a wrong length" here - that the key is an
attempt to write past the end of the record.

Then, *if* the environment provides a mechanism for detecting and
handling exception conditions at the application level, your routine
or code it invokes could probe the record to find the trap point.
Again, this is not specified in the problem, so we can't rely on this
as a general solution. But, for example:

- In Windows, use the pointer-testing routines or SEH to probe
locations in the buffer to see if they're writable

- In Unix, use a SIGSEGV handler that sets a flag to detect when a
probe fails. In some Unix implementations, you can also use the EFAULT
trick - perform I/O from and to the buffer (saving the contents first
in the latter case) against a descriptor for /dev/null, and look for
an EFAULT error return. This behavior isn't guaranteed by SUS, though.

- On the AS/400, call a subprogram that probes the buffer and handles
the appropriate message.

And so forth. It might be tempting to binary-search for the buffer
length, but given the likely overhead of a faulting miss (ie, a probe
that strikes past the end of the buffer), a linear probe from the
beginning is likely to be faster. (With more information about the
platform architecture, you might do better - for example, on a typical
paged-memory system you only need to check each page - but the problem
definition excludes that: it says any attempt to write past the end of
the buffer will fail, so this must not be a paged system. Note that
rules out Windows and Unix, so the strategies suggested for those
platforms above are irrelevant.)

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
From: Anonymous on
In article <7s5qqlF6j8U1(a)mid.individual.net>,
Bill Gunshannon <billg999(a)cs.uofs.edu> wrote:
>In article <hjk7i7$lb9$4(a)reader1.panix.com>,
> docdwarf(a)panix.com () writes:
>> In article <7s5l9hF6q8U1(a)mid.individual.net>,
>> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>>>Richard wrote:
>>>> On Jan 25, 11:28 am, "Pete Dashwood"
>>>> <dashw...(a)removethis.enternet.co.nz> wrote:
>>
>> [snip]
>>
>>>>> As the site in question doesn't HAVE grep or an equivalent facility,
>>>>> for them, it is a nightmare.
>>>>
>>>> If it doen't have grep or equivalent then _everything_ is a nightmare.
>>>
>>>Perhaps...:-)
>>>
>>>You'd be amazed the number of sites that actually function without tools a
>>>"good" site would take for granted.
>>
>> As recently as 1996 I had a contract in an IBM mainframe shop where
>> ABEND-Aid was not available and core-dumps had to be read.
>
>I remember clearly from my days doing COBOL in an IBM 360 environment
>(actually, VM370) and reading core-dumps from an IBM was easy and
>very useful. The best I ever worked with and I have worked in a
>lot of different environments. I could easily take it right back to
>the offending source statement.

You seem to be using yourself as a comparative, Mr Gunshannon, and my
Sainted Paternal Grandfather - may he sleep with the angels! - warned
against that, as mentioned recently.

The point I attempted to make was that even recently (by COBOL standards)
there were shops that did not have tools which enhanced programmer
productivity. Certainly, one of a particular set of skills would know to
check the PSW and find out where things blew up... but stuff like
ABEND-Aid and MAX and FileAid and the like were (supposedly) created to
make things easier.

I, for one, do not recall ever looking at the clock and saying 'Whoops,
10:02am... time to set everything aside, grab a cup of coffee and catch up
on the sports page'... and yet I've worked in shops where a goodly number
of folks did just that. I also find that some of my best work gets done
when I stare at a screen and say 'Oh... don't tell *me* that I can't do
that!'... then again, I try not to use myself as a comparative.

DD