Re: COBOL's Influence on C

On Nov 18, 3:25 pm, Robert <n...@xxxxxx> wrote:
On Sat, 17 Nov 2007 13:06:05 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:

No. Wrong. You only established that they don't understand why it is a
problem because it _isn't_ a problem to them.

They must not work in large shops that run 100,000 jobs per month. I thought mainframers
did.

They are a mainframe shop, therefore they have problem X. Yeah that
makes sense, NOT. Perhaps it isn't a problem because they manage
their site in a way that avoids it.


You did _not_ 'establish' that they 'don't understand how Cobol causes
it', which is just more of your self-promoting puffery, it just is not
a problem.

Best I can tell, z/OS has no tool like ldd to check whether called programs exist. I think
the reason is because they run so much Cobol, which cannot be checked.

If it was actually a problem then tools would have been developed
which eliminated the problem. The absence of a tool indicates the
absence of a problem. ldd is a useful tool on Unix because it is a C
environment that relies on having scads of libraries that must be
checked when a new program is installed.

If they ran mostly
C and a little Cobol, like Unix, they'd have such a tool. Then they'd understand that
Cobol causes a problem.

If Cobol was the same problem as C they would have such a tool.
Instead of trying to tell that they have a non-existent problem why
don't you _ask_ if they do.

Or are you astounded by the idea that the rest of the world is not
just a reflection of what you see around you ?

What is making the programs 'disappear' from the machine such that
suddenly it cannot be found ? If a program was there last week when
the batch ran why is it not there now ?

A bad library path is one common reason, as I said earlier.

What causes the 'library path' to change ?

Typical Unix applications run an 'environment script' that's 'sourced in' (included) from
a remote location controlled by systems guys, not applications guys. The library path is
set in that script. It's not set once for the whole installation, it's set for each
application system. For example, payroll might be different from general ledger.

Deployment to production is controlled by a third group: change management (where I often
work). Problems occur because of miscommunication between systems guys, who change the
environment script, and change management guys, who deploy executables.

Then fix the real problem rather than ranting about how it is everyone
else's fault.

How would showing that the
called program is in its proper place by a verification routine solve
bad programmers writing bad library paths.

Applications programmers don't write library paths; systems programmers write library
paths. The exception is development environments, aka sandboxes, where applications
programmers can do anything they want. When (not if) they find a path is screwed up, they
fix it. But they often don't communicate the fix to systems programers. Similarly, when
they find a third party library is missing, they remedy the problem in their sandbox, but
don't communicate that to change (deployment) managers.

Then fix the problem instead of ranting on about how it is the fault
of Cobol, or language designers.

If a job has a bad library path and a verification is done after the
path is set then the job will fail. How is this different than the
program starting and failing immediately because it can't find its
called program, or dll ?

The difference is hours of time to fix the problem before the program runs for real.

You haven't shown that it will 'fix the problem' because your routine
does not try the execute the called routine, just because it is there
does not prove it will run. It also doesn't prove that the library
path tested is the one in the production run.

ALso, the failing program might be deep into a jobstream that runs for hours. Depending on
restart procedures, recovery might have to rerun many other programs.

<shrung> that is what system testing is for. Do a system test on the
production machine, or at least do a diff between the development and
production systems.

Another is the installation of new third party software. A typical call hierarchy is not
as simple as MAIN calling A, B and C, it is usually MAIN calling A, which calls B from a
third party, which calls C from another third party. Now B is replaced. The new B requires
a new C. On the development machine, C _is_ replaced (by a developer, after a test
aborts). Due to missed communication, C is not replaced on the production machine.

That is simple to detect by do a diff on the structure listing.

What's a structure listing, and how do I get one?

ls -alR base directory >listing

I would also suggest that the program date/time be compared because
even if the program _is_ there it may have been updated in system test
and not in production. This applies regardless of language or how the
calls are made and is a fairly basic check when moving to
production.

Timestamps are an obsolete idea we stopped using in the '90s. We now use version numbers,
which tie directly into the version control (change management) system. You DO use
version control, like CVS or SVN, don't you?

Then extract the version number in all the files of the system on both
systems and run a diff on these.

If a file is missing or has the wrong version then diff will tell you.

Unix lets you put the version number into the ELF header. That's how you check the version
deployed. That's also how you check the version of third party software, and other third
party software called by it.

Is the above something you were responsible for and and now try to
blame others ?

Ad hominem ignored, as usual.

You have a strange idea of what an 'ad hominem' is and use this as a
deflection.

It was a question. If you are sensitive about this then perhaps I was
on target. Maybe you stuffed something up and are trying to blame
Cobol, or Call dataname, or ...

.

Relevant Pages

  • Saturn Commercial with "Pixie and Dixie" music (Hanna barbera)
    ... Production Media Music', aka "Ole George/OGM Media Music", which soon ... Hanna Barbera's blue pooch had that tune used when Huckleberry "injures ... It's one of many cues commonly used at the time on many shows and even ... libraries comepted for the makret Cpaitol,a s a now major labnel, ...
    (rec.autos.makers.saturn)
  • Re: z/OS PTFs
    ... Meganen Naidoo - BCX - RO JHB wrote: ... We are currently running z/OS 1.7 service level 0705 on 11 production ... Lpars for different clients - not in a sysplex. ... use the 'fix on fail' approach if we require a fix. ...
    (bit.listserv.ibm-main)
  • Re: Vista
    ... It's sort of like going back and modifying the "2am fix" to standardize it with the rest of the code. ... Especially dealing with the DRM fixes, it could be that someone left an inefficient tight loop in one of the libraries. ... A man who believes in a God he doesn't see, ...
    (comp.lang.cobol)
  • Re: Tale of debugging and programming logic in c#/sql
    ... > and I pushed it to production. ... I was anxious to find a fix, ... The login page does ... > user authenticates or creates a new login name -- it is based on an ID ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: PDS to SEQ and back to PDS
    ... then try to get the same error so they can make sure their fix ... I had to globally change a JCL library to get production out. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)