Cobol - *LARGE* COBOL programs - new SHARE requirement

Author

*LARGE* COBOL programs - new SHARE requirement

William M. Klein

2004-05-18, 9:30 pm

I thought my note to IBM-MAIN might be of interest to some in other newsgroups.

FYI ..

> To: IBM-MAIN (with various BCC's including the LNGC distribution list)
>
> As a follow-on to a current IBM-MAIN thread, I have just created (and placed
> into the OPEN FOR DISCUSSION category) a new SHARE requirement for "better
> handling" of LARGE COBOL programs. It is already available for discussion -
> and should get a new SHARE requirement number tomorrow.
>
> I *doubt* that "we" can discuss, vote on, and get a response from IBM by the
> NYC SHARE in August. However, if I see "lots" of positive discussion
> quickly, I will try and move it along as quickly as possible.
>
> For those of you who work for (are related to?) SHARE installations but you
> are not currently participating in the LNGC requirement process, please see:
>
> http://home.netcom.com/~wmklein/IBM...%20-%20LNGC.htm
>
> The wording of the requirement in question begins:
>
> - Remove restriction - compiling and optimizing large programs
>
> - The restrictions on the OPT compiler option documented in APAR PQ74496
> should be removed - not only for VisualGEN produced COBOL source code, but
> for any "generated" COBOL source code that does not violate the "size of
> program" limit documented at:
>
>
http://publibz.boulder.ibm.com/cgi-...R20/APPENDIX1.2
>
> as:
> Size of program 999,999 lines
>
> Furthermore, the PGT, TGT, and any other relevant internal "tables" should
> be expanded to handle such large programs with and without the OPT compiler
> option - thereby significantly "increasing the limit" documented as:
>
> Procedure and constant area 4,194,303 bytes
>
> and reflected in compiler message
>
> IGYXX5159-U Procedure plus constant area exceeded 4 megabytes. "PGT"
> capacity was exceeded.
>
> - The "requirement" (permanent restriction) documented in PQ74496 which
> states,
>
> "Problem conclusion
> COBOL code produced by CSP and VisualGen should never be compiled with
> OPTIMIZE, since it takes lots of resource and provides no benefit."
>
> is unacceptable (especially when it reflects an inadequate interface between
> two IBM products) - as is the restriction reflected in compile-time message:
>
> IGYXX5159-U Procedure plus constant area exceeded 4 megabytes. "PGT"
> capacity was exceeded.
>
> In this day and age when a growing number of COBOL programs are created by
> "tools" which generate COBOL source code (and, hence, the code may not be
> directly modified by any application programmer) - and when such features as
> OO, XML, and other "modern" programming interfaces may require VERY large
> source programs, it is imperative that COBOL programs not have artificially
> small internal limits - even if these limitations are hit infrequently they
> are, nevertheless often enough experienced to be encountered by multiple
> shops and for multiple applications.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

James J. Gavan

2004-05-19, 1:30 am

William M. Klein wrote:

>I thought my note to IBM-MAIN might be of interest to some in other newsgroups.
>
> FYI ..
>
>
>
<snip>
[color=darkred]
I must chide you, even if somewhat gently, on your above statement.
Although you've never been negative about the Standard including OO
syntax, as you've indicated many times, you haven't bought into OO. Well
if you Big Boys on the Big Iron want LARGE programs so be it, with the
attendant LARGE MAINTENANCE..

I'm not clear if the quote about large OO progrms is fro m you or from
the IBM quote, earliert in the text - nevertheless whoever wrote it -
But you(tehy) are totally, totally wrong about needing LARGE OO
programs (classes). It's still my contention the major buzz word for OO
is *REUSE* - and essentially you only obtain that by (1) fragmenting a
LARGE program into a set of specific classes to do specific functions,
and (2) For each separate class, where possible, segment it into small
discrete, (and very often 'bland') methods.

Example # 1 - in response to your message about Nested Programs -
re-entrant/recursive/iterative - whatever......

(a) Class TabbedDialog - a generic template that does all the donkey
work for setting up controls in any Dialog
(b) I showed the code for DropListDialog, (where I want to colour the
droplists), which inherits from (a)

Using the Large program concept why not include (b) in (a) - after all
(a) currently only contains just over 86 methods and the top limit is
1,000. Reasons for not doing it (1) I might want to fine-tune (b) and
could screw myself if it was included in (a).
Reason # 2 - not every dialog has droplists, or again I might not want
to colour them - that gives me two choices :-

- may or may not contain droplists but NO colouring :-

invoke TabbedDialog (which inherits from Modal or Modeless)
"start" using .......... returning os-Dialog, OR

- I want a dialog with a coloured DropList :-

invoke DropListgDialog (which inherits from TabbedDialog)
"start"using ....... returning os-Dialog

I should mention that initializing GUIs in M/F is the exception. You
can't invoke "new" - it goes belly up inheriting from Modal or Modeless.
So you call your "new" whatever you want - invoke "startIt" "BeginIt"
"makeIt", whatever .......

Example # 2 :

I didn't show the code for TabbedDialog, but it does contain 'bland'
methods, (if we want to get academic, polymorphic methods). I have left
in the code for two of them, so that you get the idea what the rest are
doing :-

Method-id. "checkChangedFlag".
Method-id. "ElementChanged".
Method-id. "finalizeObjects".
Method-id. "getCoordinates".
Method-id. "returnObjectFromField".
Method-id. "setAsEmpty".
Method-id. "setClear".
*>--------------------------------------------------------------
Method-id. "setDisable".
*>--------------------------------------------------------------
Linkage section.
copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.

Procedure Division using lnk-Params.

invoke os-DialogCollection(1) "at"
using lnk-field returning lnk-object
invoke lnk-object "disable"

End Method "setDisable".
*>--------------------------------------------------------------
Method-id. "setDisableClear". *> used for RadioButtons
*>--------------------------------------------------------------
Linkage section.
copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.

Procedure Division using lnk-Params.

invoke os-DialogCollection(1) "at"
using lnk-field returning lnk-object
invoke lnk-object "disable"
invoke lnk-object "clear"

End Method "setDisableClear".
*>--------------------------------------------------------------
Method-id. "setDisableEmpty".
Method-id. "setEnable".
Method-id. "setEnableEmpty".
Method-id. "setFocusDefault".
Method-id. "SetGainedFocus".
Method-id. "setHide".
Method-id. "setHideDisable".
Method-id. "setNextFocusClear". *> for DropLists/Radiobuttons
Method-id. "setNextFocusEmpty".
Method-id. "setNextFocusInsert".
Method-id. "setRecordFlags".
Method-id. "setRGBColors".
Method-id. "setSelectedUnselected".
Method-id. "SetTheColor".
Method-id. "setTheFocus".
Method-id. "SetTheLength".
Method-id. "showControl".

So out of my total methods, some 86, (which include creating controls
and event callback methods), there are 26 which fit into the 'bland'
category and for the most part are applicable to every GUI control created.

Recall all those "includes..." you see in C programs - which of course
are paralleled in OO by M/F's Class-Control or 2002 Repository
(Repository *IS* in N/E V 4.0) - I have all of the necessary GUI classes
listed in TabbedDialog - and that's the only place they appear in an
application.

Example # 3 - I illustrated to Daniel (X-Li) about using a super to
"getIndexFromKey" or "getKeyFromIndex" in a droplist collection. It
didn't start out that way. Softly, softly, catchee monkee. Each
individual DBI (Database Interface) had its own version of the two
methods above, plus the initialization code to create
collections/dictionaries. As I worked my way through there came an
awareness that so much was 'common routines' - that's when I hit on the
idea of a super class DbiMain with appropriate sub-classes DbiThis or,
DbiThat inheriting the resources in DbiMain.

Granted, splitting a problem into many classes, you still have a fair
sized system, but with stringent testing of each inherited class, (i.e.
the class deasignated as the SUPER) you have reduced your testing when
making future invocations for new classes/objects. Once you start
'inheriting', particularly 'bland/polymorphic' methods - I have no way
of guaging, but would suggest a saving of something like 20% on
repetitive code.

No way ! - if you are using big iron or small iron - you do NOT need
LARGE OO programs. If they are LARGE, I'll put my money on it - your
thinking/design is dead wrong.

Jimmy, Calgary AB

William M. Klein

2004-05-19, 11:30 am

I agree with you Jimmy that an OO "application" can (and POSSIBLY should) be
made up of "relatively" small classes. However, I also believe that some -
especially any created by "high-level" design interfaces are NOT.

The same is true for applications for handling XML.

--
Bill Klein
wmklein <at> ix.netcom.com
"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:bOBqc.501401$Pk3.37699@pd7tw1no...
> William M. Klein wrote:
>
newsgroups.[color=darkred]
> <snip>
>
> I must chide you, even if somewhat gently, on your above statement.
> Although you've never been negative about the Standard including OO
> syntax, as you've indicated many times, you haven't bought into OO. Well
> if you Big Boys on the Big Iron want LARGE programs so be it, with the
> attendant LARGE MAINTENANCE..
>
> I'm not clear if the quote about large OO progrms is fro m you or from
> the IBM quote, earliert in the text - nevertheless whoever wrote it -
> But you(tehy) are totally, totally wrong about needing LARGE OO
> programs (classes). It's still my contention the major buzz word for OO
> is *REUSE* - and essentially you only obtain that by (1) fragmenting a
> LARGE program into a set of specific classes to do specific functions,
> and (2) For each separate class, where possible, segment it into small
> discrete, (and very often 'bland') methods.
>
> Example # 1 - in response to your message about Nested Programs -
> re-entrant/recursive/iterative - whatever......
>
> (a) Class TabbedDialog - a generic template that does all the donkey
> work for setting up controls in any Dialog
> (b) I showed the code for DropListDialog, (where I want to colour the
> droplists), which inherits from (a)
>
> Using the Large program concept why not include (b) in (a) - after all
> (a) currently only contains just over 86 methods and the top limit is
> 1,000. Reasons for not doing it (1) I might want to fine-tune (b) and
> could screw myself if it was included in (a).
> Reason # 2 - not every dialog has droplists, or again I might not want
> to colour them - that gives me two choices :-
>
> - may or may not contain droplists but NO colouring :-
>
> invoke TabbedDialog (which inherits from Modal or Modeless)
> "start" using .......... returning os-Dialog, OR
>
> - I want a dialog with a coloured DropList :-
>
> invoke DropListgDialog (which inherits from TabbedDialog)
> "start"using ....... returning os-Dialog
>
> I should mention that initializing GUIs in M/F is the exception. You
> can't invoke "new" - it goes belly up inheriting from Modal or Modeless.
> So you call your "new" whatever you want - invoke "startIt" "BeginIt"
> "makeIt", whatever .......
>
> Example # 2 :
>
> I didn't show the code for TabbedDialog, but it does contain 'bland'
> methods, (if we want to get academic, polymorphic methods). I have left
> in the code for two of them, so that you get the idea what the rest are
> doing :-
>
> Method-id. "checkChangedFlag".
> Method-id. "ElementChanged".
> Method-id. "finalizeObjects".
> Method-id. "getCoordinates".
> Method-id. "returnObjectFromField".
> Method-id. "setAsEmpty".
> Method-id. "setClear".
> *>--------------------------------------------------------------
> Method-id. "setDisable".
> *>--------------------------------------------------------------
> Linkage section.
> copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.
>
> Procedure Division using lnk-Params.
>
> invoke os-DialogCollection(1) "at"
> using lnk-field returning lnk-object
> invoke lnk-object "disable"
>
> End Method "setDisable".
> *>--------------------------------------------------------------
> Method-id. "setDisableClear". *> used for RadioButtons
> *>--------------------------------------------------------------
> Linkage section.
> copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==lnk==.
>
> Procedure Division using lnk-Params.
>
> invoke os-DialogCollection(1) "at"
> using lnk-field returning lnk-object
> invoke lnk-object "disable"
> invoke lnk-object "clear"
>
> End Method "setDisableClear".
> *>--------------------------------------------------------------
> Method-id. "setDisableEmpty".
> Method-id. "setEnable".
> Method-id. "setEnableEmpty".
> Method-id. "setFocusDefault".
> Method-id. "SetGainedFocus".
> Method-id. "setHide".
> Method-id. "setHideDisable".
> Method-id. "setNextFocusClear". *> for DropLists/Radiobuttons
> Method-id. "setNextFocusEmpty".
> Method-id. "setNextFocusInsert".
> Method-id. "setRecordFlags".
> Method-id. "setRGBColors".
> Method-id. "setSelectedUnselected".
> Method-id. "SetTheColor".
> Method-id. "setTheFocus".
> Method-id. "SetTheLength".
> Method-id. "showControl".
>
> So out of my total methods, some 86, (which include creating controls
> and event callback methods), there are 26 which fit into the 'bland'
> category and for the most part are applicable to every GUI control created.
>
> Recall all those "includes..." you see in C programs - which of course
> are paralleled in OO by M/F's Class-Control or 2002 Repository
> (Repository *IS* in N/E V 4.0) - I have all of the necessary GUI classes
> listed in TabbedDialog - and that's the only place they appear in an
> application.
>
> Example # 3 - I illustrated to Daniel (X-Li) about using a super to
> "getIndexFromKey" or "getKeyFromIndex" in a droplist collection. It
> didn't start out that way. Softly, softly, catchee monkee. Each
> individual DBI (Database Interface) had its own version of the two
> methods above, plus the initialization code to create
> collections/dictionaries. As I worked my way through there came an
> awareness that so much was 'common routines' - that's when I hit on the
> idea of a super class DbiMain with appropriate sub-classes DbiThis or,
> DbiThat inheriting the resources in DbiMain.
>
> Granted, splitting a problem into many classes, you still have a fair
> sized system, but with stringent testing of each inherited class, (i.e.
> the class deasignated as the SUPER) you have reduced your testing when
> making future invocations for new classes/objects. Once you start
> 'inheriting', particularly 'bland/polymorphic' methods - I have no way
> of guaging, but would suggest a saving of something like 20% on
> repetitive code.
>
> No way ! - if you are using big iron or small iron - you do NOT need
> LARGE OO programs. If they are LARGE, I'll put my money on it - your
> thinking/design is dead wrong.
>
> Jimmy, Calgary AB

James J. Gavan

2004-05-19, 3:30 pm

William M. Klein wrote:

>I agree with you Jimmy that an OO "application" can (and POSSIBLY should) be
>made up of "relatively" small classes. However, I also believe that some -
>especially any created by "high-level" design interfaces are NOT.
>
>
>
Are you here referring to program generators, for want of a name, (SAS,
SAP or whatever) ? Being omnibus, it's natural they would generate a
lot of code - but in the case of SAP I recall an early statement from
Donald that it was a proprietary language. (That fits in with when it
was being implemented at one of his former clients, they had to type him
a cheque for his 'services' because the SAP application wasn't ready
:-) ). Perhaps with your Share background you are aware of program
generators specifically written in COBOL ? (Just a thought - they could
always go back to using Segmentation !).

