Prev: contract jobs in australia
Next: Visual Object Cobol
From: razor on 1 Jan 2010 18:59
Which is exactly what happened.
From: razor on 1 Jan 2010 19:14
>
> If it were just a requirement to print then I would probably bypass
> all the use of a GUI and implement a simple program to collect email
> (sent to a specific address) and extract the attachment and print it
> without any user action.

They may wish to have that control. Unfortunately, its not for me to
say what their requirements are other than to say 'they want to know
what the orders are'. One can get bogged down asking 'do you wish to
view or print them?'. I find one has to let people a bit lower down ,
no, closer to it decide these things. Then they tell me what they
want.

Very often they (my customer) don't know what they want until what
they receive is 'not suitable'. But then thats always been IT. The
times I've heard IT people complaining when the customer changes their
mind or has misunderstood something when we get half way through a
project. Thats what we are supposed to be able to deal with. It 'may'
cost them more money. There have been times when I've changed things
myself just because as things progress it becomes 'obvious'. Therein
lies our skill in deciding this 'obvious'. This is what pays my bills.

>
> But then I have these sort of things already automated, such as
> collecting emails with .xls attachments and processing these in
> various ways.

Sounds great. I'm quite sure I would have loved some time to play with
such things in the past.

Then again, now I re-read, maybe you misunderstood me. The sending of
the emails with attachments is fully automated. Nobody has to do
anything except press the button. And that bit is the way I have
designed it to be.
From: razor on 1 Jan 2010 19:47
> Having sat in similar meetings, I sympathize. Pricing plans are always
> "tricky" and I remember one U.K. company wehre they believed it could never
> be effectively computerized because of all the exceptions and Sales based
> spur-of-the-moment overrides.(They were wrong; it WAS computerized and
> theSales people could still override it...)
>

This is similar to the problem I had. They have 500,000 pricing
exceptions held as customer X pays £1 for product Y. Standard sort of
stuff, built up over a great period of time. Now the customer sees
that using the package they can classify the products and customers
and a matrix can hold the prices that each customer pays. The fact
that the existing system can do this and more is lost on them. After
all, they're spending a lot of money and it needs justifying.

The answer to this is (they thought) to split these 500,000 prices
into Excel spreadsheets for the 22 account managers, send them out for
these managers to 'review' and send back. What for? Do the
calculations. A literally physical impossibility if they devote 60
seconds to each price, considering, looking up in a paper table then
guess what. 'Advise us of a new price' was the advice.

Oh, by the way on the day we were to go live, no customers prices were
to change. I fully understand the problem here which is to remove the
maintenance nightmare. But thats a business issue and not an issue of
any specific computer system.

What I wanted to do was get them to classify all customers (or I could
have done it for them by turnover/profitability even by product sub
sector) and convert all prices to 'differences' to where they 'should'
be in the matrix. Thereby removing the need to ever go in and maintain
these items ever again. Silence.

> Very often, especially with people whoare flogging a package, they turn off
> when a processing difficulty is being outlined. The theory is that they
> don't have to worry about it because the company has already bought the
> package and they can "scrub round it" or put something together to dealwith
> it at a later time.

I agree. I could see their faces glaze over when shown something
'differen' to how the package works.

> I DO charge a four figure daily sum and often it is helpful, not just
> because it improves the quality of my life :-), but because it actually
> confers "credibility". Senior Managers tend to listen to someone who they
> are paying large amounts of money for. I have even had cases where I
> independently investigated something, and came up with exactly the same
> conclusions and solution as their own people had already done some time
> before. It was unacceptable when their own people proposed it because it was
> "difficult", but they were prepared to finance and back it when I proposed
> it, because they then had someone they could hang it on if it went pear
> shaped. Part of my recommendation was that they should work to build better
> trust with their people and start taking some responsibility for
> leadership...

I hope you understood that I was being sarcastic about the four figure
sum. A scouse accent doesn't help either when you are dealing with
bigoted people. There are more complicated reasons why I was not 'in
the loop' (I know too much).



>
> Remember that all you have in this life is what's in your head. You spent
> years acquiring and honing it, why undervalue it? Information has value,
> knowledge and expertise have value, an impeccable track record has value
> (although I've never really understood that one...it seems to me that (just
> like stock market investment) past performance is no guarantee of future
> return...I treat every project as if it were the first, and recognise that I
> REALLY don't want a failure to start the ball rolling...).
>
> The nature of consultancy is that you will not be there for a long period of
> time. (This is different from "contract programming" where the idea is to
> extend your stay by whatever means are possible...:-)). It is therefore fair
> and reasonable, that you should charge a higher rate. If they baulk, point
> out that it is still way less than IBM or Microsoft charge for on-site
> consultancy and support. (If you have either or both of these on your CV it
> tends to cut some ice. You also have to be prepared to carry the can for the
> project and should have professional indemnity insurance to cover this.
> (Don't do like I once did, and put your house on the line if the delivery
> date is not met...:-) I still have my house and enjoy living in it, but it
> could have been very different if a loyal team hadn't baled me out at the
> 11th hour...)

