The only "plus" that I know of in starting a programmer's jobs with their
TSO id is the fact that the SDSF "H" display defaults to only displaying
jobs with those types of names. This avoids the need for a PREFIX command
or a FILTER. Now, since I don't do this job name stuff, I must remember to
first do a FILTER command in the SDSF H screen to filter on OWNER EQ myid,
then I must remember to issue the "H *" command instead of a simple H
command. Long ago I implemented the IKJEFF53 exit which disabled the "id
plus one character" check in some TSO commands.

For job sequencing, I do the method where the last step of a given job
submits the next job in sequence. In the past, the "plus" of submitting all
the jobs in the right sequence with the same name was when the input queues
were long. All of the jobs would get to the top of the queue and then each
would usually start immediately after the previous one finished. Otherwise,
each job has to run, submit, wait for turn in queue, and repeat. I remember
one programmer who would submit a lot of compile jobs in the morning, on
hold. He knew which programs he was going to work on. The jobs would
migrate to the top of the queue and then hold there. We the programmer was
ready, he just released the job and it was usually next in line. He could
swamp the system in the afternoons. The other programmers despised this. He
considered it to be clever and efficient.

On Fri, May 3, 2013 at 12:34 PM, Frank Swarbrick
<[email protected]>wrote:

> If their way was better (and I've found some MVS processes to be better;
> I'm no "VSE lover") I would look in to changing it.  Just because something
> "has always been done this way" doesn't mean it's better and should not be
> changed.  In all of this discussion of MVS job names I have yet to hear a
> good justification for:
> - MVS jobs of the same name not running at the same time
> - MVS jobs starting with the users initials
>
> What I have heard is there are many better ways to accomplish:
> - job sequencing
> - job user identification
>
>
> Just my opinion.
>
> Frank
>
>
>
>
> >________________________________
> > From: Ted MacNEIL <[email protected]>
> >To: [email protected]
> >Sent: Thursday, May 2, 2013 10:01 PM
> >Subject: Re: Duplicate job names (Was: Check whether job still running)
> >
> >
> >Sorry.
> >No insult intended.
> >But, you've been z/OS for what 3 years?
> >How would you feel if a bunch of MVS'rs came and b*tched about 40+ years
> of VSE practices that I'm sure are just as ingrained?
> >
> >How can you know where I'm at if you ain't where I've been?
> >Understand where I'm coming from?
> >-
> >Ted MacNEIL
> >[email protected]
> >Twitter: @TedMacNEIL
> >
> >-----Original Message-----
> >From:         Frank Swarbrick <[email protected]>
> >Sender:       IBM Mainframe Discussion List <[email protected]>
> >Date:         Thu, 2 May 2013 15:45:15
> >To: <[email protected]>
> >Reply-To:     IBM Mainframe Discussion List <[email protected]>
> >Subject: Re: Duplicate job names (Was: Check whether job still running)
> >
> >They've been brainwashed.
> >
> >
> >
> >
> >>________________________________
> >> From: John Gilmore <[email protected]>
> >>To: [email protected]
> >>Sent: Thursday, May 2, 2013 3:22 PM
> >>Subject: Re: Duplicate job names (Was: Check whether job still running)
> >>
> >>
> >>Some shops have even institutionalized practices that produce
> >>duplicate jobname values.
> >>
> >>I know of one that long required development programmers who used the
> >>submit command to use their TSOIDs as the name of every job they
> >>submitted.  I suggested that it would be helpful to these programmers
> >>if they could suffix a single character to that jobname to help them
> >>to distinguish such jobs from each other; and they were then
> >>grudgingly permitted to do so; not all of them, however, make use of
> >>this freedom.
> >>
> >>John Gilmore, Ashland, MA 01721 - USA
> >>
> >>----------------------------------------------------------------------
> >>For IBM-MAIN subscribe / signoff / archive access instructions,
> >>send email to [email protected] with the message: INFO IBM-MAIN
> >>
> >>
> >>
> >
> >----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to [email protected] with the message: INFO IBM-MAIN
> >
> >----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to [email protected] with the message: INFO IBM-MAIN
> >
> >
> >
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to