>The same is true for applications for handling XML.
>
>
>
As yet I know nothing of XML, other than looking at RM/Liant's manual -
they did a pretty good job. I think I'm correct, but I believe it was
Richard who wrote that XML was no big deal, the XML standard has a fixed
template layout. Design your application so that you can fill in the
pieces. From an OO perspective the prime template is in a class of its
own, (or perhaps more accurately a 'template' file), and the 'pieces'
are, as necessary, in their own separate classes or more likely,
retrieved from files or DB Tables. If I get there, subject to viability,
I'd do my damnedest to take that approach.. Again such an approach
allows you to 'fragment' into smaller classes/programs.

You still come up with a caveat, "(and POSSIBLY should)". I wrote some
time back that there was a Net Express developer who came unstuck
because he wanted to add method # 1,001 onwards. I haven't seen his code
- but it's a fair bet he took the basic OO syntax template and wrapped
it around a procedural program turning PERFORMS into methods. I wouldn't
be at all surprised to find out that he was also using SECTIONS in
methods as well !!! Surprisingly, Simon who is a real whiz at the
graphical interface stuff, produces fairly large methods and uses
SECTIONS. That's in part attributable to the techniques he learned from
procedural COBOL. (You may recall that having adapted very early on to
the SECTION concept, Pete still prefers to have SECTIONS in OO). I've
never questioned him, (Simon), but probably the following is relevant.
Being in a development shop, (I'd guess there might be 6 or 12
programmers), the operative phrase is "get it out now" - and unlike
myself, that just doesn't allow time for them to ruminate and think
about shortcut techniques, i.e.'supers' with sub-classes inheriting..