Been doing the same one for 18 years.

> Here's a thought.
>
> Formulate a document putting your concerns in writing with suggestions as to
> what is needed to fix things. (A White Paper?). Circulate all the
> consultants and the Business and COPY their bosses. (Don't make it too
> technical... managers have limited attention spans, but it doesn't need to
> be in non-joined up writing with a crayon, either.  Think about what is
> wrong, think about how it could be fixed and state that as simply and
> directly as possible (You don't have to give them full details of a
> solution; suggest an approach and let them buy the details from you). (From
> your writing here I can see you don't have a problem expressing yourself.)

Its not in anybodies interests to listen. Everybody has already bought
into the new system. It will come, sooner or later. Although I have
tried in the past, I may give it another shot.

> If anyone jumps on you for doing it (and COIs - sorry, Doc's terminology -
> "Corner Office Idiots" - and Consultants are often insecure and easily
> threatened by intelligent action...) simply say:" I copied all parties. My
> action was up front and not deceitful. I tried to explain it in the meeting
> but no-one wanted to listen. What recourse did I have? Now, at least people
> are talking about it."

Interesting and all sounds so simple. Not all situations are the same
though and mine does not allow me to do this.

Cheers

Razor
From: Richard on 1 Jan 2010 20:21
On Dec 31 2009, 11:53 pm, singa <viasilvat...(a)gmail.com> wrote:
> Hy Guys,
> i am experiencing with cobol (RmCobol85) since 1984,
> all of my reports (from *nix servers) are going to
> users or external customers (b.e. invoices) sending
> text output from Cobol to email thru a simple PDF
> wrapper
>
> In other word the output of cobol ASSING TO PRINT
> goes to a pipe, here i have the PDF wrapper, PDF
> output file goes to email
>
> At the top of the print output, for each page, i put
> the destination email address , if omitted is the
> currently logged in user
>
> For each Form Feed the wrapper close the current PDF
> and will open the next one.
>
> The PDF wrapper could be a simple PHP script, or some
> similar (i am not confident with Php, so i have a C program,
> built with lex and Clib)
>
> In this way the attachment is a pure PDF file, with
> all the advantages (archiving, printing. virus scan,
> portability, ...)
>
> Plus: using PDF is possible to draw box, circle, barcodes, ....
>
> If someone is interested i can send them some samples
> of output and more details
>
> Sorry but my English is very bad, and all my software and
> manualals are in Italian

I do PDF output as well, but I use a postscript template. I draw these
using tgif, a Unix/Linux drawing program. For the text fields where
text is to be merged in I put text tags, eg <!%tagname%>, multiple or
repeating items are added using <!> on the start of each new line
within the text field. Setting of graphics, fonts, images, is all done
in the template. tgif will output a postscript file and this is used
by the merge program to produce output postscript which can go
directly to printer or via ps2pdf to create a PDF to be emailed.

By using a template the program doesn't have to care what the result
looks like, it could just as well be HTML, XML, CSV or plain text. It
is also very easy to have several different templates, for different
companies or different branches and swap these around as required.
From: Alistair on 2 Jan 2010 12:06
On Jan 1, 2:16 am, "Pete Dashwood"
<dashw...(a)removethis.enternet.co.nz> wrote:
> Alistair wrote:
>
> > If you really want a challenge  [   ;-P   ], try convincing Pete
> > Dashwood that Cobol is not dead and that both India and China are
> > training university graduates to code in Cobol.
>
> It was I who pointed that out some time back, Alistair. Do try and keep up.
> You should also note that they are learning COBOL as part of the "History of
> Computing", and not with the idea of making a living from it.
>
>
> And I never said "COBOL is dead". I said it will be by 2015 as a development
> language of choice. (That is pretty much already true... so I see no reason
> to modify or withdraw that statement). The procedural paradigm is definitely
> dead as a model for future development, and standard COBOL implements
> that.paradigm. (OO COBOL has a longer life expectancy as a useful tool for
> migration of legacy, but few people will continue development in COBOL (even
> OO COBOL) once they have migrated to more modern platforms.)
>

I could have sworn that you were announcing the death of Cobol (as per
the announcement that the Nazi party was dead) but, using DD's new-
fangled 'net, the best I can find is that you have consistently stated
2015 as the move-on-by-date and have only heralded the imminent death
of the language. I was wrong. Sorry (for causing you offense).
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: contract jobs in australia
Next: Visual Object Cobol