Re: Is it possible to use the value of the PROGRAM ID within the source code?

From: Warren Simmons (wsimmons5_at_optonline.net)
Date: 06/20/04 

Date: Sun, 20 Jun 2004 03:47:51 GMT

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:
>
>
>>On Sat, 19 Jun 2004 08:59:40 GMT, robert.deletethis@wagner.net (Robert
>>Wagner) wrote:
>>
>>
>>>riplin@Azonic.co.nz (Richard) wrote:
>>>
>>>
>>>>"Chuck Stevens" <charles.stevens@unisys.com> wrote
>>>>
>>>>
>>>>>>If dataname is the same on the next CALL, as it is 99% of the time, the
>>>>>
>>>>> call
>>>>>
>>>>>>would be faster than the first.
>>>>>
>>>>>Where on earth did you get *that* statistic? The whole point of CALL
>>>>><dataname> is that the programmer *doesn't* know what the name of the
>
> called
>
>>>>>program is going to be until he gets to the CALL statement! If 99% of
>
> the
>
>>>>>time it's the same, why not use CALL <literal>? Or even CHANGE ATTRIBUTE
>>>>>TITLE OF <libraryname> TO <newlibname> CALL <newlibname>? Both are a
>
> whole
>
>>>>>lot faster than CALL <dataname>!
>>>>
>>>>I have several systems where the 'main' program is a simple loop which
>>>>is roughly:
>>>>
>>>> MOVE Logon-Program TO Program-Name
>>>> MOVE Menu-Program TO Next-Program
>>>> PERFORM
>>>> UNTIL Program-Name = "FINISH"
>>>>
>>>> CALL Program-Name
>>>> USING <interface block that includes Program-Name
>>>> and Next-Program>
>>>> ON EXCEPTION ...
>>>> END-CALL
>>>> CANCEL Program-Name
>>>> MOVE Next-Program TO Program-Name
>>>> MOVE Menu-Program TO Next-Program
>>>> END-PERFORM
>>>>
>>>>Any program can change Next-Program to allow the user or any program
>>>>to control where the system goes without having to return to the menu,
>>>>which is just the default action.
>>>>
>>>>The chances of the same program being CALLed twice in a row is very
>>>>small.
>>>
>>>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.
>>
>>The fact that you didn't just proves how restricted your moving around
>>has been.
>>
>>I'v seen this implementation in several customers this since the
>>1980's, andsome of the ones I saw were working since the 70's.
>>
>>some implemented this with a main program that reads a file to
>>determine the "transaction flow", others just have a list of possible
>>programs "hardcoded" within the main program (which in turn is called
>>by a menu option which is also based on a file)).
>>
>>All of them allowed for different flows depending on flags set by the
>>last program called, being this because the user hit a F-key or just
>>because he selected a field value that causes a program flow to branch
>>to a different place, or even because of the menu option selected
>>on the first place.
>>
>>The common factor with all those systems is that they had been well
>>designed on paper before starting coding the main interface programs.
>
>
> 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.
>

Relevant Pages

  • Re: APL2 and 64 bit o/s
    ... most of these are used with 32-bit operating ... On the compatibility question, our experience is that both Linux ... especially support for older hardware. ...
    (comp.lang.apl)
  • Re: APL2 and 64 bit o/s
    ... vast arrays of booleans - hundreds of times bigger than can be ... On the compatibility question, our experience is that both Linux ... operating systems) are very highly compatible with the 32-bit versions ... especially support for older hardware. ...
    (comp.lang.apl)
  • Re: Old burnt heatsink termal compound (white grease) removal
    ... the discussion of hardware issues relating to the Windows XP operating ...
    (microsoft.public.windowsxp.hardware)
  • Re: DLT-Laufwerk spult hin und her
    ... Das Tape laeuft also im Fast10 Transfermodus. ... Der ist nicht auf LVD ... Hardware angewiesen aber selbst auf SE Hardware recht unkritisch ... Rechner testen ob es am Tape oder am Hostadapter liegt. ...
    (de.comp.hardware.misc)
  • Re: Newbie cant use CD-ROM
    ... >successfully used this hardware with another operating ... It works when I boot up in Win95. ... >grafted into the file tree there. ...
    (linux.redhat.install)