BTW - back to that DroplistDialog - another very good reason I hived it
off as a separate class. Take a look at the very first line "copy
windows.cpy" - that is an absolute monster containing 28,215 lines of
source and includes every typedef or hex value you would want to use
with calls to Win APIs. Boy, does that slow down compilation of the
DroplistDialog class. Included in the 'super' TabbedDialog, it would
drive me nuts on re-compilations. (Because those windows.cpy routines
are so integrated I doubt there's much M/F could do to segment into a
hierarchical set of copyfiles).

The following is pure conjecture because I don't know the mechanism, but
you may well have some insight from your M/F days. N/E has a neat
feature I really like - it obviously puts a date/time stamp on source,
including copyfiles.

1 - I change a comment line and re-compile - BLIP - it's done in
seconds. The compiler doesn't really give a damn about comment lines.
2 - I change a source program - I can either 'compile this' or "compile
project' - done in a very short time - seconds.
3 - I want a change in a copyfile used with this particular program -
'compile project' - picks up and recompiles all programs affected by the
copyfile change.

One would have thought that windows.cpy fits into # 3 - apart from which
it is NEVER changed. I can only guess, because of its size, the compiler
does a thorough check on the copyfile syntax, and perhaps somewhat like
the REPOSITORY concept, forward checks your source code to see which
variables etc you need from windows.cpy ?????

