Re: Question regarding Line Sequential files on MF Cobol running under HP-UX (by The Walrus I_Am_The_Walrus@invalid.email.com)

On 16 Feb 2008 03:05:31 GMT, The Walrus <I_Am_The_Walrus@xxxxxxxxxxxxxxxxx> wrote:

On Fri, 15 Feb 2008 20:45:06 -0600, Robert wrote:

Why can't Fred run the job directly? It sounds like your shop is under
'mainframe tyranny', where the scheduler runs on a mainframe, which
kicks off Unix jobs via Tuxedo or similar.

Close... before I arrived on the scene, the company I work for decided to
outsource their Y2K conversion so that they could take MF JCL and convert
it to "something" that would run on Unix but have the same functionality
of the MF stuff.

Realia, still sold by Computer Associates, offers 100% JCL compatibility off the shelf.

When I say "submit to the scheduller", I mean we run a
script that invokes the job manager which takes the "jcl" and runs it.
On our production box, it's Maestro that's responsible for this as no
jobs are run "by hand". Funny thing is, that if I write a ksh script and
have it run the Cobol, it works no matter where I run it from..so that's
why I'm worried.. converting to ksh isn't an option, although I've been
through an exercise that has proven that we could run everything using
ksh.

We have the same situation -- a mainframe scheduler running Unix jobs through Maestro. We
have one job that runs fine on three out of four production machines, and every test
machine. It crashes with a memory protection error (114) on one production machine. I
determined it's crashing inside SyncSort, which is called by a Cobol SORT verb. The
program runs fine when launched from a ksh script or menu program NOT started by Maestro.

It seems like a simple problem, there must be something different in the environment set
up by Maestro. I said stick an 'env' in the Maestro script so I can figure out what the
difference is. That's too easy, they'd rather play Finger Pointing. They don't want to
know WHAT the problem is, they want to know WHO is at fault.

Six months later, it still isn't fixed. Each time they run it directly on Unix, they have
to get special permission from some big shot.

What's even funnier is we're the company that created Unix. Why are we scheduling jobs
through a mainframe?

A programmer writes a piece of JCL and calls it FILE.CS (don't ask what
the CS stands for). He/She submits that to the job manager using
either sub (a script) or via sudo -u .... sub ....
sub takes the .CS and sends it to the scheduller called cjm which runs
the JCL as if it was running on the mainframe, down to the ability to
have generation data groups.

We don't go through the mainframe scheduler in development and test, only in prod.

What does that mean? This isn't black magic. If the file is readable,
the first record will appear in the record area.

And it does, but the program in question is expecting to see 'HDR ' in
bytes 9-12. The first 8 bytes of the line are binary 0's or something
like that.

Problem solved! By default, nulls are removed from line sequential files, causing the rest
of the record to be shifted left. You can turn that off by entering
INSERTNULL=OFF in the file handler configuration file.

Environment variable $EXTFH points to the configuration file. If $EXTFH is not set, the
default location is $COBDIR/etc/extfh.cfg

Check that file on your production machine. I'm sure you'll find the INSERTNULL option.
If you don't have write permission on the non-working machines, copy it to your home and
set EXTFH=~/extfh.cfg

Whip them programmers into shape. Bye.

I used to be one... this program, the one I am trying to figure out is
one of the worst coded Cobol programs I've ever seen. I've always been
told that when ever you open a file, or read a record, or even close the
file, you should check the File Status. But this program isn't even
specifying that there is a File Status... but that's just my opinion.

You ERRONEOUSLY think that the absence of File Status means errors will go undetected and
unhandled. In fact, if an error occurs and there IS NO File Status, the Micro Focus file
system aborts the job with an appropriate message such as "Open error on file xxxxxxx".

If that's all the program is going to do, which is usually the case, it's easier to let
Micro Focus do it for you.
.

Relevant Pages

  • Re: Question regarding Line Sequential files on MF Cobol running under HP-UX (by The Walrus I_Am
    ... 'mainframe tyranny', where the scheduler runs on a mainframe, which ... kicks off Unix jobs via Tuxedo or similar. ... Many Big Unix shops use BMC's Control-M, a job scheduler that runs on both z/OS and Unix. ...
    (comp.lang.cobol)
  • Re: Can an employer force you to stay?
    ... So nothing recent in a formal manner, but I have done a lot of IT at uni, including training staff and students, writing web pages for the department on UNIX matters etc. ... Particularly this prospective post requires skills in Solaris, HP-UX, and network storage skills. ... Lots of junior IT jobs seem to want Windows, first line support, chaning passwords for every idiot who forgets them, filling the printers up with paper etc. ...
    (uk.legal)
  • Re: Task Scheduler stopped running and Im unable to restart
    ... restart the Task Scheduler. ... one of the files that one of the jobs was logging to had become corrupted ... You also could try System Restore if you have a ... I've down everything that I can think of to restart it. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Controlling the execution sequence of dependant jobs in JES2
    ... similar situation where we had one jcl deck that contained hundreds of jcls ... within the one deck. ... got around this by simply setting the priority of all input jobs to be the same ... I'm close to suggesting a RYO scheduler. ...
    (bit.listserv.ibm-main)
  • Re: unix "batch processing"
    ... In article, bill@xxxxxxxxxxx (Bill Gunshannon) writes: ... VMS can't do (at least not without elevated priviledges on the ... Perhaps the UNIX facility you refer to exists in Linux? ... I guess I would need to know what you think of as "batch jobs". ...
    (comp.os.vms)