Home > Archive > Cobol > September 2005 > command line arguments like on mainframe under fujitsu
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]
| Author |
command line arguments like on mainframe under fujitsu
|
|
|
| I am migrating cobol code from mainframe to fujitsu .net cobol.
On the mainframe, a program called from within a jcl received the
parameter via the linkage section, as shown below:
LINKAGE SECTION
01 PARM.
05 PARM-LEN PIC S999 COMP.
05 PARM-TXT.
10 PIC X OCCURS 0 TO 100 DEPENDING ON PARM-LEN.
When I trry compiling a program to use this feature, I get the
following error message:
JMN5701I-S In the PROCEDURE DIVISION header of the program specified
for compile option /main, USING phrase and RETURNING phrase cannot be
specified.
I have seen a few code examples where command line arguments are passed
via "accept .... from command-line-value" where command-line-value is
defined in the "special names" section. I would prefer not to use this
option, as it would mean changing many programs.
I have 2 questions:
a/ Can I receive the command line argument as I did on the mainframe?
b/ If the answer to "a" is yes, what am I doing wrong - how do I avoid
the error message I received?
| |
| Binyamin Dissen 2005-09-05, 6:55 pm |
| On 5 Sep 2005 09:02:22 -0700 "ari" <unikoski@yahoo.com> wrote:
:>I am migrating cobol code from mainframe to fujitsu .net cobol.
:>On the mainframe, a program called from within a jcl received the
:>parameter via the linkage section, as shown below:
:> LINKAGE SECTION
:> 01 PARM.
:> 05 PARM-LEN PIC S999 COMP.
:> 05 PARM-TXT.
:> 10 PIC X OCCURS 0 TO 100 DEPENDING ON PARM-LEN.
:>When I trry compiling a program to use this feature, I get the
:>following error message:
:>JMN5701I-S In the PROCEDURE DIVISION header of the program specified
:>for compile option /main, USING phrase and RETURNING phrase cannot be
:>specified.
:>I have seen a few code examples where command line arguments are passed
:>via "accept .... from command-line-value" where command-line-value is
:>defined in the "special names" section. I would prefer not to use this
:>option, as it would mean changing many programs.
:>I have 2 questions:
:>a/ Can I receive the command line argument as I did on the mainframe?
:>b/ If the answer to "a" is yes, what am I doing wrong - how do I avoid
:>the error message I received?
The easiest approach may be to create an envelope main program which will do
the ACCEPT, format it like the MVS plist, and then call the real main program.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
| |
| William M. Klein 2005-09-05, 9:56 pm |
| Micro Focus provides support for this "compatibility" feature as does (I think)
CA-Realia. Fujitsu does NOT (as far as I know).
--
Bill Klein
wmklein <at> ix.netcom.com
"ari" <unikoski@yahoo.com> wrote in message
news:1125936142.692250.105410@g47g2000cwa.googlegroups.com...
>I am migrating cobol code from mainframe to fujitsu .net cobol.
>
> On the mainframe, a program called from within a jcl received the
> parameter via the linkage section, as shown below:
>
> LINKAGE SECTION
> 01 PARM.
> 05 PARM-LEN PIC S999 COMP.
> 05 PARM-TXT.
> 10 PIC X OCCURS 0 TO 100 DEPENDING ON PARM-LEN.
>
>
> When I trry compiling a program to use this feature, I get the
> following error message:
>
>
> JMN5701I-S In the PROCEDURE DIVISION header of the program specified
> for compile option /main, USING phrase and RETURNING phrase cannot be
> specified.
>
>
> I have seen a few code examples where command line arguments are passed
> via "accept .... from command-line-value" where command-line-value is
> defined in the "special names" section. I would prefer not to use this
> option, as it would mean changing many programs.
>
> I have 2 questions:
> a/ Can I receive the command line argument as I did on the mainframe?
> b/ If the answer to "a" is yes, what am I doing wrong - how do I avoid
> the error message I received?
>
| |
| Richard 2005-09-05, 9:56 pm |
|
ari wrote:
> I have 2 questions:
> a/ Can I receive the command line argument as I did on the mainframe?
No.
Write a small 'MAIN' program that accepts the command line including a
program name to call and the required parameters and then use the name
to call your existing programs which you will have (re)compiled as
dynamically loaded modules.
| |
| HeyBub 2005-09-05, 9:56 pm |
| ari wrote:
> I am migrating cobol code from mainframe to fujitsu .net cobol.
>
> On the mainframe, a program called from within a jcl received the
> parameter via the linkage section, as shown below:
>
> LINKAGE SECTION
> 01 PARM.
> 05 PARM-LEN PIC S999 COMP.
> 05 PARM-TXT.
> 10 PIC X OCCURS 0 TO 100 DEPENDING ON PARM-LEN.
>
>
> When I trry compiling a program to use this feature, I get the
> following error message:
>
>
> JMN5701I-S In the PROCEDURE DIVISION header of the program specified
> for compile option /main, USING phrase and RETURNING phrase cannot be
> specified.
>
>
> I have seen a few code examples where command line arguments are
> passed via "accept .... from command-line-value" where
> command-line-value is defined in the "special names" section. I would
> prefer not to use this option, as it would mean changing many
> programs.
>
> I have 2 questions:
> a/ Can I receive the command line argument as I did on the mainframe?
> b/ If the answer to "a" is yes, what am I doing wrong - how do I avoid
> the error message I received?
Yes, you can. I think.
In PowerCOBOL it's a property of POW-SELF, viz:
MOVE CommandLine of POW-SELF to My-Command-Line.
| |
| Michael Mattias 2005-09-05, 9:56 pm |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1125945880.017388.20870@g47g2000cwa.googlegroups.com...
>
> ari wrote:
>
>
> No.
No?
I would think under Windows your entry point function's third parameter is a
poitner to the command line.
The implied syntax of any Windows EXE's entry point function is
]
ENTRY WINMAIN
USING BY VALUE hInstance
BY VALUE hprevInstance << always zero on Win/32
BY REFERENCE szCommandLine <<< pointer to null terminated
string
BY VALUE iCmdShow
Of course, it might be easier to just call the Windows API function
GetCommandLine(), which returns a pointer to a null-teminated string
containing (if you can believe it) --- the command line.
And of course, I'm not sure if these rules hold under .NET. But it sure
looks worth a try to me before giving up.
MCM
| |
| Richard 2005-09-05, 9:56 pm |
| > >> I have 2 questions:
[color=darkred]
[color=darkred]
> No?
The functional part of the question was: "as I did on the mainframe?"
If you (and Heybub who completely missed the point) read the message
you would see that he knows he can change all his programs to ACCEPT
xxx FROM COMMAND-LINE but "as he did on the mainframe" was with a
linkage section and procedure division using xxx.
Fujitsu requires that a MAIN does not have procedure division using
xxx. I am not even sure that any PC Cobol (perhaps Realia) will pass
the command line "as he did on the mainframe". A simple MAIN that does
the accept and passes this by CALLing the program will emulate the
mainframe way and avoid having to change all his programs.
| |
| Richard 2005-09-05, 9:56 pm |
| >> to fujitsu .net cobol.
> In PowerCOBOL it's a property of POW-SELF, viz:
PowerCobol is _not_ Cobol for .net, nor is it part of Cobol for .net.
> MOVE CommandLine of POW-SELF to My-Command-Line.
Which is completely _not_ "as I did on the mainframe?"
| |
| Arnold Trembley 2005-09-06, 3:55 am |
|
Richard wrote:
>(snip)
> The functional part of the question was: "as I did on the mainframe?"
>
> If you (and Heybub who completely missed the point) read the message
> you would see that he knows he can change all his programs to ACCEPT
> xxx FROM COMMAND-LINE but "as he did on the mainframe" was with a
> linkage section and procedure division using xxx.
>
> Fujitsu requires that a MAIN does not have procedure division using
> xxx. I am not even sure that any PC Cobol (perhaps Realia) will pass
> the command line "as he did on the mainframe". A simple MAIN that does
> the accept and passes this by CALLing the program will emulate the
> mainframe way and avoid having to change all his programs.
>
I can confirm that Realia COBOL version 4.2 for OS/2 and DOS (circa
1992) supported command-line arguments "as he did on the mainframe".
I can't confirm if the current CA-Realia COBOL version supports this,
but it probably would.
--
http://arnold.trembley.home.att.net/
| |
| Michael Mattias 2005-09-06, 7:55 am |
| "Richard" <riplin@Azonic.co.nz> wrote in message
news:1125964278.830277.27390@g43g2000cwa.googlegroups.com...
>
>
>
> The functional part of the question was: "as I did on the mainframe?"
Even though this is *not* on a mainframe?
Oh, never mind, I see. You've endorsed the concept that it's a terrific
idea to decide on a route before you know where you are going.
Good plan.
MCM
| |
| Binyamin Dissen 2005-09-06, 7:55 am |
| On Tue, 06 Sep 2005 11:57:52 GMT "Michael Mattias" <michael.mattias@gte.net>
wrote:
:>"Richard" <riplin@Azonic.co.nz> wrote in message
:>news:1125964278.830277.27390@g43g2000cwa.googlegroups.com...
:>> > >> I have 2 questions:
:>> > >> a/ Can I receive the command line argument as I did on the mainframe?
:>> >> No.
:>> > No?
:>> The functional part of the question was: "as I did on the mainframe?"
:>Even though this is *not* on a mainframe?
Perhaps there is a desire to run in parallel with the same main routine?
That way they can actually change it for business reasons and simply FTP the
updated module to run on the parallel environment.
:>Oh, never mind, I see. You've endorsed the concept that it's a terrific
:>idea to decide on a route before you know where you are going.
So you consider it a better idea to first decide to change to window$ and
afterwards try to figure out what cost savings might occur (the typical
management approach)?
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
| |
| Michael Mattias 2005-09-06, 7:55 am |
| "Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
news:ao1rh1lmbo2ebi5tkvkrigii5l1n3h35d3@
4ax.com...
>
> :>Oh, never mind, I see. You've endorsed the concept that it's a terrific
> :>idea to decide on a route before you know where you are going.
>
> So you consider it a better idea to first decide to change to window$ and
> afterwards try to figure out what cost savings might occur (the typical
> management approach)?
While you could have anticipated a 'management-like' response from me (after
all, I was a (non-IT) professional manager for twenty years before I
changed careers), I assure you I have never been guilty of making a decision
like that BEFORE looking at the economics.
I see this kind of thing all the time on programming-related newgroups and
BBSs - deciding *how* to do something and then s ing help with the method,
instead of asking for alternatives to the "how."
Of course, sing help with the "how" first requires a solid understanding
of the "what," which understanding is often the weakest link in the entire
applications development chain.
Oh, if only programmer/analyst/developers would spend some time in the Real
World - working at a sales/service desk, on the shop floor or loading dock,
or in the accounting office - there would be a lot more quality application
suites in this world.
MCM
| |
| docdwarf@panix.com 2005-09-06, 6:55 pm |
| In article <63gTe.1061$jE2.373@newssvr19.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
>"Binyamin Dissen" <postingid@dissensoftware.com> wrote in message
> news:ao1rh1lmbo2ebi5tkvkrigii5l1n3h35d3@
4ax.com...
>
>While you could have anticipated a 'management-like' response from me (after
>all, I was a (non-IT) professional manager for twenty years before I
>changed careers), I assure you I have never been guilty of making a decision
>like that BEFORE looking at the economics.
Mr Mattias, with all due respect... as my Sainted Paternal Grandfather -
may he sleep with the angels! - used to say, 'Never use yourself as a
comparative... you'll only be disappointed.'
>
>I see this kind of thing all the time on programming-related newgroups and
>BBSs - deciding *how* to do something and then sing help with the method,
>instead of asking for alternatives to the "how."
I've seen this thing in a few shops for Fortune 100-sized organisations...
'My boss says 'all ya gotta do is...' and now it's up to me to show that
she's right.'
[snip]
>Oh, if only programmer/analyst/developers would spend some time in the Real
>World - working at a sales/service desk, on the shop floor or loading dock,
>or in the accounting office - there would be a lot more quality application
>suites in this world.
It might help... but again, I've worked in shops where coders are
forbidden to contact users unless a Formal Meeting - with management
representation - is called. I remember reading about some company or
other that was having difficulties with order processing... the system
would generate pick-lists for the order-filling-folks but it took a Goodly
Long Time for the folks to fill the order. Their DDP (Director of Data
Processing) got in contact with the DDP at L L Bean's - a company which is
known for delightfully efficient order processing and one with which the
company in question was not in competetion - and asked for hints.
The tip was... go into the stockroom and look at how the bins were
organised. If necessary re-label the bins or re-organise the stockroom
but the key is to first sort your pick-list in bin order; this cuts down
on 'walking-around time' and speeds order fulfillment.
(Now getting the stockroom reorganised is not always the easiest task; a
buddy o' mine heard the manager at his place of employment once say 'Our
people are used to things being in certain places, they won't be able to
learn a new order.')
DD
| |
| Michael Mattias 2005-09-06, 6:55 pm |
| <docdwarf@panix.com> wrote in message news:dfk4ju$s3u$1@panix5.panix.com...
and[color=darkred]
method,[color=darkred]
>
> I've seen this thing in a few shops for Fortune 100-sized organisations...
> 'My boss says 'all ya gotta do is...' and now it's up to me to show that
> she's right.'
>
> ...
> It might help... but again, I've worked in shops where coders are
> forbidden to contact users unless a Formal Meeting - with management
> representation - is called.
I'm not defending these practices.
I have way to much respect for Real Users to endorse throwing any more crap
on the dung heap.
MCM
| |
| HeyBub 2005-09-06, 6:55 pm |
| Richard wrote:
>
>
> PowerCobol is _not_ Cobol for .net, nor is it part of Cobol for .net.
Really? Well I'll be damned!
>
>
> Which is completely _not_ "as I did on the mainframe?"
Oh. Sorry.
Inasmuch as what you were doing on the mainframe didn't work, I thought you
were trying to accomplish the same result, not use the exact same process.
If you are dedicated to doing things exactly the same way as you did on the
mainframe, I suggest you keep using the mainframe.
| |
| Richard 2005-09-06, 6:55 pm |
| > not use the exact same process.
It is quite clear that he wanted to use exactly the same source code
and avoid having to change all his programs. Given that he had stated
an alternative that would actually work with his compiler he wasn't
sing other, different, ways of doing this.
| |
| Richard 2005-09-06, 6:55 pm |
| > Even though this is *not* on a mainframe?
Actually, if you read and understood the question you would have seen
that the code _is_ on a mainframe:
"""I am migrating cobol code from mainframe to fujitsu ..."""
> Oh, never mind, I see. You've endorsed the concept that it's a terrific
> idea to decide on a route before you know where you are going.
Actually, if you read and understood the question you would have seen
that the "route" is to minimise changes to the code:
""".. accept ... I would prefer not to use this option, as it would
mean changing many programs."""
He may even be able to wind up with one set of sources that runs on
both environments thus keeping costs down.
> Good plan.
The 'plan' that I provided was a solution that did meet his expressed
preference of not changing all his programs and provided a compatible
way of passing the command lines.
> I assure you I have never been guilty of making a decision like that
> BEFORE looking at the economics.
Is that right ? You just suggested that he change the source code of
all the programs to something that was Windows specific, ensuring that
it was now non-portable, would no longer work on its existing
environment, and would require further changing to move to other
systems.
Just like a manager: skip the body of the message, read the summary,
and provide pre-packaged solutions regardless of whether it is
appropriate.
| |
|
| Michael Mattias wrote:
> "Richard" <riplin@Azonic.co.nz> wrote in message
> news:1125964278.830277.27390@g43g2000cwa.googlegroups.com...
>
>
> Even though this is *not* on a mainframe?
Sure - porting code without having to "change every program" was one of
his stated goals.
> Oh, never mind, I see. You've endorsed the concept that it's a terrific
> idea to decide on a route before you know where you are going.
The original poster got some alternatives. It doesn't seem, to me, to
be a bad idea; nor, much different from how other languages work. I
know VB prefills the string "Command", Java has "String[] args" on its
"main" method - and, can't C/C++ see them in a similar way? We've even
had a contribution that PowerCOBOL has it as a property of POW-SELF.
> Good plan.
I guess I'm missing what's so bad about having an idea of where you want
to go. I could post and say "Hey, I want to drive to London." Now,
from here in Montgomery, that wouldn't be the best way to go - but,
someone could suggest driving to Atlanta, then catching a flight to
London. (That seems to be similar to the suggestion of writing a main
program to pass the subprogram input through its linkage section. The
main program wouldn't even have to be COBOL.)
Did this just hit on particular pet peeve of yours?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| docdwarf@panix.com 2005-09-06, 9:55 pm |
| In article <4f1b$431e3450$45491c57$26734@KNOLOGY.NET>,
LX-i <lxi0007@netscape.net> wrote:
>Michael Mattias wrote:
[snip]
>
>I guess I'm missing what's so bad about having an idea of where you want
>to go. I could post and say "Hey, I want to drive to London." Now,
>from here in Montgomery, that wouldn't be the best way to go - but,
>someone could suggest driving to Atlanta, then catching a flight to
>London.
The difficulty seems to be that the analogy you give of driving to London
is a... whatever they call it ('completely transportable'?) solution, one
that cannot be cut-n-pasted into any program in any place at any time.
(London, England? London, Ontario? London, KY? London, AL?)
DD
| |
|
| docdwarf@panix.com wrote:
> In article <4f1b$431e3450$45491c57$26734@KNOLOGY.NET>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
>
> [snip]
>
>
>
>
>
>
> The difficulty seems to be that the analogy you give of driving to London
> is a... whatever they call it ('completely transportable'?) solution, one
> that cannot be cut-n-pasted into any program in any place at any time.
>
> (London, England? London, Ontario? London, KY? London, AL?)
The first one. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| docdwarf@panix.com 2005-09-07, 7:55 am |
| In article <a1aad$431e4290$45491c57$3110@KNOLOGY.NET>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>The first one. :)
Even worse... by accident (and accident alone) the data not only presented
the desired alternative but presented it in the most efficient position...
this can lead to the Production Implementation crew signing off and when
the next batch comes in as:
(London, OH? London, AR? London, OR? London, CA?)
.... the program will blow up and Some Poor Newbie will get a 2:am call...
DD
| |
|
| <docdwarf@panix.com> wrote in message news:dfmb49$ia9$1@panix5.panix.com...
> In article <a1aad$431e4290$45491c57$3110@KNOLOGY.NET>,
> LX-i <lxi0007@netscape.net> wrote:
>
> Even worse... by accident (and accident alone) the data not only presented
> the desired alternative but presented it in the most efficient position...
> this can lead to the Production Implementation crew signing off and when
> the next batch comes in as:
>
> (London, OH? London, AR? London, OR? London, CA?)
>
> ... the program will blow up and Some Poor Newbie will get a 2:am call...
>
> DD
In this example, the poor newb will actually have travelled from Alabama to
Ohio...a fun trip I'm sure.
I discussed with a client this w the Theory of Coincidental
Programming....also known as "the fact that it works is happenstance"
JCE
| |
| Michael Mattias 2005-09-07, 6:55 pm |
| To steer this thread 'slightly' back toward its initial vector...
I guess I am just intolerant of the condition "without changing all the
programs."
For crying out loud, if you are changing operating systems as well as
compilers, what did you expect?
There is no magic wand.
There is no silver bullet.
There is no stake to drive thru the heart of the beast.
Ye shall reap as ye shall sow, so you may as well get off your dead butt and
start sowing.
Besides, if one spent just a little sowing time *wisely*, one could probably
come up with a COPYLIB or additonal module allowing the required change to
all the programs to consist of adding precisely one line of source code:
"COPY libname" or "CALL entryname USING ... RETURNING.."
MCM
| |
| Michael Wojcik 2005-09-07, 6:55 pm |
|
In article <7y4Te.238$jE2.165@newssvr19.news.prodigy.com>, "Michael Mattias" <michael.mattias@gte.net> writes:
>
> The implied syntax of any Windows EXE's entry point function is
> ENTRY WINMAIN
> USING BY VALUE hInstance
> BY VALUE hprevInstance << always zero on Win/32
> BY REFERENCE szCommandLine <<< pointer to null terminated
> string
> BY VALUE iCmdShow
This is simply not true. Windows programs that do not run under the
GUI subsystem - and there are a great many of them - do not have a
WINMAIN entry point at all. If I were porting batch-mode mainframe
programs to Windows, why would I have them run under the GUI
subsystem?
--
Michael Wojcik michael.wojcik@microfocus.com
If Mokona means for us to eat this, I, a gentle person, will become
 ! -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_
| |
| Michael Mattias 2005-09-07, 6:55 pm |
| "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dfmr250231n@news3.newsguy.com...
>
> In article <7y4Te.238$jE2.165@newssvr19.news.prodigy.com>, "Michael
Mattias" <michael.mattias@gte.net> writes:
Win/32[color=darkred]
terminated[color=darkred]
>
> This is simply not true. Windows programs that do not run under the
> GUI subsystem - and there are a great many of them - do not have a
> WINMAIN entry point at all. If I were porting batch-mode mainframe
> programs to Windows, why would I have them run under the GUI
> subsystem?
All Windows executable program file (both EXE and DLL) have an entry point,
period. The 'entry point function' address (well, actually the offset) is
stored in the PE header when the program file is created (compiled).
All Windows executable programs are passed these four parameters by the
loader. (Dynamic Link Libraries, while technically classified as executable
*files*, are never directly invoked by the loader; the entry point function
of a DLL uses different parameters).
It is possible that a specific individual compiler "helps" the programmer by
concealing the actual entry point and the parameters, but by golly at the
Windows level this is what happens.
MCM
| |
| William M. Klein 2005-09-07, 6:55 pm |
| Well ... Yes and No (from MY perspective),
One of the "selling points" (historically) for COBOL was (is) its portability.
Therefore, if one sticks to ONLY ANSI/ISO conforming syntax, then the source
code should be portable. (At least since the '74 Standard, there have been
requirements for "flagging" extension language). However, even with "portable
source code" the Standard doesn't require all "limits" (ellipsis in the
Standard) to be the same and some semantics are "implementor defined".
Make to the original request,
*IF* one is doing "IBM mainframe development" on a Workstation (PC, Unix, or
Linux), then I think it is important that the workstation environment support
*all* the "peculiarities" of the original environment (e.g. EBCDIC, JCL, PARMs,
file-status 9x, etc). Both Micro Focus and CA-Realia have (and continue) to
"target" this environment. To a lesser extent, Fujitsu also provides such an
environment. On the other hand, if one is PORTING an (IBM) mainframe
application to the workstation (for production use), then I think that part of
the "porting" process SHOULD be an evaluation of what is "new and different" in
the target platform. However, for cost-effectiveness, I understand the QUESTION
of "can I do this the SAME way on the workstation" and understand replies that
indicate that "NO, but there is a way to do an equivalent process).
P.S. It may or may not be worth adding here, that Fujitsu is RELATIVELY unusual
among COBOL products in that it DOES require one to identify "main" vs
"non-main" programs at compile-time. For an IBM mainframe application (with NO
Procedure Division USING statement) it is entirely possible to use the same
object code as a "main" program in some cases and a "sub-program" in other
cases. This restriction does not exist in Micro Focus or CA-Realia (and I don't
think in most Unix-supporting COBOLs). If one is a "paying customer" to
Fujitsu, one might want to raise this issue with them; it certain does turn out
to be "migration inhibitor" for some (not all) IBM mainframe COBOL customers.
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:PBBTe.1239$jE2.159@newssvr19.news.prodigy.com...
> To steer this thread 'slightly' back toward its initial vector...
>
> I guess I am just intolerant of the condition "without changing all the
> programs."
>
> For crying out loud, if you are changing operating systems as well as
> compilers, what did you expect?
>
> There is no magic wand.
>
> There is no silver bullet.
>
> There is no stake to drive thru the heart of the beast.
>
> Ye shall reap as ye shall sow, so you may as well get off your dead butt and
> start sowing.
>
> Besides, if one spent just a little sowing time *wisely*, one could probably
> come up with a COPYLIB or additonal module allowing the required change to
> all the programs to consist of adding precisely one line of source code:
> "COPY libname" or "CALL entryname USING ... RETURNING.."
>
> MCM
>
>
>
| |
| Michael Wojcik 2005-09-08, 6:55 pm |
|
In article <Q5DTe.468$Xq6.135@newssvr22.news.prodigy.net>, "Michael Mattias" <michael.mattias@gte.net> writes:
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dfmr250231n@news3.newsguy.com...
> Mattias" <michael.mattias@gte.net> writes:
> Win/32
> terminated
>
> All Windows executable program file (both EXE and DLL) have an entry point,
> period.
I never said they did not. I'm quite familiar with the PE format,
thanks. The entry point is a field in the Optional Header, which is
required for image files (which is the standard name for "EXE and DLL"
PE files).
There's nothing that demands that the entry point be named "WINMAIN".
In fact, for C programs built to run under the console subsystem
(that's a 3 in the Subsystem field of the Optional Header), it'll
be a function in the C startup; for Visual C 6, for example, that's
"_mainCRTStartup".
> The 'entry point function' address (well, actually the offset)
Actually the RVA, but why quibble?
> is
> stored in the PE header when the program file is created (compiled).
Linked. PE object files don't have an optional header, so the
compiler does not store an entry point in them. The linker creates
the optional header and sets the entry point field.
> All Windows executable programs are passed these four parameters by the
> loader.
Do you happen to have a reference to support this claim?
> It is possible that a specific individual compiler "helps" the programmer by
> concealing the actual entry point and the parameters,
I can't think of a modern implementation of a high-level language for
Windows that doesn't use a cover routine for the PE image entry point.
> but by golly at the Windows level this is what happens.
Perhaps; I haven't found anything in MSDN to confirm or deny that
those four parameters are passed to the entry point under all
subsystems. They're certainly not referenced by Microsoft's
mainCRTStartup, which is declared as taking no parameters at all.
At any rate, that looks to me like rather a weaker claim than what
you originally posted.
--
Michael Wojcik michael.wojcik@microfocus.com
"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_
|
|
|
|
|