Jimmy, Calgary AB

Richard

2004-05-19, 9:30 pm

"James J. Gavan" <jjgavan@shaw.ca> wrote

> (or perhaps more accurately a 'template' file),

I do a lot of stuff using template files. Then I don't care whether
the output is XML, HTML, EDIFAC, or simple text. One of the
advantages of having OO for this is that I can create two template
objects at the same time.

The latest project that I did was picking up EMail from a POP3 server,
extracting the attachments which are Excel .xls files, processing the
rows in each sheet by matching up on the headings and outputting the
delivery orders (by change of order number) into templated EDIFAC
files in various directories for the warehouse management systems to
collect.

Because the templating is a class I can also create a summary reply
EMail at the same time using a different template file and then at the
end of the xls file SMTP this to a list of receivers (including
warehouse managers, IT Manager and originating client) as
confirmation.

(it was actually done in Python, but same thing).

James J. Gavan

2004-05-20, 4:30 am

Richard wrote:

>"James J. Gavan" <jjgavan@shaw.ca> wrote
>
>
>
>
>I do a lot of stuff using template files. Then I don't care whether
>the output is XML, HTML, EDIFAC, or simple text. One of the
>advantages of having OO for this is that I can create two template
>objects at the same time.
>
>The latest project that I did was picking up EMail from a POP3 server,
>extracting the attachments which are Excel .xls files, processing the
>rows in each sheet by matching up on the headings and outputting the
>delivery orders (by change of order number) into templated EDIFAC
>files in various directories for the warehouse management systems to
>collect.
>
>Because the templating is a class I can also create a summary reply
>EMail at the same time using a different template file and then at the
>end of the xls file SMTP this to a list of receivers (including
>warehouse managers, IT Manager and originating client) as
>confirmation.
>
>(it was actually done in Python, but same thing).
>
>
Whoa there Richard, that's the first time you've used the magic word
'OO' to my knowledge. I know you have a complete box of tricks down
there, somewhat like Aladdin and his forty jars - specifically which
languages are you using for OO - is Python in fact OO ?

