Home > Archive > Cobol > June 2004 > Re: Is it possible to use the value of the PROGRAM ID within the
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 |
Re: Is it possible to use the value of the PROGRAM ID within the
|
|
| Donald Tees 2004-06-10, 8:55 am |
| Stephen Gennard wrote:
> You could use x/open syntax...
>
> 01 ws-stuff pic x(80).
>
> display 0 upon argument-number
> accept ws-stuff from argument-value
> display "Main exe is : " ws-stuff
>
> It works with both "cobrun xx" and your program built as an exe....
>
> --
Normally, only one program of a run unit can be the EXE. You prbably
*KNOW* what is running at that point. It is after control transfers to
another program that you need the information.
Donald
| |
|
| JerryMouse wrote:
>
> In olden days, programmers used to mark the start of Working-Storage with:
>
> 01 FILLER PIC X(24) VALUE 'START OF WORKING-STORAGE.
Wow! In olden days, you used to be able to omit the closing quote? ;)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| JerryMouse wrote:
> LX-i wrote:
>
>
>
> No, there's a continuation line. Remember those?
Heh - remember? I've used 'em - used one last w . :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Clark F. Morris, Jr. 2004-06-14, 3:55 am |
| The problem with using PROGRAM-ID is that it has no necessary
operational significance in many environments. On the IBM OS360 and
successor operating systems (z/OS being the latest incarnation), a
program could have a source member name of X123 and be compiled and
linked to give an executable name of X123 while the PROGRAM-ID value is
Z456. While this is bad policy, the operating system will happily
execute X123 or accept dynamic CALLs of X123, executing them correctly
and won't recognize Z456.
| |
| Donald Tees 2004-06-19, 3:55 pm |
| docdwarf@panix.com wrote:
> In article <40d3f520.233277868@news.optonline.net>,
> Robert Wagner <robert.deletethis@wagner.net> wrote:
>
>
>
> [snip]
>
>
>
>
> Mr Wagner, you have presented code here about which many others have made
> the same claim... and you've called them 'resistant to progress' or the
> like.
>
>
>
>
> Oh, I *cannot resist... this seems like rigid, hierarchical thinking, Mr
> Wagner, how very archaic of you! Remeber the IBM mainframe ISPF
> 'revolution' of the 1970s? Not only was there a menu-driven Integrated
> environment... but at any point one could use the command-line to jump to
> any other place in the Facility.
>
> Come to The Future, Mr Wagner... it started about three decades ago!
>
> DD
>
A collection of such command lines, tied as an object to a buttons on a
screen, seems like such a neat liitle oop object. Compiled with the
actual code given above, also implimented as an oop object, you have a
ten minute single stepping debug tool.
'Course using objects is just *so* inefficient.
Donald
| |
| Warren Simmons 2004-06-19, 3:55 pm |
| Regarding the Never Before Seen Program mentioned below, and based upon
the logic depicted, that logic is very much like the old Univac I Run to
Run Locater (our only operating system), and placed between each load
mod on an application library TAPE.
Our manual controls had to make sure the right library tape had to be
mounted upon the correct drive before an application began. Simple.
Worked well. Not very good when you are using fancy hardware like you
are dealing with today.
Warren Simmons
Robert Wagner wrote:
> riplin@Azonic.co.nz (Richard) wrote:
>
>
>
>
> I've never written nor seen a program like that.
>
> Letting subordinate programs control who gets control next seems like bad
> structure. The menu program should make that decision.
| |
| Warren Simmons 2004-06-20, 3:55 am |
| Regarding Structured Programming.....
At one time, our Data Center was managed by a programmer who mostly
was interested in getting the computer used for scientific work during
his lunch hour to work on his stock portfolio.
My view of his attitude was that we all know how to program, you staff
managers take care of things. I'll watch.
Then, a new guy came in. His background was managing a card shop at a
large plant. He reminded me of a first Sargent. Everything has to be
lined up by size, nothing left on a desk overnight, etc. However, he
was used to listening to his equipment salespeople, and when they and
people in the staff began to suggest a training program, he bought the
idea, and did a better than average job seeing that the training paid off.
After all, everything we did as a service to the company was funded
by cost savings. I was in no position to judge the outcome, but having
a part in some of the training programs, I found that it was well
received, and that in my opinion, there was no way, did the training
cost us money.
Yet, when it came down to some of the training programs, the bosses
exercised "discretion' and only supported part of the over all
objective. As an example, the trend became to use Structured
Programming,but some of the elements were overlooked for cost savings!
Such as wly review by team members. In the long run, something else
may have replaced it, but the attitude became supportive of staying
aware of the progress of tools, and the rapid adoption of them.
It was like a breath of fresh air. Something I could use a little of
right now. New Jersey vs Arizona. Guess which one I favor.
Warren Simmons
docdwarf@panix.com wrote:
> In article <joe_zitzelberger-B0D300.10185919062004@corp.supernews.com>,
> Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:
>
>
>
> [snip]
>
>
>
>
> Quite simply, things might not be as they are described as 'quite simply'.
> I was taught, e'er-so-long ago, that 'modified Yourdon structuring' was
> defined as allowing for a GO TO which directed execution to the top of the
> paragraph which contained the statement, to the -EXIT paragraph THRU which
> the containing paragraph was PERFORMed or to the -ABEND routine of the
> program... those three and no more.
>
> If these teaching were correct then a method of structuring is defined as
> allowing for a GO TO and therefore, quite simply, it does *not* make a
> program unstructured.
>
> DD
>
| |
| Warren Simmons 2004-06-20, 3:55 am |
| This is redundant so skip it if you have had enough.
Fancy operating systems and the hardware that needed them did not exist
in my knowledge in 1960. Since that's a large claim, I would not dispute
any other input that says there was.
Now, getting down to the use of Program name in a program.
There is an out of sync condition in these kinds of discussions because
of the lack of historical identification. And, a look at the whole
problem of managing a system running a variety of applications with
tape jockeys, and computer operators who did not necessarily know
programming.
In the simplest case I know of, the run to run locater system, there
were many other external manual steps that went with the program.
Tape library identification with it's back up needs, scheduled
application run times for processing to meet other requirements.
(Example: Every night, a station wagon left our office and drove
half way to Chicago. At about the same time, another driver left
Chicago going to Pgh with mail for the home office. Logistics
Logistics.
Each application had label requirements also adjusted to the
application schedules.
In the event of hardware failure, a company plane might take
all the tapes for required processing to the backup site along
with the people who ran the system and the programmers who had
to be there at times.
It was even necessary to have the paper in the console typewriter
imprinted with serial numbers on each blank page to avoid
operator cover up.
That is all very old history. MOre and more the lease lines
took care of things, and other methods of input and storage
occurred. Programs began to tell the tape jockeys what tapes
to get by serial number. Daily backup tapes were sent to
an archive under ground.
But as the hardware, software, and knowhow improved, so did
the methods. Picking on how the program gets from one step
to another is a very obtuse subject I'd call outside the
realm of the C.L.C. If a user wants to do something outside
the area of standard support, that user has very few choices.
Go with the already supported methods, or go buy or program
their own methods. There are way to many variables to pursue
this subject without setting the stage, and having an assignment.
Even the records of what, when, how, and where is soiled by
the imprecise bantering.
However, if you guys continue to talk about it, I'll be
reading it for awhile longer.
Warren Simmons
Robert Wagner wrote:
> Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:
>
>
>
> called
>
>
> the
>
>
> whole
>
>
>
> I have no objection to that. I object to a subordinate program returning the
> NAME of the next program, and main calling it blindly. Every program would have
> to know the name of every other program, which means adding or deleting a
> program would require changes to all.
>
> That's with traditional programming and hardcoded names. I wouldn't object if
> names were stored in externally defined widgets, or even in a file.
>
|
|
|
|
|