Home > Archive > Cobol > January 2007 > Productivity
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]
|
|
| Pete Dashwood 2006-12-22, 6:55 pm |
| I've been doing a lot of thinking about productivity lately. (Of course
thinking about something doesn't necessarily make you more productive, but
you hope that it improves the quality of the end product.)
Just as an exercise and without any particular bias, I recently finished
rewriting a COBOL application that originally took six w s to develop.
(This includes design, writing, testing/debugging). The design took around 4
days, say, take a w off for design, and it took 5 ws to develop.
It was rewritten in C# and DotNET in 5 days.
Given that I am a newbie in C#, but am no slouch when it comes to COBOL, I
was at a loss to explain this.
1. Having developed it once, it is true that I now understand the whole
thing a lot better.
2. Part of the 5 days for the C# development was spent doing video tutorials
on C#.
3. Some of the things that took a fair bit of effort in OO COBOL were easy
in DotNET.
But despite all of that, it is quite obvious that my productivity in Visual
Studio 2005 is MUCH better than my productivity using the Fujitsu IDE.
This made me think about tools.
VS 2005 provides an Interactive Development Environment that is simply years
ahead of any other development environment I have ever worked in (on both
mainframes and PCs).
Colour coding of code, rollaway windows that you can pin down when you want
them or send to a tab when you don't, intuitive context sensitive tooltips,
having all your defined variables available for selection at the moment you
want to reference them, having all methods, events and properties for the
object you are referencing available as you type, along with help tooltips
for any you select, ...all of these things collectively add up to MAJOR
productivity improvements. There's no flipping through a listing (or opening
other windows on the data division) to check variable names. No wondering or
having to check parameter lists to methods. No syntax errors; you simply
can't make them. No spelling errors...(Keywords are inserted for you and
variables are selected from lists as you begin typing the name). You can
view or hide any section of code at any time. Online contextual help is
instantly available for any method you want to use. If you don't know what
methods are available (always part of the problem when you start learning
something), they are organised by type so you can browse them instantly.
But.most importantly of all, the environment is NOT focused on code
development. It is pure event driven programming. You DON'T start by writing
IDENTIFICATION DIVISION (or its equivalent). You design what you want and
the code for the events is placed into the right contexts for you. All of
the housekeeping, fixed context, and overhead is hidden (unless you WANT to
see it). You focus totally on your application and what you want to happen
when events occur in it.
I find myself wondering how much quicker I could have built COBOL apps if I
had had this kind of development environment.
I understand that Fujitsu DotNET COBOL comes with this environment. It costs
several thousand dollars (if you can get them to sell it to you...I
couldn't).
Visual C# Express comes with the same environment and is a FREE download.
(This has been so for nearly two years now. I wouldn't be surprised if they
stop it soon...) MicroSoft WANT you to use their products. They are
confident (and with good reason) that, once you experience this environment,
you will want to upgrade to Enterprise version and support multiple teams
all working in it. (The enterprise version also supports source control).
There are over 400 FREE video tutorials on C# available on the web,
thousands of code snippets and samples, and a positive and upbeat user
community which is growing daily.
(What am I doing here... :-))
After a couple of months evaluating alternatives to COBOL, I am satisfied
that C# and Java between them have everything I need. Visual Studio is
simply the icing on the cake. I don't need to write off my existing
investment in COBOL, as DotNET runs my existing COBOL components as
unmanaged code. (This will do until I need to replace them, if I need to
replace them.) I have been finding ways to minimize COBOL maintenance for
some years now, and components achieve this. I simply use C# as the glue to
hold them together.
So, it looks like I will be winding down my COBOL development.
The tools for cutting edge development are MUCH better and cheaper than
COBOL. It remains useful for batch development, which is what it was
invented for, and where we came in...
Forty years of writing it.
Guess it's time for a change... :-)
Pete.
| |
| HeyBub 2006-12-22, 6:55 pm |
| Pete Dashwood wrote:
>
> Guess it's time for a change... :-)
>
> Pete.
Don't jump to conclusions. It has been my experience that luck has a lot to
do with program development - maybe more than anything else.
How many times have you said to yourself: "I'll be damned. It worked the
first time!" And how many times have you just never been able to get the
sucker to function at all?
Same tools, experience, money, etc. The only difference is providence.
Maybe you just got lucky.
| |
| William M. Klein 2006-12-22, 9:55 pm |
| FYI,
The current Micro Focus product for .NET development comes with both the
"traditional" (GUI) MF IDE *and* VisualStudio 2005 development. It is up to the
programmer which is "most" convenient for them. (I tend to run "simple"
ANSI/ISO conforming NON-OO, non-dotNET programs, so the old IDE works fine for
me. If I were developing "real" Windows applications, I suspect, that I would
switch over.
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4v33ipF1a006cU1@mid.individual.net...
> I've been doing a lot of thinking about productivity lately. (Of course
> thinking about something doesn't necessarily make you more productive, but you
> hope that it improves the quality of the end product.)
>
> Just as an exercise and without any particular bias, I recently finished
> rewriting a COBOL application that originally took six ws to develop. (This
> includes design, writing, testing/debugging). The design took around 4 days,
> say, take a w off for design, and it took 5 ws to develop.
>
> It was rewritten in C# and DotNET in 5 days.
>
> Given that I am a newbie in C#, but am no slouch when it comes to COBOL, I was
> at a loss to explain this.
>
> 1. Having developed it once, it is true that I now understand the whole thing
> a lot better.
> 2. Part of the 5 days for the C# development was spent doing video tutorials
> on C#.
> 3. Some of the things that took a fair bit of effort in OO COBOL were easy in
> DotNET.
>
> But despite all of that, it is quite obvious that my productivity in Visual
> Studio 2005 is MUCH better than my productivity using the Fujitsu IDE.
>
> This made me think about tools.
>
> VS 2005 provides an Interactive Development Environment that is simply years
> ahead of any other development environment I have ever worked in (on both
> mainframes and PCs).
>
> Colour coding of code, rollaway windows that you can pin down when you want
> them or send to a tab when you don't, intuitive context sensitive tooltips,
> having all your defined variables available for selection at the moment you
> want to reference them, having all methods, events and properties for the
> object you are referencing available as you type, along with help tooltips for
> any you select, ...all of these things collectively add up to MAJOR
> productivity improvements. There's no flipping through a listing (or opening
> other windows on the data division) to check variable names. No wondering or
> having to check parameter lists to methods. No syntax errors; you simply can't
> make them. No spelling errors...(Keywords are inserted for you and variables
> are selected from lists as you begin typing the name). You can view or hide
> any section of code at any time. Online contextual help is instantly available
> for any method you want to use. If you don't know what methods are available
> (always part of the problem when you start learning something), they are
> organised by type so you can browse them instantly.
>
> But.most importantly of all, the environment is NOT focused on code
> development. It is pure event driven programming. You DON'T start by writing
> IDENTIFICATION DIVISION (or its equivalent). You design what you want and the
> code for the events is placed into the right contexts for you. All of the
> housekeeping, fixed context, and overhead is hidden (unless you WANT to see
> it). You focus totally on your application and what you want to happen when
> events occur in it.
>
> I find myself wondering how much quicker I could have built COBOL apps if I
> had had this kind of development environment.
>
> I understand that Fujitsu DotNET COBOL comes with this environment. It costs
> several thousand dollars (if you can get them to sell it to you...I couldn't).
>
> Visual C# Express comes with the same environment and is a FREE download.
> (This has been so for nearly two years now. I wouldn't be surprised if they
> stop it soon...) MicroSoft WANT you to use their products. They are confident
> (and with good reason) that, once you experience this environment, you will
> want to upgrade to Enterprise version and support multiple teams all working
> in it. (The enterprise version also supports source control).
>
> There are over 400 FREE video tutorials on C# available on the web, thousands
> of code snippets and samples, and a positive and upbeat user community which
> is growing daily.
>
> (What am I doing here... :-))
>
> After a couple of months evaluating alternatives to COBOL, I am satisfied that
> C# and Java between them have everything I need. Visual Studio is simply the
> icing on the cake. I don't need to write off my existing investment in COBOL,
> as DotNET runs my existing COBOL components as unmanaged code. (This will do
> until I need to replace them, if I need to replace them.) I have been finding
> ways to minimize COBOL maintenance for some years now, and components achieve
> this. I simply use C# as the glue to hold them together.
>
> So, it looks like I will be winding down my COBOL development.
>
> The tools for cutting edge development are MUCH better and cheaper than COBOL.
> It remains useful for batch development, which is what it was invented for,
> and where we came in...
>
> Forty years of writing it.
>
> Guess it's time for a change... :-)
>
> Pete.
>
>
>
>
>
>
>
>
>
>
>
>
>
| |
| gary drummond 2006-12-23, 6:55 pm |
| William M. Klein wrote:
> FYI,
> The current Micro Focus product for .NET development comes with both the
> "traditional" (GUI) MF IDE *and* VisualStudio 2005 development. It is up to the
> programmer which is "most" convenient for them. (I tend to run "simple"
> ANSI/ISO conforming NON-OO, non-dotNET programs, so the old IDE works fine for
> me. If I were developing "real" Windows applications, I suspect, that I would
> switch over.
>
I have been browsing the security problems involved with mixing
components and languages. C# and .NET are better than others for bounds
checking, string length, and stack problems we see in the news today.
http://en.wikipedia.org/wiki/Buffer_overflow
A paper from SANS has a little more depth, and background, as well as
how it's done. In the 24 pages it explains quite a lot, and is
supprisingly easy to read.
http://www.sans.org/reading_room/wh...urecode/386.php
COBOL is not mentioned in either of the two links above, but the methods
suggested to block a lot of the errors involve replacing the libraries
with other safer ones, and third-party products that add the protections
simply provided by COBOL. By design, COBOL doesn't lend itself to most
of the above, but some protections could be disabled for fasted
processing. I wouldn't do that when mixing languages. Over half of the
vulnerabilities reported by SANS are failures to validate the
(user's/caller's) input, which I think was taught in my 3rd day of COBOL
class.
Just my $.02
Gary
| |
| gary drummond 2006-12-23, 6:55 pm |
| gary drummond wrote:
> William M. Klein wrote:
> I have been browsing the security problems involved with mixing
> components and languages. C# and .NET are better than others for bounds
> checking, string length, and stack problems we see in the news today.
> http://en.wikipedia.org/wiki/Buffer_overflow
>
> A paper from SANS has a little more depth, and background, as well as
> how it's done. In the 24 pages it explains quite a lot, and is
> supprisingly easy to read.
> http://www.sans.org/reading_room/wh...urecode/386.php
>
> COBOL is not mentioned in either of the two links above, but the methods
> suggested to block a lot of the errors involve replacing the libraries
> with other safer ones, and third-party products that add the protections
> simply provided by COBOL. By design, COBOL doesn't lend itself to most
> of the above, but some protections could be disabled for fasted
> processing. I wouldn't do that when mixing languages. Over half of the
> vulnerabilities reported by SANS are failures to validate the
> (user's/caller's) input, which I think was taught in my 3rd day of COBOL
> class.
>
> Just my $.02
>
> Gary
That should be "faster", as in NOT checking ranges and etc.
Also, thanks for the updates. Between you and Frank's comments, I may
just give C# and MF Net Express both a try.
Gary
| |
| Pete Dashwood 2006-12-24, 7:55 am |
|
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12oosqtmgaqcd81@news.supernews.com...
> Pete Dashwood wrote:
>
> Don't jump to conclusions. It has been my experience that luck has a lot
> to do with program development - maybe more than anything else.
The same way luck decides who wins at Chess? :-)
I'm not dismissing luck; as a keen Backgammon player I know that a lucky
player will beat an expert player, in the short term. In the long term;
skill will out. And every lucky streak eventually goes cold...
Nevertheless, your comment may be fair, because I only have a sample of one
and it COULD be luck.
I don't think it is. I don't think it is because, (when it comes to
programming) I am meticulous and have acquired skill. Assigning success to
having lucked out, simply devalues the many hours of thought and effort I
invested in the project..
>
> How many times have you said to yourself: "I'll be damned. It worked the
> first time!"
When this happens it isn't luck; it is care, thought, skill, and a lot of
sweat. I EXPECT stuff to work the first time; If it takes more than 3
compiles, I start thinking about a redesign...:-)
I should qualify this by saying that I write and debug at a function level.
I don't write huge programs with thousands of lines of code and then compile
them as a single entity. I write say, 50 to 100 lines (a SECTION) then
check that it works. The end product could be many thousands of lines, but
that will be many building blocks glued together, and each block will be
separately focused on, designed, built and debugged. (And many of these are
simply reusable modules that are plugged in and are known to work.) .
And how many times have you just never been able to get the
> sucker to function at all?
Only once. Forty years ago... the very first production program I ever wrote
in COBOL. It had to produce 6 reports and one of them never worked... :-)
These days if I found myself writing code that never worked, I'd consider
some other form of employment...
>
> Same tools, experience, money, etc. The only difference is providence.
No, I've never been to Rhode Island so I don't know what life changing
catharsis could be experienced there, and I don't believe in a Higher Power
who throws dice to decide whether COBOL programs work or not. Providence
simply doesn't cut it for me.
I am reasonably satisfied in this instance that, although luck cannot be
ruled out, it is far more probable that the superiority of the tools made
the difference.
I have come to believe in Visual Studio 2005... : -) The DotNET framework
also simplifies a number of things.
(And C# is a pretty  language too...)
It seems I am not the only one finding this. Demand for C# skills has almost
doubled in the last 6 months and is still steeply rising.
Quote from 'Information W' October 4th, 2006...
"Hudson sees particularly strong demand for developers, especially those
with C# skills, says Taylor. At this time last year, the demand from Hudson
clients for developers was 70% related to Java, 25% to C#, and 5% to C++.
That's not the case this year, with 70% of demand for developers with C#
talent, 25% for Java, and 5% for C++. "
Here's the full article:
[url]http://www.informationw.com/management/showArticle.jhtml?articleID=193104411&subSection=Career+Development[/url]
People wondering where their COBOL career may be going, should consider
this.
Sometimes it is comforting to have a parachute, even if the plane is flying
steadily...
It isn't hard to learn but it DOES require some time and effort. And there
are new concepts, (like OO), which reqire suspension of what you already
know, and acceptance of a different way of approaching things.. There is a
huge amount of information and (downloadable or runnable online video)
tutorials available, at all levels of programming skill (including Absolute
Beginner), for FREE, along with software and IDE downloads, for FREE. I have
been quite stunned by the quality of some of this material and would expect
to pay for it...
>
> Maybe you just got lucky.
Possible, but unlikely.
Pete.
| |
| Robert Jones 2006-12-24, 6:55 pm |
|
>
> Possible, but unlikely.
>
> Pete.
I have no doubt you are very skilled, but a rewrite will take advantage
of a number of design decisions and perhaps experiments that may have
take the original writer some time to get right. You also have to bear
in mind that perhaps you are more skilled than the person who
originally wrote it and would have done the job rather faster had you
written the original. The difference can be dramatic and even the same
person could be a lot faster with regular practice or better training.
Perhaps a fairer comparison would be a two way test, where one person
rewrites a Java and C# application in OO COBOL of roughly similar
complexity.
Having said that, I am nevertheless very impressed and can see your
point.
Robert
| |
| Pete Dashwood 2006-12-24, 9:55 pm |
|
"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1166980834.471149.102990@i12g2000cwa.googlegroups.com...
>
>
> I have no doubt you are very skilled, but a rewrite will take advantage
> of a number of design decisions and perhaps experiments that may have
> take the original writer some time to get right.
I WAS the original designer/writer... that was the whole point. I was amazed
because I expected the rewrite to take at least as long, given my
inexperience with C#. And I noted in my post that I had a better
understanding the second time.
I am totally persuaded that the toolset makes a major difference.
The whole approach under VS 2005 allows you to focus entirely on the
application and how you want it to behave. Hundreds (thousands?) of lines of
working, debugged code are generated for you (in whatever language you have
selected... C#, C++, or VB in the full version; I only have C# in the
Express version) and you only NEED to write specific code for specific
events. All of the necessary contexts are produced automatically as you
specify event handling.
In the same way that we don't write COBOL programs from scratch, but take a
previous program or template and modify it, VS2005 inserts what you actually
write into the right place in the code and does all of the housekeeping and
context for you. (You can change it if you want to, but so far I have not
had any need to.) Things like allocation of namespaces, connection to
appropriate support libraries, automatic scoping of variables and so on are
all wrapped around your code and you never have to worry about them. It's
like having someone present you with only the part of your COBOL template
that you want to deal with right now, and then ensuring that any variables
you create are automatically placed in the DATA division and any existing
variables are available on a drop down that appears as soon as you reach a
point where the syntax requires a dataname. (The list shrinks automatically
as you type further characters, or you can simply select the dataname you
want immediately from the list. There is no possibility of spelling or
syntax errors, unless you force them deliberately... I did this just to see
what compiler diagnostics looked like and how they were presented; if I
hadn't, I never would have seen this... :-)) Not only that, but a tooltip
describing the picture of the variable flashes up when you move the mouse
over the list. No more keeping listings of the data division while you write
procedure division code, or having to refer back to see what you named
something...it is all automatically at your fingertips.
That is just one tiny part of it. It is a truly interactive environment and
you interact with it to describe your application, rather than to write
code. The whole thing is component based and appropriate components are
simply dragged and dropped to where you want them. The DotNET framework is
an "object rich" environment, so a very large percentage of what you want is
already available. Things like list views, directory searches, etc are a
mouse click to install then you can decide what properties you want set, and
when.
I remember battling to get the standard directory/file selection dialog
included in an OO COBOL (PowerCOBOL)application. It was difficult and
non-intuitive. There was no documentation provided by Fujitsu and I had no
idea what the component was even called or where it lived. I had to use an
Object Browser to locate it amongst thousands of Operating System
components, and then try and figure out what its methods, properties,
events, and interfaces were and provide the correct format for them in
COBOL. Finally got it working, but it took a day. In C#/DotNET I did the
same job in literally 5 minutes, dragging the component from the toolbar
directly into my codeview. And it displays in the Windows XP theme
automatically, so the program does not look "alien" to the user. I actually
wrote 9 lines of code to support this, and 6 of those are comments...:
Here's the C# code:
private void button1_Click(object sender, EventArgs e) //provided by
VS2005
{
//provided by VS2005
/* User clicks "Browse for database" button. Open the standard dialog
* and put the selected file and path into the current form.
*
* This is only for MS ACCESS... other databases and ODBC have other
selections.
*
*/
openFileDialog1.InitialDirectory = "C:\\"; // start at the
beginning...
openFileDialog1.ShowDialog();
textBox1.Text = openFileDialog1.FileName;
}
//provided by VS2005
(I have included the // strings for clarity. They don't appear in the actual
listing.) The code to actually construct the "openFileDialog1" object is
automatically included in the right place in the C# program as soon as I
drag and drop the component icon from the DotNET toolbox. I never need to
refer or even look at it, just use the object immediately. Furthermore, it
has default properties that ensure that any selection made is a valid path
and the file selected actually exists...
First time I've done it in this environment... 5 minutes work.(Drag and drop
took seconds...) Tested it, worked perfectly first time (Jerry, please note
:-))
Here's the same stuff in OO COBOL... (about 10 hours work the first time I
wrote it, at least 1 hour to debug)...
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 FileMask Pic X(55) Value "ACCESS RDB Files (.mdb .mde)|*.mdb;*.mde|All
Files|*.*".
01 DeskFile.
12 FileName Pic X(255) Value Spaces.
12 Filler Pic X Value X"00".
01 ReturnValue pic s9(4) comp-5.
PROCEDURE DIVISION.
a000.
Move Spaces to FileName
INVOKE POW-SELF "GetFileName" USING FileName
"Select ACCESS Database File"
FileMask
POW-CDOPEN
RETURNING ReturnValue
END-INVOKE
* If ReturnValue is true, user did select a db...
if ReturnValue = POW-TRUE
move FileName to DB-path
else
move spaces to DB-path
end-if
move DB-path to "Text" of CmText2
if DB-path NOT = spaces
move spaces to "Text" of CmText1
call 'SetCaption'
else
invoke CmText2 "SetFocus"
end-if
| |
| Frank Swarbrick 2006-12-26, 9:55 pm |
| Pete Dashwood wrote:
> I remember battling to get the standard directory/file selection dialog
> included in an OO COBOL (PowerCOBOL)application. It was difficult and
> non-intuitive. There was no documentation provided by Fujitsu and I had no
> idea what the component was even called or where it lived. I had to use an
> Object Browser to locate it amongst thousands of Operating System
> components, and then try and figure out what its methods, properties,
> events, and interfaces were and provide the correct format for them in
> COBOL. Finally got it working, but it took a day. In C#/DotNET I did the
> same job in literally 5 minutes, dragging the component from the toolbar
> directly into my codeview. And it displays in the Windows XP theme
> automatically, so the program does not look "alien" to the user. I actually
> wrote 9 lines of code to support this, and 6 of those are comments...:
>
> Here's the C# code:
>
> private void button1_Click(object sender, EventArgs e) //provided by
> VS2005
> {
> //provided by VS2005
>
> /* User clicks "Browse for database" button. Open the standard dialog
> * and put the selected file and path into the current form.
> *
> * This is only for MS ACCESS... other databases and ODBC have other
> selections.
> *
> */
>
> openFileDialog1.InitialDirectory = "C:\\"; // start at the
> beginning...
> openFileDialog1.ShowDialog();
> textBox1.Text = openFileDialog1.FileName;
>
> }
> //provided by VS2005
How about this?
method-id. "button1_Click" final private.
linkage section.
01 sender object.
01 e System-EventArgs.
procedure division using by value sender e.
*> everything above here generated
move "C:\\"
to self::"openFileDialog1"::"InitialDirectory"
invoke self::"openFileDialog1"::"ShowDialog"()
move self::"openFileDialog1"::"FileName"
to self::"textBox1"::"Text"
*> everything below here generated
end method "button1_Click".
:-)
Frank
| |
| Pete Dashwood 2006-12-27, 7:55 am |
|
"Frank Swarbrick" <infocat@earthlink.net> wrote in message
news:dElkh.4094$yx6.3439@newsread2.news.pas.earthlink.net...
> Pete Dashwood wrote:
>
> How about this?
>
> method-id. "button1_Click" final private.
> linkage section.
> 01 sender object.
> 01 e System-EventArgs.
> procedure division using by value sender e.
>
> *> everything above here generated
> move "C:\\"
> to self::"openFileDialog1"::"InitialDirectory"
> invoke self::"openFileDialog1"::"ShowDialog"()
> move self::"openFileDialog1"::"FileName"
> to self::"textBox1"::"Text"
> *> everything below here generated
>
> end method "button1_Click".
>
> :-)
>
OK, but what's your point?
You don't specifiy what the above actually is, so I can only speculate...
That looks very much like what I would expect DotNET COBOL to look like.
(As this runs in the VS2005 environment, the questions below would not
apply.)
If it is MicroFocus you will pay run time fees for it as well as the
compiler cost.
If it is either of the above, it cost several thousand dollars (hardly
competitive with the FREE C# solution); if it isn't, then I have some
questions...
How does openFileDialog1 get instantiated?
How do you know what library is required?
What happens if no file is selected?
Suppose the selected file is deleted moments after you select it?
I'm also still waiting for your comments on the nested perform I posted
sample code for, in response to your comment about that...
Am I wasting my time here? :-)
Pete.
| |
| Howard Brazee 2006-12-27, 6:55 pm |
| Coding is the easy part of programming.
Prototyping tools can help with the design and user feedback. Since
these are the bottlenecks, efficiencies here help considerably.
I'm not convinced which tools make programs more maintainable.
| |
| Frank Swarbrick 2006-12-27, 6:55 pm |
| Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/27/06 3:40 AM >>>
>"Frank Swarbrick" <infocat@earthlink.net> wrote in message
>news:dElkh.4094$yx6.3439@newsread2.news.pas.earthlink.net...
[color=darkred]
>
>OK, but what's your point?
>
>You don't specifiy what the above actually is, so I can only speculate...
Point? :-)
Only that I used NetExpress COBOL within Visual Studio 2005 to create the
above, just like you used C# within Visual Studio 2005 to create your
example.
Though I have to be honest, the "Intellisense" was somewhat flakey and
didn't "lead me" as well as it apparently did for you. Not sure if that's a
"product issue" or a "user issue". :-)
>That looks very much like what I would expect DotNET COBOL to look like.
>(As this runs in the VS2005 environment, the questions below would not
>apply.)
>If it is MicroFocus you will pay run time fees for it as well as the
>compiler cost.
>
>If it is either of the above, it cost several thousand dollars (hardly
>competitive with the FREE C# solution); if it isn't, then I have some
>questions...
We'll, again, I got the"University Edition", which was under $200, but is
still not free and not for 'production use'. Now I'm not being a Micro
Focus apologist here. I totally agree that they care little to nothing
about the little guy. I was just pointing out that it is, and I think
you'll agree, Visual Studio itself that makes this so easy, and not any
particular language. I have nothing against C#, and for Windows development
I think I'd probably agree that it's a much better answer than any form of
COBOL.
>How does openFileDialog1 get instantiated?
Umm, how does it in your example? I only posted the COBOL corresponding to
your C# example.
Anyway, the instantiation of openFileDialog1 is generated by VS, just like
I'm sure it was in your example. I can't remember exactly (I only have it
at home), but I believe it was something like...
set openFileDialog1 = System-Windows-Forms-OpenFileDialog::"NEW"()
>How do you know what library is required?
I have no idea.
>What happens if no file is selected?
Dunno, but I believe that's a function of the .NET runtime. I will try it
and see what happens.
>Suppose the selected file is deleted moments after you select it?
I am no where near proficient in WinForms or any kind of event driven
program. The fact that I could even come up with the code above is only
thanks to the ease of use of VS2005!
>I'm also still waiting for your comments on the nested perform I posted
>sample code for, in response to your comment about that...
>
>Am I wasting my time here? :-)
Umm, maybe. I didn't know I was supposed to respond. I was only commenting
that I had never used it; not that it was not a useful thing to have.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
|
| Pete Dashwood wrote:
>
> But despite all of that, it is quite obvious that my productivity in Visual
> Studio 2005 is MUCH better than my productivity using the Fujitsu IDE.
This impressed me when I first started working with VB6 many years ago.
What I found especially useful was that it syntax-checked each line as
you typed it. I wrote a VB program to parse our DMS schema and compute
card columns. I looked at it a few years ago, when I already had some
years of VB experience under my belt - it was horrendous! But, it was
syntactically correct.
A little over a year ago (or has it been 2 now - wow!), I used it to
strip the data items and create relational tables. Now, the code is
much tighter - and to calculate the total size of an OCCURS clause, I
just read ahead in the dataset to get all the PIC sizes, and multiply by
the number of times.
> This made me think about tools.
>
> VS 2005 provides an Interactive Development Environment that is simply years
> ahead of any other development environment I have ever worked in (on both
> mainframes and PCs).
>
> Colour coding of code, rollaway windows that you can pin down when you want
> them or send to a tab when you don't, intuitive context sensitive tooltips,
> having all your defined variables available for selection at the moment you
> want to reference them, having all methods, events and properties for the
> object you are referencing available as you type, along with help tooltips
> for any you select, ...all of these things collectively add up to MAJOR
> productivity improvements.
SlickEdit (formerly "Visual SlickEdit") does many of these things for
COBOL, although not to the extent that VS2005 does for C#. Our
productivity shot through the roof when we began using it for our COBOL
code development. It will pop up a list of variable defined in working
storage, has context-sensitive help, and even has a window that will
show you the definition of whatever variable the cursor is on. (All
this assumes you have the thing configured correctly - it will build
"tag lists" for the COBOL COPY libraries, for example, but you have to
do that for the feature to work.)
It's a little pricey, IMO, for an editor ($200 last I checked), but of
course, the US taxpayers provide us our copies. :)
Back in 2002, I was out at Oracle in Silicon Valley, at a w-long
"hey, pick us!" pitch they were giving the USAF. Some of the folks
there were from the Software Engineering Institute (SEI) at
Carnegie-Mellon University. One of the ladies there saw it open on my
laptop and said "Hey, is that Visual SlickEdit?" I told her that it
was, and she said, "we use that all the time for our Java! I never
would have thought to use it for COBOL." I thought that was kind of
funny because, at the time, I had never thought of using it for Java.
> But.most importantly of all, the environment is NOT focused on code
> development. It is pure event driven programming. You DON'T start by writing
> IDENTIFICATION DIVISION (or its equivalent). You design what you want and
> the code for the events is placed into the right contexts for you. All of
> the housekeeping, fixed context, and overhead is hidden (unless you WANT to
> see it). You focus totally on your application and what you want to happen
> when events occur in it.
I don't really have a good comparison here, because our COBOL is based
on the Unisys mainframe. I do know that there are tools that really
integrate Windows with it (such as the ability to map drives to
mainframe program files, interactive debug execute on the mainframe from
the PC). Of course, none of them have been approved for use. (Don't
get me started on that...)
> So, it looks like I will be winding down my COBOL development.
>
> The tools for cutting edge development are MUCH better and cheaper than
> COBOL. It remains useful for batch development, which is what it was
> invented for, and where we came in...
And what it's still used for in our environment. We're seeing thousands
of batch jobs run per day - in fact, we recently had to change the way
we handled these runs, because the users were literally bringing the
system to its knees. (Have you ever seen a mainframe beg? It ain't
pretty...) Now, we have a controller, and we're actually clearing more
runs than we did with the old way, because we're controlling the number
that are started.
That's the one thing that I'm not sure about - there still is a need for
innovation within the COBOL community. There are processes that are
crucial for businesses and governments that cannot be replaced
immediately, but could be improved. What happens to these apps as the
IT world "moves on"? I don't see improvements - in our arena, every
system we interface with has had big problems with a fraction of the
transaction volume that we clear on a slow day. There was one recently
that went to 30-plus second response times when they got 4 users! Then,
you deal with all these policies and things that you have to deal with
to be "compliant," and they all seem to suck bandwidth and performance.
Sure, if you're running on a huge box, it'll be passable - but are the
network folks giving us funds to upgrade our hardware? Heh.
For good or bad, the above won't be my concern for the system on which
I've worked for the past 9 years. In a way, I hate that, because I have
so many other ideas that I know would improve the system with minimal
investment of code. I guess I just have trouble detaching myself from
this thing that I've worked so hard on for the past 9 years.
Probably more than you wanted to hear... :) Those are some of the
thoughts I've had about productivity.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Oliver Wong 2006-12-27, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4vfl66F1as7a4U1@mid.individual.net...
> Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/27/06 3:40 AM >>>
>
> Dunno, but I believe that's a function of the .NET runtime. I will try it
> and see what happens.
Perhaps the string will be set to null or the empty string or something
similar. It's probably explicitly stated in the OpenFileDialog
documentation.
>
>
> I am no where near proficient in WinForms or any kind of event driven
> program. The fact that I could even come up with the code above is only
> thanks to the ease of use of VS2005!
Nothing will happen yet... the only thing your code does is to get a
string representing the path to the selected file (before it was deleted).
Now, if all you're going to do is display that string to user, no problem
should arise (except maybe for a  user who can no longer find
specified file). But if you try to open that file, then a
FileNotFoundException will probably get thrown.
In Java, the compiler would complain unless you explicitly put code to
deal with the possibility of that exception arising. In .NET, the compiler
wouldn't say anything, and if the exception DOES come up during runtime, and
you haven't added code to handle it, the program will just terminate,
possibly emitting some debugging info (e.g. a stack trace) to the console.
- Oliver
| |
| Pete Dashwood 2006-12-27, 9:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4vfl66F1as7a4U1@mid.individual.net...
> Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/27/06 3:40 AM >>>
<snipped>[color=darkred]
>
>
> Umm, maybe. I didn't know I was supposed to respond. I was only
> commenting
> that I had never used it; not that it was not a useful thing to have.
No Frank, what prompted me to post a comprehensive example, with an
explanation, was your comment:
(From your post in the 'Looking for sample code' thread dated 14th December,
2006)
"For better or for worse I don't think I've ever written a complex perform
statement such as that. And I'm not sure I'd ever want to! :-)"
The last sentence certainly implies it is NOT a useful thing to have and, as
I believe you are involved in teaching people COBOL (I may have you
with someone else.. if you're not responsible for instructing others then it
doesn't really matter and I wouldn't have taken the time to post), I thought
some explanation/clarification from me might be in order.
I guess I'm sensitive about powerful constructs being banned on sites
(having worked in many places where they are) simply because people don't
take the trouble to understand how they work. When teachers start dismissing
them too ... well, I was hoping to get you to look again.
Of course you are not required to respond; I just hoped that you would. (My
post was in response to yours).
Thanks for the clarification about NetExpress COBOL under VS 2005. It looks
very much as NetCOBOL for DotNET would.
There is no doubt that VS2005 is a superb development environment, whatever
language you are using
The questions are not relevant if VS2005 is used, as the DotNET framework
handles them.
Leaving all of that aside, I am coming to the conclusion that I AM wasting
my time here :-) As I'm on holiday at the moment I can afford to waste some,
but in the coming year I'll look to wind down my contributions here.
Pete.
| |
| Pete Dashwood 2006-12-27, 9:55 pm |
| Really good response, Daniel. Thanks.
Comments below...
"LX-i" <lxi0007@netscape.net> wrote in message
news:73e30$4592adbc$454920f8$28313@KNOLO
GY.NET...
> Pete Dashwood wrote:
>
> This impressed me when I first started working with VB6 many years ago.
> What I found especially useful was that it syntax-checked each line as you
> typed it. I wrote a VB program to parse our DMS schema and compute card
> columns. I looked at it a few years ago, when I already had some years of
> VB experience under my belt - it was horrendous! But, it was
> syntactically correct.
I really scorned VB for many years seeing it as being "kiddie programming".
Fortunately, I was forced to use it to modify a Rational tool, and this
caused me to appreciate how powerful and concise it is, and to re-adjust my
attitude.
VB6 is a full blown programming tool and deserves its place in my toolbox.
>
> A little over a year ago (or has it been 2 now - wow!), I used it to strip
> the data items and create relational tables. Now, the code is much
> tighter - and to calculate the total size of an OCCURS clause, I just read
> ahead in the dataset to get all the PIC sizes, and multiply by the number
> of times.
It is ideal when you need something in a hurry...:-)
>
>
> SlickEdit (formerly "Visual SlickEdit") does many of these things for
> COBOL, although not to the extent that VS2005 does for C#. Our
> productivity shot through the roof when we began using it for our COBOL
> code development. It will pop up a list of variable defined in working
> storage, has context-sensitive help, and even has a window that will show
> you the definition of whatever variable the cursor is on. (All this
> assumes you have the thing configured correctly - it will build "tag
> lists" for the COBOL COPY libraries, for example, but you have to do that
> for the feature to work.)
>
> It's a little pricey, IMO, for an editor ($200 last I checked), but of
> course, the US taxpayers provide us our copies. :)
I never heard of SlickEdit, but it sounds good. I don't think $200 is a lot
to pay for a useful tool...I'm staggered that MS simply GIVE Visual Studio
2005 Express away...I guess they can afford to and it certainly gets people
into their camp.
>
> Back in 2002, I was out at Oracle in Silicon Valley, at a w-long "hey,
> pick us!" pitch they were giving the USAF. Some of the folks there were
> from the Software Engineering Institute (SEI) at Carnegie-Mellon
> University. One of the ladies there saw it open on my laptop and said
> "Hey, is that Visual SlickEdit?" I told her that it was, and she said,
> "we use that all the time for our Java! I never would have thought to use
> it for COBOL." I thought that was kind of funny because, at the time, I
> had never thought of using it for Java.
>
It's funny (and interesting) how we are blinkered by what we know...:-)
This follows from the component based approach. Thinking in "functions" (or
"production line machines"), encapsulated pieces of functionality that are
stable and robust, is a really good way to develop applications. We get too
tied into code. Need to get data and start thinking about READ...AT
END...NOT AT END... etc. when we should be thinking about WHAT we are
getting, WHY we are getting it at this point, and at how many different
places we are going to need to get it, and providing a function that simply
gets it.
I believe the difference between procedural and non-procedural approaches
underlies this. COBOL programmers are used to a sequential procedural
approach with rigid control and event driven programs aren't like that.
Objects lend themselves to being used anywhere at anytime so design can be
much more flexible.
[color=darkred]
>
> I don't really have a good comparison here, because our COBOL is based on
> the Unisys mainframe. I do know that there are tools that really
> integrate Windows with it (such as the ability to map drives to mainframe
> program files, interactive debug execute on the mainframe from the PC).
> Of course, none of them have been approved for use. (Don't get me started
> on that...)
>
>
> And what it's still used for in our environment. We're seeing thousands
> of batch jobs run per day - in fact, we recently had to change the way we
> handled these runs, because the users were literally bringing the system
> to its knees. (Have you ever seen a mainframe beg? It ain't pretty...)
> Now, we have a controller, and we're actually clearing more runs than we
> did with the old way, because we're controlling the number that are
> started.
>
Yes, COBOL is excellent for sequential batch processing and will fill that
requirement for some time to come. Eventually, transactions will be
processed so fast that Batch will not be necessary, even reports will be
spooled online as transactions occur, and so there will be less dependence
on Batch. Only historical reporting would need a batch approach. But that
time is still a few years off yet.
> That's the one thing that I'm not sure about - there still is a need for
> innovation within the COBOL community. There are processes that are
> crucial for businesses and governments that cannot be replaced
> immediately, but could be improved. What happens to these apps as the IT
> world "moves on"? I don't see improvements - in our arena, every system
> we interface with has had big problems with a fraction of the transaction
> volume that we clear on a slow day. There was one recently that went to
> 30-plus second response times when they got 4 users! Then, you deal with
> all these policies and things that you have to deal with to be
> "compliant," and they all seem to suck bandwidth and performance. Sure, if
> you're running on a huge box, it'll be passable - but are the network
> folks giving us funds to upgrade our hardware? Heh.
A very good point. I suspect that rather than fix or improve, these systems
will simply be allowed to atrophy until they are replaced. If the
replacements, as you describe above, are far worse than the existing systems
then they simply should not be accepted until proper SLAs are agreed and put
in place.
>
> For good or bad, the above won't be my concern for the system on which
> I've worked for the past 9 years. In a way, I hate that, because I have
> so many other ideas that I know would improve the system with minimal
> investment of code. I guess I just have trouble detaching myself from
> this thing that I've worked so hard on for the past 9 years.
If you didn't care about it you wouldn't be much good at it :-)
We all get emotionally attached to things that have been a big part of our
working life, even though we know we shouldn't.
why don't you write a paper on the system, outling some of the areas that
could be improved , and suggesting some approaches so that anyone taking
over at least has the option, based on your years of experience, to
implement some of your ideas?
Even if they don't, at least you know you gave it your best shot.
>
> Probably more than you wanted to hear... :)
Not at all. I for one, found your observations interesting.
>Those are some of the thoughts I've had about productivity.
It's something that many of us should give some thought to...
Pete.
| |
| Howard Brazee 2007-01-06, 6:55 pm |
| On Thu, 28 Dec 2006 14:34:05 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>Yes, COBOL is excellent for sequential batch processing and will fill that
>requirement for some time to come. Eventually, transactions will be
>processed so fast that Batch will not be necessary, even reports will be
>spooled online as transactions occur, and so there will be less dependence
>on Batch. Only historical reporting would need a batch approach. But that
>time is still a few years off yet.
I see lots of shops going with data warehouses on one side, and
on-line transactions on the other side - with interfaces between the
web servers accessing both. Where is batch CoBOL needed in that?
| |
| Michael Mattias 2007-01-06, 6:55 pm |
| "Howard Brazee" <howard@brazee.net> wrote in message
news:dnn7p2lh7524u11iuvt77dcchh76c53cfk@
4ax.com...
> On Thu, 28 Dec 2006 14:34:05 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I see lots of shops going with data warehouses on one side, and
> on-line transactions on the other side - with interfaces between the
> web servers accessing both. Where is batch CoBOL needed in that?
I think you are forgetting the incredibly ubiquitous and overwhelmingly
powerful influence of the We've Always Done It That Way School of System
Design...
MCM
| |
| Frank Swarbrick 2007-01-06, 6:55 pm |
| Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/27/06 5:59 PM >>>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:4vfl66F1as7a4U1@mid.individual.net...
><snipped>
>
>No Frank, what prompted me to post a comprehensive example, with an
>explanation, was your comment:
>
>(From your post in the 'Looking for sample code' thread dated 14th
December,
>2006)
>
>"For better or for worse I don't think I've ever written a complex perform
>statement such as that. And I'm not sure I'd ever want to! :-)"
>
>The last sentence certainly implies it is NOT a useful thing to have and,
as
>I believe you are involved in teaching people COBOL (I may have
you
>with someone else.. if you're not responsible for instructing others then
it
>doesn't really matter and I wouldn't have taken the time to post), I
thought
>some explanation/clarification from me might be in order.
>
>I guess I'm sensitive about powerful constructs being banned on sites
>(having worked in many places where they are) simply because people don't
>take the trouble to understand how they work. When teachers start
dismissing
>them too ... well, I was hoping to get you to look again.
I was only joking about that. If I ever came upon a situation where it
appears this construct would be useful I would have no problem using it. I
just don't recall ever coming upon such a thing. Or, if I did, I probably
didn't realize it and thus did something else. :-)
I am certainly *not* against using all of the power that COBOL provides. I
only recently used DECLARATIVES recently to handle file I/O errors. It's
actually quite nice, not having to check the status after each I/O. Should
be a bit more powerful to be *really* useful, but I'd be happy to see others
understand and use it. My manager at first was against my use of this, but
I convinced him by pointing out that it's an "implicit perform" rather than
an "implicit goto".
I've also recently been using UNSTRING, which I hadn't made a lot of use of
in the past. Below is something I was working on the other day. I had
hoped to be able to get it in to a single "UNSTRING", but I ended up with
two and I'm fairly happy with it. Essentially, it parses some input where
fields are delimited by '¦' (MSG-FIELD-DELIMITER), and for each field there
can be both a parm name and a parm value delimited by '='
(MSG-FIELD-SEPARATOR), or just a parm name (no '='). Each perform of
300-PARSE-INPUT-DATA should result in the parsing of one field, putting the
parm name into INPUT-STRING-ID and the parm value (if present) into
INPUT-STRING-PARM. If the field is a "null" field (essentially '¦¦') then
the flag END-OF-REQUEST should be set.
300-PARSE-INPUT-DATA.
MOVE LOW-VALUES TO INPUT-STRING-ID
INPUT-STRING-PARM
STRING-ID-DELIM
STRING-PARM-DELIM
MOVE ZEROES TO STRING-ID-LEN
STRING-PARM-LEN
IF INPUT-DATA-POS > INPUT-DATA-LENGTH
SET END-OF-REQUESTS TO TRUE
ELSE
UNSTRING INPUT-DATA
DELIMITED BY MSG-FIELD-DELIMITER
OR MSG-FIELD-SEPARATOR
INTO INPUT-STRING-ID
DELIMITER IN STRING-ID-DELIM
COUNT IN STRING-ID-LEN
POINTER INPUT-DATA-POS
END-UNSTRING
IF STRING-ID-DELIM = MSG-FIELD-SEPARATOR
UNSTRING INPUT-DATA
DELIMITED BY MSG-FIELD-DELIMITER
INTO INPUT-STRING-PARM
DELIMITER IN STRING-PARM-DELIM
COUNT IN STRING-PARM-LEN
POINTER INPUT-DATA-POS
END-UNSTRING
END-IF
IF STRING-ID-LEN = ZERO
SET END-OF-REQUEST TO TRUE
END-IF
I'm guessing there is no way to make this a single UNSTRING, but if anyone
can do it I'd love to see it! :-)
>Of course you are not required to respond; I just hoped that you would. (My
>post was in response to yours).
Sorry. I simply didn't feel I had any more to add.
>Thanks for the clarification about NetExpress COBOL under VS 2005. It looks
>very much as NetCOBOL for DotNET would.
>
>There is no doubt that VS2005 is a superb development environment, whatever
>language you are using
I sometimes (often?) wish I worked in a job where I could take advantage of
such tools, rather than just fooling around with them at home. Our Windows
applications team is now using Visual C# and sometimes I am jealous! (They
had been using Borland Delphi previously, but were having a hard time
finding Delphi developers.)
>The questions are not relevant if VS2005 is used, as the DotNET framework
>handles them.
When do we get .NET for the mainframe? :-)
>Leaving all of that aside, I am coming to the conclusion that I AM wasting
>my time here :-) As I'm on holiday at the moment I can afford to waste
some,
>but in the coming year I'll look to wind down my contributions here.
That is up to you, of course. I, for one, value your contributions, even if
it sometimes appears that I don't. :-)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:dnn7p2lh7524u11iuvt77dcchh76c53cfk@
4ax.com...
> On Thu, 28 Dec 2006 14:34:05 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I see lots of shops going with data warehouses on one side, and
> on-line transactions on the other side - with interfaces between the
> web servers accessing both. Where is batch CoBOL needed in that?
A good question. I hadn't considered that scenario. Thanks, Howard.
Pete.
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:AYRkh.10164$ZT3.9592@newssvr19.news.prodigy.com...
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:dnn7p2lh7524u11iuvt77dcchh76c53cfk@
4ax.com...
>
> I think you are forgetting the incredibly ubiquitous and overwhelmingly
> powerful influence of the We've Always Done It That Way School of System
> Design...
>
LOL! Sad but true...:-)
Pete
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4vimr5F1cedo7U1@mid.individual.net...
> Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/27/06 5:59 PM >>>
> dismissing
>
> I was only joking about that. If I ever came upon a situation where it
> appears this construct would be useful I would have no problem using it.
> I
> just don't recall ever coming upon such a thing. Or, if I did, I probably
> didn't realize it and thus did something else. :-)
Fair enough. Thanks for that.
>
> I am certainly *not* against using all of the power that COBOL provides.
> I
> only recently used DECLARATIVES recently to handle file I/O errors. It's
> actually quite nice, not having to check the status after each I/O.
> Should
> be a bit more powerful to be *really* useful, but I'd be happy to see
> others
> understand and use it. My manager at first was against my use of this,
> but
> I convinced him by pointing out that it's an "implicit perform" rather
> than
> an "implicit goto".
Yes, DECLARATIVES can be very useful. In the old days, before disks, we used
them all the time to handle tape errors... :-)
>
> I've also recently been using UNSTRING, which I hadn't made a lot of use
> of
> in the past. Below is something I was working on the other day. I had
> hoped to be able to get it in to a single "UNSTRING", but I ended up with
> two and I'm fairly happy with it. Essentially, it parses some input where
> fields are delimited by '¦' (MSG-FIELD-DELIMITER), and for each field
> there
> can be both a parm name and a parm value delimited by '='
Do you mean it looks like this: |name=value=| or |name=value| ?
> (MSG-FIELD-SEPARATOR), or just a parm name (no '='). Each perform of
> 300-PARSE-INPUT-DATA should result in the parsing of one field, putting
> the
> parm name into INPUT-STRING-ID and the parm value (if present) into
> INPUT-STRING-PARM. If the field is a "null" field (essentially '¦¦') then
> the flag END-OF-REQUEST should be set.
If you can clarify the use of = as requested above, I believe I can do this
with a single UNSTRING.
Having said that, what you have posted is pretty good, especially for an
early attempt :-)
I think I would unstring ALL of the parameters into a name/value array
during initialization, rather than go back to the arguments during
processing, but that is just me...
>
> 300-PARSE-INPUT-DATA.
> MOVE LOW-VALUES TO INPUT-STRING-ID
> INPUT-STRING-PARM
> STRING-ID-DELIM
> STRING-PARM-DELIM
> MOVE ZEROES TO STRING-ID-LEN
> STRING-PARM-LEN
> IF INPUT-DATA-POS > INPUT-DATA-LENGTH
> SET END-OF-REQUESTS TO TRUE
> ELSE
> UNSTRING INPUT-DATA
> DELIMITED BY MSG-FIELD-DELIMITER
> OR MSG-FIELD-SEPARATOR
> INTO INPUT-STRING-ID
> DELIMITER IN STRING-ID-DELIM
> COUNT IN STRING-ID-LEN
> POINTER INPUT-DATA-POS
> END-UNSTRING
> IF STRING-ID-DELIM = MSG-FIELD-SEPARATOR
> UNSTRING INPUT-DATA
> DELIMITED BY MSG-FIELD-DELIMITER
> INTO INPUT-STRING-PARM
> DELIMITER IN STRING-PARM-DELIM
> COUNT IN STRING-PARM-LEN
> POINTER INPUT-DATA-POS
> END-UNSTRING
> END-IF
> IF STRING-ID-LEN = ZERO
> SET END-OF-REQUEST TO TRUE
> END-IF
>
> I'm guessing there is no way to make this a single UNSTRING, but if anyone
> can do it I'd love to see it! :-)
Post some example parameter strings so we can be sure we are on the same
wavelength and I'll post what my solution would be. There are many ways to
do this; I'm not saying mine is the best, but it would use a single
UNSTRING.
<snip>
>
> I sometimes (often?) wish I worked in a job where I could take advantage
> of
> such tools, rather than just fooling around with them at home. Our
> Windows
> applications team is now using Visual C# and sometimes I am jealous!
> (They
> had been using Borland Delphi previously, but were having a hard time
> finding Delphi developers.)
That is very interesting to me as I'm getting into C# at the moment. I was
wondering if any Corporates were looking at it... Statistics say they are,
but it is nice to have this confirmed by some first hand reports.
>
>
> When do we get .NET for the mainframe? :-)
Er... I think it's called LE :-)
> That is up to you, of course. I, for one, value your contributions, even
> if
> it sometimes appears that I don't. :-)
>
Thanks :-)
Pete.
| |
| Richard 2007-01-06, 6:55 pm |
|
Howard Brazee wrote:
> web servers accessing both. Where is batch CoBOL needed in that?
Cobol runs fine running services for a web server.
| |
| Howard Brazee 2007-01-06, 6:55 pm |
| On 28 Dec 2006 20:43:14 -0800, "Richard" <riplin@Azonic.co.nz> wrote:
>
>Cobol runs fine running services for a web server.
Sure. It's advantage is when you already have people who are good at
CoBOL. I can't think of an other advantage of using it for running
web services.
| |
| Frank Swarbrick 2007-01-06, 6:55 pm |
| >>>> Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/28/06 4:34 PM >>>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:4vimr5F1cedo7U1@mid.individual.net...
[color=darkred]
It's[color=darkred]
>
>Yes, DECLARATIVES can be very useful. In the old days, before disks, we
used
>them all the time to handle tape errors... :-)
It's still useful to handle "file out of space" conditions. (Somethat that
never happens in the world of tape processing!)
[color=darkred]
with[color=darkred]
where[color=darkred]
>
>Do you mean it looks like this: |name=value=| or |name=value| ?
The latter.
then[color=darkred]
>
>If you can clarify the use of = as requested above, I believe I can do
this
>with a single UNSTRING.
Here's an example:
userId=FJS¦location=AURO¦function=filmRe
quest¦acctNumber=1234567890¦userExte
nsion=1403¦routing=branch¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments Go
Here¦type=debit¦date=121306¦amount=100.00¦sequenceNbr=12345678¦¦type=credit¦
date=051406¦amount=900. 00¦sequenceNbr=11122233¦¦type=ATM¦date=0
10106¦amount=
123. 45¦¦type=chargeback¦date=010106¦amount=5
00.00¦¦type=statement¦date=03290
6¦amount=1000.00¦
In this case there are none with just the parm name and not the parm value.
In fact so far we have no cases like that, but I'm trying to "think ahead"
just in case we do want to allow for that. So, just so we have a better
example, let me change the above to this (I removed the "type=", leaving
just the value (which would now be considered the "string ID" rather than
the "string parm"):
userId=FJS¦location=AURO¦function=filmRe
quest¦acctNumber=1234567890¦userExte
nsion=1403¦routing=branch¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments Go
Here¦debit¦date=121306¦amount=100. 00¦sequenceNbr=12345678¦¦credit¦date=051
40
6¦amount=900. 00¦sequenceNbr=11122233¦¦ATM¦date=010106
¦amount=123.45¦¦chargeb
ack¦date=010106¦amount=500.00¦¦statement¦date=032906¦amount=1000.00¦
So the result should be:
INPUT-STRING-ID=userId
INPUT-STRING-PARM=FJS
INPUT-STRING-ID=location
INPUT-STRING-PARM=AURO
INPUT-STRING-ID=function
INPUT-STRING-PARM=filmRequest
INPUT-STRING-ID=acctNumber
INPUT-STRING-PARM=1234567890
INPUT-STRING-ID=userExtension
INPUT-STRING-PARM=1403
INPUT-STRING-ID=routing
INPUT-STRING-PARM=branch
INPUT-STRING-ID=routeLoc
INPUT-STRING-PARM=K-MISS
INPUT-STRING-ID=routeAttn
INPUT-STRING-PARM=Joe
INPUT-STRING-ID=comments
INPUT-STRING-PARM=Comments Go Here
INPUT-STRING-ID=debit
INPUT-STRING-PARM=
INPUT-STRING-ID=date
INPUT-STRING-PARM=121306
INPUT-STRING-ID=amount
INPUT-STRING-PARM=100.00
INPUT-STRING-ID=sequenceNbr
INPUT-STRING-PARM=12345678
INPUT-STRING-ID=
INPUT-STRING-PARM=
INPUT-STRING-ID=credit
INPUT-STRING-PARM=
INPUT-STRING-ID=date
INPUT-STRING-PARM=051406
INPUT-STRING-ID=amount
INPUT-STRING-PARM=900.00
INPUT-STRING-ID=sequenceNbr
INPUT-STRING-PARM=11122233
INPUT-STRING-ID=
INPUT-STRING-PARM=
INPUT-STRING-ID=ATM
INPUT-STRING-PARM=
INPUT-STRING-ID=date
INPUT-STRING-PARM=010106
INPUT-STRING-ID=amount
INPUT-STRING-PARM=123.45
INPUT-STRING-ID=
INPUT-STRING-PARM=
INPUT-STRING-ID=chargeback
INPUT-STRING-PARM=
INPUT-STRING-ID=date
INPUT-STRING-PARM=010106
INPUT-STRING-ID=amount
INPUT-STRING-PARM=500.00
INPUT-STRING-ID=
INPUT-STRING-PARM=
INPUT-STRING-ID=statement
INPUT-STRING-PARM=
INPUT-STRING-ID=date
INPUT-STRING-PARM=032906
INPUT-STRING-ID=amount
INPUT-STRING-PARM=1000.00
>Having said that, what you have posted is pretty good, especially for an
>early attempt :-)
Well, it's not like I just came up with it all at once. :-) I tried a few
things and that was the one that worked.
>I think I would unstring ALL of the parameters into a name/value array
>during initialization, rather than go back to the arguments during
>processing, but that is just me...
We are doing this, just not within this paragraph. After each
300-PARSE-INPUT-DATA is done there's a validation routine, and if the parm
is valid then INPUT-STRING-ID and INPUT-STRING-PARM are placed into just
such an array. That array is then passed to the appropriate sub-program
(depending on the value of the "function" parameter) for further
processing.
>Post some example parameter strings so we can be sure we are on the same
>wavelength and I'll post what my solution would be. There are many ways to
>do this; I'm not saying mine is the best, but it would use a single
>UNSTRING.
See above. I am preparing myself to be amazed. :-)
><snip>
[color=darkred]
>
>That is very interesting to me as I'm getting into C# at the moment. I was
>wondering if any Corporates were looking at it... Statistics say they are,
>but it is nice to have this confirmed by some first hand reports.
framework[color=darkred]
>
>Er... I think it's called LE :-)
Ho ho ho.
[color=darkred]
>
>Thanks :-)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2007-01-06, 6:55 pm |
| Pete Dashwood<dashwood@removethis.enternet.co.nz> 12/28/06 2:42 PM >>>
>
>"Howard Brazee" <howard@brazee.net> wrote in message
> news:dnn7p2lh7524u11iuvt77dcchh76c53cfk@
4ax.com...
that[color=darkred]
dependence[color=darkred]
that[color=darkred]
>
>A good question. I hadn't considered that scenario. Thanks, Howard.
What about the manager who wants to know the total amount of transactions
processed today? I guess there would be something that uses SQL to do this,
selecting only transactions with a particular date. Not a bad idea.
I am very curious to know if there are any banks out there that work like
this. Additional things that a bank would have to worry about is when to
accumulate and/or pay interest, and when to cutoff transactions for an
account whose statement is cycling today. Seems to be that "batch
processes" would be required for both of those cases. Especially the
interest thing, because you essentially have to go through every single
account, even those that did not have any transactions today, and accrue
their interest (oh, and charge their fees! <G> ).
It's not that I think such things are "impossible". More that they are out
of the realm of my experience, and thus fraught with many unknowns.
fRANK
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4vlc76F1bf56sU2@mid.individual.net...
<snip>
> What about the manager who wants to know the total amount of transactions
> processed today? I guess there would be something that uses SQL to do
> this,
> selecting only transactions with a particular date. Not a bad idea.
>
> I am very curious to know if there are any banks out there that work like
> this. Additional things that a bank would have to worry about is when to
> accumulate and/or pay interest, and when to cutoff transactions for an
> account whose statement is cycling today. Seems to be that "batch
> processes" would be required for both of those cases. Especially the
> interest thing, because you essentially have to go through every single
> account, even those that did not have any transactions today, and accrue
> their interest (oh, and charge their fees! <G> ).
>
> It's not that I think such things are "impossible". More that they are
> out
> of the realm of my experience, and thus fraught with many unknowns.
It needs a slight change of concept.
A batch process is an accumulation of events that happened in the past. An
on-line process involves events happening now. (Usually in the form of
transactions)
Therefore, theoretically at least, a batch process can be removed if the
transactions happening "now" make provision for the things the Batch process
would have been run to find out. (Sorry, I know that sounds clumsy, but it
is the best I can do... :-))
Another way to look at it is that the batch process emulates a series of
events over time. Therefore, if those events provided what the batch process
is going to, as they happened, there would be no need for the batch process.
Because of the fundamental laws of arithmetic you can achieve the same
result with a series of individual accumulations as they occur, as you can
with a bunch of retrospective accumulations.
I have worked for a few major banks and I know of one that does online
accrual and interest calculation. (It's in London and is not a retail
bank). Interest on any account is available as it stands "now" without
running a batch process. Transactions affecting the balance automatically
post to the interest account so it is always up to date. Interest is
calculated on the days between the old and new balance at the time any
transaction on the account is run, and is accrued. (A transaction is run to
get the current interest and it does exactly the same calculation. The old
and new balance will be the same, but the dates between them will require
interest to be calculated to bring the interest up to date.) This stuff is
complex because of interest rate fluctuations (rates are held as a
"collection" ordered by date), but it can certainly be done.
Statements can also be built up on line with lines being added as
transactions occur. A "virtual image" of the statement is held until it is
requested or otherwise triggered by a statement date. My local bank here in
NZ offers online statements and I no longer get paper ones. I can request a
statement any time I want and it will reflect the state of my account as it
is "now" or between whatever dates I specify (up to about one year ago). The
information is presented immediately on request, via a Web Service, and
interest is calculated and shown for the period I requested the statement.
(Along with fees as you mentioned.)
Howard is right in that Data Warehousing can simply remove much of the need
for batch processing, with data cubes already providing consolidated and
accumulated pictures which are updated in real time, along with the
capability to drill down to detail right now, as the transaction runs.
Databases that have stored procedures triggered by transactions can fully
automate much of what would have required a batch process to extract.
I think batch processing will be with us for some time to come (mainly
because of what Michael observed: "That's the way we've always done it"),
and not because of any real need for it. As the new approaches and tools
become more firmly established, and the demand for information right "now"
increases, we will see diminishng dependency on it.
Pete.
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:l2bap2h2poke97e8q19cpl77nl9rbgu5d1@
4ax.com...
> On 28 Dec 2006 20:43:14 -0800, "Richard" <riplin@Azonic.co.nz> wrote:
>
>
> Sure. It's advantage is when you already have people who are good at
> CoBOL. I can't think of an other advantage of using it for running
> web services.
I agree totally. I am currently building a web service and I would normally
have used COBOL on the server. It runs very well as a CGI processor on the
server side, but for a properly presented web service it is simply easier to
use DotNET and C#. WSDL and XML are generated automatically and there is no
requirement for the SOAP transport layer. It isn't that COBOL CAN'T do it,
it is just that there is no advantage in using it and there ARE advantages
in NOT using it, for me, at least...
Pete
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4vlbkiF1bf56sU1@mid.individual.net...
>
> It's
> used
>
> It's still useful to handle "file out of space" conditions. (Somethat
> that
> never happens in the world of tape processing!)
>
>
> with
> where
>
> The latter.
>
> then
> this
>
> Here's an example:
> userId=FJS¦location=AURO¦function=filmRe
quest¦acctNumber=1234567890¦userExte
> nsion=1403¦routing=branch¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments
> Go
> Here¦type=debit¦date=121306¦amount=100.00¦sequenceNbr=12345678¦¦type=credit¦
> date=051406¦amount=900. 00¦sequenceNbr=11122233¦¦type=ATM¦date=0
10106¦amount=
> 123. 45¦¦type=chargeback¦date=010106¦amount=5
00.00¦¦type=statement¦date=03290
> 6¦amount=1000.00¦
>
> In this case there are none with just the parm name and not the parm
> value.
> In fact so far we have no cases like that, but I'm trying to "think ahead"
> just in case we do want to allow for that. So, just so we have a better
> example, let me change the above to this (I removed the "type=", leaving
> just the value (which would now be considered the "string ID" rather than
> the "string parm"):
> userId=FJS¦location=AURO¦function=filmRe
quest¦acctNumber=1234567890¦userExte
> nsion=1403¦routing=branch¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments
> Go
> Here¦debit¦date=121306¦amount=100. 00¦sequenceNbr=12345678¦¦credit¦date=051
40
> 6¦amount=900. 00¦sequenceNbr=11122233¦¦ATM¦date=010106
¦amount=123.45¦¦chargeb
> ack¦date=010106¦amount=500.00¦¦statement¦date=032906¦amount=1000.00¦
>
> So the result should be:
> INPUT-STRING-ID=userId
> INPUT-STRING-PARM=FJS
>
> INPUT-STRING-ID=location
> INPUT-STRING-PARM=AURO
>
> INPUT-STRING-ID=function
> INPUT-STRING-PARM=filmRequest
>
> INPUT-STRING-ID=acctNumber
> INPUT-STRING-PARM=1234567890
>
> INPUT-STRING-ID=userExtension
> INPUT-STRING-PARM=1403
>
> INPUT-STRING-ID=routing
> INPUT-STRING-PARM=branch
>
> INPUT-STRING-ID=routeLoc
> INPUT-STRING-PARM=K-MISS
>
> INPUT-STRING-ID=routeAttn
> INPUT-STRING-PARM=Joe
>
> INPUT-STRING-ID=comments
> INPUT-STRING-PARM=Comments Go Here
>
> INPUT-STRING-ID=debit
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=date
> INPUT-STRING-PARM=121306
>
> INPUT-STRING-ID=amount
> INPUT-STRING-PARM=100.00
>
> INPUT-STRING-ID=sequenceNbr
> INPUT-STRING-PARM=12345678
>
> INPUT-STRING-ID=
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=credit
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=date
> INPUT-STRING-PARM=051406
>
> INPUT-STRING-ID=amount
> INPUT-STRING-PARM=900.00
>
> INPUT-STRING-ID=sequenceNbr
> INPUT-STRING-PARM=11122233
>
> INPUT-STRING-ID=
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=ATM
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=date
> INPUT-STRING-PARM=010106
>
> INPUT-STRING-ID=amount
> INPUT-STRING-PARM=123.45
>
> INPUT-STRING-ID=
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=chargeback
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=date
> INPUT-STRING-PARM=010106
>
> INPUT-STRING-ID=amount
> INPUT-STRING-PARM=500.00
>
> INPUT-STRING-ID=
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=statement
> INPUT-STRING-PARM=
>
> INPUT-STRING-ID=date
> INPUT-STRING-PARM=032906
>
> INPUT-STRING-ID=amount
> INPUT-STRING-PARM=1000.00
>
>
> Well, it's not like I just came up with it all at once. :-) I tried a
> few
> things and that was the one that worked.
>
>
> We are doing this, just not within this paragraph. After each
> 300-PARSE-INPUT-DATA is done there's a validation routine, and if the parm
> is valid then INPUT-STRING-ID and INPUT-STRING-PARM are placed into just
> such an array. That array is then passed to the appropriate sub-program
> (depending on the value of the "function" parameter) for further
> processing.
>
>
>
> See above. I am preparing myself to be amazed. :-)
OK, that is excellent. It is a rainy Saturday here (so much for Summer :-))
so I'll make that my entertainment for the day (it will be good to write
some COBOL again :-)). I'll post fully functioning code later today.
Whether it will be "amazing" or not may depend on how much Jack Daniel's
gets consumed... :-)
Pete.
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4vlnqgF1c247oU1@mid.individual.net...
>
OK, as promised here is a complete working program.
I really enjoyed doing this :-)
The hard parts were confining myself to the B margin and using upper case...
Fortunately the sun has come out and I'm off to a cocktail party so it might
not be perfect. I ran it and checked the output; (the ARGUMENTS array)... it
looked good.
You may need to remove all the *> comments if your compiler doesn't support
them; the rest should compile OK.
Should be able to cut and paste the code below directly into your editor. It
should run as written.
IDENTIFICATION DIVISION.
PROGRAM-ID. NVPARMS.
AUTHOR. PETER E. C. DASHWOOD.
DATE-WRITTEN. DECEMBER 30TH, 2006.
*REMARKS.
*
* A SET OF "PARAMETERS" MUST BE PARSED AND PRESENTED TO A
* PROGRAM
* FOR PROCESSING
*
* IN FACT, THESE ARE NOT "PARAMETERS" AT ALL BUT ARE REALLY
* AN INPUT
* FILE...
*
* NEVERTHELESS THE PROGRAM DEMONSTRATES SOME USES OF:
* UNSTRING
* COMPLEX PERFORM
* INSPECT
*
* THE COMPLETE PARAMETER SET IS STORED TO AN ARRAY DURING
* INITIALIZATION AS A 'ONE-TIME' TASK.
*
* THIS ARRAY COULD BE VALIDATED DURING INITIALIZATION ALSO,
* AND ENTRIES IN IT CROSS-REFERENCED IF REQUIRED.
*
* BY ISOLATING THE CODE TO LOAD THE ARGUMENTS INTO THE
* INITIALIZATION
* PART OF THE PROGRAM, THIS CODE COULD BE USED IN ANY PROGRAM
* THAT HAD A SIMILAR PARAMETER FORMAT. DOING IT FROM THE
* MAINLINE ON A PARAMETER BY PARAMETER BASIS PREVENTS THIS.
*
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-PC.
OBJECT-COMPUTER. IBM-PC.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 ARGUMENTS.
12 NAME-VALUE-PAIR OCCURS 40
INDEXED BY ARGS-X1.
15 ARG-NAME PIC X(25).
15 ARG-VALUE PIC X(25).
15 ARG-EOG PIC X. *> INDICATES THAT THIS ENTRY IS
*> THE END OF A "GROUP" OF
*> PARAMETERS.
88 ARG-END-OF-GROUP VALUE '1'.
01 ARGS-TABLE-LIMIT PIC S9(4) COMP VALUE 40.
*> MUST MATCH VALUE IN OCCURS ABOVE.
01 IN-DATA.
12 FILLER PIC X(50) VALUE
" userId=FJS¦location=AURO¦function=filmRe
quest¦acct".
12 FILLER PIC X(50) VALUE
" Number=1234567890¦userExtension=1403¦rou
ting=branc".
12 FILLER PIC X(50) VALUE
"h¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments ".
12 FILLER PIC X(50) VALUE
"Go Here¦debit¦date=121306¦amount=100.00¦sequenceNb".
12 FILLER PIC X(50) VALUE
" r=12345678¦¦credit¦date=051406¦amount=90
0.00¦seque".
12 FILLER PIC X(50) VALUE
" nceNbr=11122233¦¦ATM¦date=010106¦amount=
123.45¦¦ch".
12 FILLER PIC X(50) VALUE
"argeback¦date=010106¦amount=500.00¦¦statement¦date".
12 FILLER PIC X(50) VALUE
"=032906¦amount=1000.00¦ ".
01 INPUT-DATA REDEFINES IN-DATA PIC X(400).
01 VARIOUS-COUNTS USAGE COMP.
12 MAX-ARGUMENTS PIC S9(4).
12 INPUT-DATA-POS PIC S9(4).
12 STRING-PARM-LEN PIC S9(4).
12 MYTALLY1 PIC S9(4).
12 MYTALLY2 PIC S9(4).
12 INPUT-DATA-LENGTH PIC S9(4).
12 NUMBER-NAME-VALUE-PAIRS PIC S9(4).
01 VARIOUS-OTHER-DATA.
12 INPUT-STRING-ID PIC X(25).
12 INPUT-STRING-PARM PIC X(25).
12 NV-WORK PIC X(60).
12 MSG-FIELD-DELIMITER PIC X VALUE "¦".
12 MSG-FIELD-SEPARATOR PIC X VALUE "=".
01 FLAGS.
12 FINISH-FLAG PIC X VALUE SPACE.
88 FINISHED VALUE '1'.
88 NOT-FINISHED VALUE '0'.
12 REQUEST-FLAG PIC X VALUE SPACE.
88 END-OF-REQUEST VALUE '1'.
88 NOT-END-OF-REQUEST VALUE '0'.
PROCEDURE DIVISION.
MAIN SECTION.
000.
PERFORM 100-INITIAL-SETUP
PERFORM 200-PROCESSING UNTIL FINISHED
* PERFORM 900-CLOSE-DOWN
STOP RUN
| |
| Rick Smith 2007-01-06, 6:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4vm6ldF16ggd7U1@mid.individual.net...
[snip]
> 01 IN-DATA.
> 12 FILLER PIC X(50) VALUE
> " userId=FJS¦location=AURO¦function=filmRe
quest¦acct".
> 12 FILLER PIC X(50) VALUE
> " Number=1234567890¦userExtension=1403¦rou
ting=branc".
> 12 FILLER PIC X(50) VALUE
> "h¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments ".
> 12 FILLER PIC X(50) VALUE
> "Go Here¦debit¦date=121306¦amount=100.00¦sequenceNb".
> 12 FILLER PIC X(50) VALUE
> " r=12345678¦¦credit¦date=051406¦amount=90
0.00¦seque".
> 12 FILLER PIC X(50) VALUE
> " nceNbr=11122233¦¦ATM¦date=010106¦amount=
123.45¦¦ch".
> 12 FILLER PIC X(50) VALUE
> "argeback¦date=010106¦amount=500.00¦¦statement¦date".
> 12 FILLER PIC X(50) VALUE
> "=032906¦amount=1000.00¦ ".
> 01 INPUT-DATA REDEFINES IN-DATA PIC X(400).
Just an observation; but it seems easier to me,
when populating a large data item, to use the
STRING statement. For example, ...
move spaces to input-data
string
" userId=FJS¦location=AURO¦function=filmRe
quest¦acct"
" Number=1234567890¦userExtension=1403¦rou
ting=branc"
"h¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments "
"Go Here¦debit¦date=121306¦amount=100.00¦sequenceNb"
" r=12345678¦¦credit¦date=051406¦amount=90
0.00¦seque"
" nceNbr=11122233¦¦ATM¦date=010106¦amount=
123.45¦¦ch"
"argeback¦date=010106¦amount=500.00¦¦statement¦date"
"=032906¦amount=1000.00¦"
delimited by size
into input-data.
And, multiple STRING statements allow
for multiple tests.
Furthermore, binary values may be inserted
by using hex literals (non-ANS 85). For example, ...
move spaces to cr-lf-separated-data
string
"abc" x"0d0a" "def" x"0d0a" "ghi" x"0d0a"
delimited by size
into cr-lf-separated-data.
All this with no messy counting!
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12pdftt926l3sb9@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:4vm6ldF16ggd7U1@mid.individual.net...
> [snip]
>
> Just an observation; but it seems easier to me,
> when populating a large data item, to use the
> STRING statement. For example, ...
>
> move spaces to input-data
> string
> " userId=FJS¦location=AURO¦function=filmRe
quest¦acct"
> " Number=1234567890¦userExtension=1403¦rou
ting=branc"
> "h¦routeLoc=K-MISS¦routeAttn=Joe¦comments=Comments "
> "Go Here¦debit¦date=121306¦amount=100.00¦sequenceNb"
> " r=12345678¦¦credit¦date=051406¦amount=90
0.00¦seque"
> " nceNbr=11122233¦¦ATM¦date=010106¦amount=
123.45¦¦ch"
> "argeback¦date=010106¦amount=500.00¦¦statement¦date"
> "=032906¦amount=1000.00¦"
> delimited by size
> into input-data.
>
> And, multiple STRING statements allow
> for multiple tests.
>
> Furthermore, binary values may be inserted
> by using hex literals (non-ANS 85). For example, ...
>
> move spaces to cr-lf-separated-data
> string
> "abc" x"0d0a" "def" x"0d0a" "ghi" x"0d0a"
> delimited by size
> into cr-lf-separated-data.
>
> All this with no messy counting!
>
Yes, that's a good point.
Over the years (starting from before STRING was available) I tried many ways
to insert long strings into COBOL programs. I'm sure most COBOL programmers
have encountered the same problem. Continuation is ugly and not simple; most
other definitions require counting as you point out, and that is also messy
and error prone.
I tried concatenation (similar to what you would do in VB) and that worked
OK but left me vaguely dissatisfied :-).
The above is as easy as I could make it on myself inasmuch as it is clear
and you don't need to count. (Just take X columns from wherever you start...
if it starts in 13 and you have defined X to be 50, it must end in 62, start
+ X - 1).
The Fujitsu IDE I use to write COBOL shows line and column for wherever you
put the cursor, so this is pretty simple. After doing the first one and
checking it, it is a simple matter to copy this and insert the rest.
Your point about hex literals is well taken, and for this it would certainly
be necessary to either concatenate or use STRING.
Pete.
| |
| P. Raulerson 2007-01-06, 6:55 pm |
| Just my two cents - Data Warehousing often requires a really staggering
amount of data manipulation and reduction before it is stored in the
warehouse. COBOL, in particular BATCH COBOL, is really good for this.
Secondly, OLTP systems usually have a batch processing back end to them
somewhere or another. BATCH processing is just cheaper and faster, and as
such will stick around for a long time to come. ;) COBOL is again, good for
that.
-Paul
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:4vis2tF1cbkkdU1@mid.individual.net...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:dnn7p2lh7524u11iuvt77dcchh76c53cfk@
4ax.com...
>
> A good question. I hadn't considered that scenario. Thanks, Howard.
>
> Pete.
>
| |
| Pete Dashwood 2007-01-06, 6:55 pm |
|
"P. Raulerson" <paul.rl@raulersons.com> wrote in message
news:pQDlh.78496$V34.25214@newsfe17.lga...
> Just my two cents - Data Warehousing often requires a really staggering
> amount of data manipulation and reduction before it is stored in the
> warehouse. COBOL, in particular BATCH COBOL, is really good for this.
As experience is gained, Data Warehouses become better. Designs improve,
processing is faster, facilities are more diverse. I know one company where
NO COBOL has ever been used, and yet their Data Warehouse provides
incredible support to their business. In particular, cubes can be updated
from online transactions and automatically consolidated by the warehousing
software. No batch processing is involved, as far as I know.
>
> Secondly, OLTP systems usually have a batch processing back end to them
> somewhere or another.
Only because that is how it has "always been done"... :-) (See Michael's
comment elsewhere).
I addressed this in my response to Frank, in this thread, on 30th December.
Smarter transactions, running on more powerful processors can obviate batch
processing. DW software facilitates this.
A properly implemented DW (and I think this may have been Howard's point)
can obviate a good deal, if not all, of batch processing.
>BATCH processing is just cheaper and faster, and as such will stick around
>for a long time to come. ;)
I believe it will, but NOT for the reasons you state. It ISN'T cheaper
(compared to an on-line transaction that sets up accrual in real time) and
it certainly isn't faster. Adding online accrual to a transaction, for
example, means it only accesses "today's" data; a batch process would have
to look at EVERY day's data. You might thik that processing cycles consumed
should be the same, but it ain't necessarily so...
(Consider an online transaction that calculates interest on an account which
last had a balance change 3 ws ago. The transaction can access a
collection of interest rates for the dates between then and today and
calculate the accrued interest; it only has to calculate for one period (the
time since the last balance chage). It "knows" the balance changed because
it is the transaction that changed it, and it wouldn't be running UNLESS the
balance changed...
A batch process doing the same job uses a "brute force" approach, looking at
every account every night, whether the balance changed or not, because it
can't know whether the balance changed until it looks at it... :-) Total
processing cycles consumed (especially EXCPs, if you work in an IBM
environment) will be (much) higher for the batch process.)
This, admittedly contrived, example demonstrates quite clearly the
fundamental difference between event driven (read, "on-line") and
non-event-driven (read, "batch") processing. OO lends itself to event driven
processing; procedural programming doesn't. That is why OO is taking over
the world... (whether the people using it understand this or not... all they
know is that Objects are flexible and responsive and designed to handle
events; procedural code simply isn't...)
Talk to your Ops Manager about the effort required to get everything
processed through the overnight "Batch window"... You can see Ops people age
every time a new system with Batch processing is released...The usual
solution is to throw more hardware at it, but then there is all the
paperwork and hassle of getting approvals... Politically, it is much easier
to get approval when online transactions have slowed, because they are so
much more visible.
I think Batch will be with us for a few years yet, as I stated before, but
it won't be because it CAN'T be decommissioned; rather, it will be because
that is what is in place, and it will take a while for the DWs and networks
to achieve the power that can obviate it, and for managers to wake up to
that fact.
>COBOL is again, good for that.
Yes, it is. Outstanding, in fact.
And canvas was superb for driving square-rigged sailing vessels.
But you won't find a lot of it on a container ship.
Pete.
| |
| Robert Jones 2007-01-06, 6:55 pm |
|
message snipped
Pete Dashwood wrote
> This, admittedly contrived, example demonstrates quite clearly the
> fundamental difference between event driven (read, "on-line") and
> non-event-driven (read, "batch") processing. OO lends itself to event driven
> processing; procedural programming doesn't. That is why OO is taking over
> the world... (whether the people using it understand this or not... all they
> know is that Objects are flexible and responsive and designed to handle
> events; procedural code simply isn't...)
>
While I can believe that COBOl will eventually be retired, I don't
believe batch processing will ever completely go away. Events such as
are invoked by as tax authorities wanting yearly company accounts and
tax computations are probably too much to suddenly throw at an on-line
system, there would probably be severe degradation of service, even if
many of the underlying figures had already been calculated. Events
such as monthly/wly payrolls, cheque printing, etc also are probably
best done in a batch process.
I would also add that while the "we have always done it that way"
factor can be an obstacle, one also has to consider whether it is worth
the effort in making the change unless there is a perceived benefit in
changing something that already works, and who is going to provide the
budget and manpower to implement a new system.
Robert
| |
|
| Howard Brazee wrote:
> On Thu, 28 Dec 2006 14:34:05 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I see lots of shops going with data warehouses on one side, and
> on-line transactions on the other side - with interfaces between the
> web servers accessing both. Where is batch CoBOL needed in that?
Batch COBOL could still be used to deal with the data in the warehouse,
and present it in an orderly fashion. However, ad-hoc query tools are
bit quicker, and don't have to be compiled. (Well, the tool does, but
the different queries don't. ;> )
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
|
| Robert Jones wrote:
> message snipped
>
> Pete Dashwood wrote
>
>
> While I can believe that COBOl will eventually be retired, I don't
> believe batch processing will ever completely go away. Events such as
> are invoked by as tax authorities wanting yearly company accounts and
> tax computations are probably too much to suddenly throw at an on-line
> system, there would probably be severe degradation of service, even if
> many of the underlying figures had already been calculated. Events
> such as monthly/wly payrolls, cheque printing, etc also are probably
> best done in a batch process.
This is a good question. How would these processes be handled in an
"on-line" way? I know you wouldn't have to actually have to calculate
payroll until it was time to generate the direct deposit/print the
che[ck|que], but doing this serially for all active employees on a
certain date would seem to be, at best, "online with a driver."
Pete, What would be your online vision of how this would take place?
(You know, once you're done with the beach party and all...) ;)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
|
| |