On the 'template' bit one thing I have done, but by no means clean and
comprehensive as yet, was to generate a source template for "Edit x" x =
Customer, Chart-of-Accounts etc.

I have no doubt, you follow a similar approach - the majority of your
'edit' programs follow the same pattern - mine of course is geared to a
class approach

- (1) Having determined my own particular pattern as to the sequencing
of an Edit program, I have a 'generic' source of that program with
'markers' and areas left blank - much like you have written in the past
that you weren't happy with Screen Sections and you have arrived at your
own design tool.

- (2) The next step is to do a line sequential read against the Micro
Focus generated Resource File from Dialog Editor information (see
footnote) picking up on all the controls and generating (2a) another
class source - DialogParameters which lists the controls in order by
their ID's (Level 88's) and (2b) a separate copyfile of those Level
88's. Bearing in mind I was unaware of the concept of Dialog System when
I started with VISOC - to my surprise I found I had re-invented the
wheel - Dialog System uses the same approach, giving each field a
numbered identity and name (which you would know from your familiarity
with M/F products).

- (3) Now a sequential read of the Edit template, using the information
generated in (2) is used to include method names in the generated
'Editxxxx' class. These same 'return' method names, also included in
DialogParameters are passed as parameters to create a dialog instance
from the generic Dialog template class.

Now to the Edit program's sequence :-

- (4) File/DB Table housekeeping - identify external names and either
OPEN or CONNECT
- (5) create any lists (collections) needed for Droplists, Litboxes,
Treeviews, Listviews etc.
- (6) Pass parameters to the generic Dialog as required - see (3) above.

The Edit class - having included methods with 'header and footer', plus
reference to a standard copy file in the return methods, gives you a
pretty good, typo-free checklist. Naturally you have to go in and hand
code to make things specific - such as validity checks. for dialog
return values. While the technique can be generalised, in both our cases
our output is to our personal liking. That's where those BIG program
generators fail, they are so generalised, trying to be everybody's
friend, of necessity they generate a lot of superfluous code, or
possibly take you down a pretty convoluted route of condition/decision
tables to generate what you are really after

I'm not demeaning your approach on inventory above, which I grasp, but
that is a fairly standard one you can take a template approach to. (You
*naughty man* - I see you used the word Excel - Jerry will be pleased
=-O ) Have you attempted templates/decision tables for things like
Payroll etc. I get the impression that for the small guy to explore and
design program generators for applications like that, all the time you
put into the generator, and it is probably never finite - you might just
as well be writing the intended resultant code. Most likely you got that
finished and thoroughly tested before a decision generator has even
started to flap its wings, let alone get off the ground !

What's your take on storage ?. I don't consider BIG is BEAUTIFUL; many
have taken the approach, what the hell, storage is cheap just spread the
stuff around guys ! I try to be circumspect on storage, keeping things
as compact as possible I'm using Win 98 with 14 GBs - not at all big
compared with current disk options, but when I use Norton to do a disk
clean-up the resulting graphic picture shows that I use less than 30 %
of disk space.

BTW - how's your female PM making out down there with the Maoris - have
you 'nationalised' the seashore yet . It appeared here as a brief
paragraph and nothing since.

Footnote : From time to time I have made reference to the M/F Dialog
Editor as opposed to the Dialog System, a separate M/F tool which a
number of people here are familiar with from their former M/F days.. If
curious at all about Dialog Editor, search the Windows directory for
\mstools\bin\dlgedit.exe - the M/F version is an extension of what you
see in the MS product.

Jimmy, Calgary AB

Richard

2004-05-20, 4:30 pm

"James J. Gavan" <jjgavan@shaw.ca> wrote

> Whoa there Richard, that's the first time you've used the magic word
> 'OO' to my knowledge.

I can't disagree about what your knowledge is ;-)

> is Python in fact OO ?

Yes.

> I'm not demeaning your approach on inventory above, which I grasp, but
> that is a fairly standard one you can take a template approach to. (You

It seems that you are using templating to generate code, which I have
done, but isn't what I took your 'templating' as.

fixed[color=darkred]
the[color=darkred]
its[color=darkred]

Rereading this it seems that you are building the 'template' into the
code (or generating code from the template) such that it becomes a
fixed layout until the program is recreated and recompiled.

I don't do that. A class handles text templates to create the output.
It will handle most any templates. A template may be:

:header
UNA:+.? '
UNB+UNOB:2+DRINKCO:ZZ+94108810LFXNA:ZZ+<!%datenow%>:<!%timenow%>+<!%number%>'
UNH+<!%number%>+INSDES:D:97A:UN'
BGM+220::6:INSDES+<!%orderno%>+9'
DTM+2:20<!%reqdate%>:102'
DTM+4:20<!%orddate%>:102'
RFF+VN:<!%orderno%>'
RFF+UO:<!%custref%>'
NAD+ST+<!%custid%>::91+<!%address1%>:<!%address2%>:<!%address3%>+<!%custname%>++++<!%zone%>'
FTX+ADU++1+<!%instruct%>'
:lineitem
LIN+<!%lineno%>+1'
PIA+1+<!%product%>:::91'
IMD+++<!%unit%>:::<!%descrip%>'
QTY+21:<!%quantity%>'
RFF+IL:<!%orderno%>?:<!%line%>'
RFF+BT:<!%batch%>'
:trailer
UNS+S'
CNT+2:<!%lineno%>'
UNT+<!%segcount%>+<!%number%>'
UNZ+1+<!%number%>'

Or it may be

:header
To: <!%sendto%>
From: <!%username%>@<!%pop3%>
Subject: File <!%filename%>
<!%%>
This file is being processed by <!%system%>, version <!%version%>
<!%%>
.. DC OrderNum Line Product Quantity
.. ------------------------------------
:lineitem
.. <!%location%> <!%orderno%> <!%line%> <!%product%>
<!%quantity%>
:trailer
<!%%>
Disclaimer:
The information in this electronic mail message together with any
attachments is confidential. It is intended solely for the addressee.
Access to this Internet electronic mail message by anyone else is
unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it is prohibited and may be unlawful.
<!%%>
<!%company%> accepts no responsibility for any effects this email
message or
attachments has on the recipient network or computer system.
<!%%>
End of message 20<!%datenow%> <!%timenow%>
------------------------------------------------------

In fact these are two that are used.

If the user wants to change the output then they use a text editor and
change it and, well, it will just work. If they want XML or HTML or
plain text they can do that too. In fact I can do postscript
templates too, but that is a two stage process.

The advantages of having an OO Class do this, over say called
programs, is that the program can output both of the templates above
concurrently _without_ worrying about re-entrancy problems.
[color=darkred]
> *naughty man* - I see you used the word Excel - Jerry will be pleased

Actually I had no control over what was used, I think SAP is
generating the file then the client fiddles it and EMails it. I would
prefer they used gnumeric or OpenOffice, but its not a big deal. At
the warehouse end it is all automatic being triggered by the arrival
of data in the inbox the program is monitoring.

> =-O ) Have you attempted templates/decision tables for things like

I did use Decision Tables on the ICL 1900 in the early 70s.

> BTW - how's your female PM making out down there with the Maoris - have
> you 'nationalised' the seashore yet . It appeared here as a brief
> paragraph and nothing since.

Still arguing, back biting, threatening. SNAFU.

James J. Gavan

2004-05-20, 5:30 pm

Richard wrote:

>It seems that you are using templating to generate code, which I have
>done, but isn't what I took your 'templating' as.
>
>
You are right. But template is such a generic word. Remember the ICL
flowchart template - I've still got one kicking around.

No I don't currently use a template as you are which is part of your
inter-active application. I thought it over, and although intrigued, I
really can't think of a requirement for that approach at the moment -
but I can see it is bloody useful. Taking a cursory look at that RPV
report writer, it appears to be using a template approach where you feed
it with a block of data in a pre-defined format.

My approach to templates is twofold :-

- the program generator, where if you like I have a 'mask' of a source
file to be re-written as a new output source, (repeating the 'chunks'
that don't need to be changed) and using 'markers' to insert new method
syntax. Strictly speaking it is not a 'program generator' but a
'program copier', updated with the methods applicable to the current
problem.

- the other which I described to Bill in this thread is a template or
general purpose/polymorphic class for dialoging. An all-purpose class
accepting input and returning event results, regardless of the dialog's
shape or controls involved. Similarly I have templates for handling the
four COBOL file types, generating as many instances as are currently
required..

Jimmy, Calgary AB

Sponsored Links