Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)

[David Cole]

As noted in my prior post, I think it is a shame that the IBM-JES2
folks make it so difficult to serialize a thread of jobs. It seems to
me that this is such an obvious thing to want to do, but when JES2 is
started with CNVTNUM=>2 (and there are strong reasons for must shops
to want to do this), such serialization becomes problematic.

The thing is, a JES2 supported solution, it seems to me, would be
both ideal and easy to implement. Here's my idea:

(1) support a //card option or a /*card option by which a user could
provide an arbitrary serialization name. Example: /*JOBPARM
THREADNAME=xyz. Use this name on each job in the thread.

(2) Run the threaded jobs into a reader in the same order that you
want the jobs to run. (Allow subsequent SUBMITs to add to a thread,
if desired.)

(3) The first converter to pick up one of the threaded jobs will
always pick up the first one.

(4) When that converter sees the thread name, it takes ownership of
that thread such that all other converters will refuse to process
jobs having that same name.

Then, of course, the jobs would be queued for execution in the same
order by which they were read, and if only one initiator ware
assigned the thread's execution class, then they would, in fact,
execute in that same order.

There are, of course, several ancillary details:
* Thread names will have to have some reasonable expiration interval.
* $D/$T command will need to allow operators to display and
manipulate threads to allow them to display and fix problems.
* Some mechanism (ownerid perhaps?) need to be created to prevent
unrelated threads having the same name from colliding.
It's been several decades since I used to be a JES2 programmer, but
from what I remember, it doesn't seem to me that this should be too
hard. I'd guess that implementing such a scheme would take maybe only
a week or few of my time.

Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Staller, Allan]

WLM managed Init's?
IIRC, Jobs are placed in queue in FIFO order within Service Class.

<snip>
The thing is, a JES2 supported solution, it seems to me, would be
both ideal and easy to implement. Here's my idea:

(1) support a //card option or a /*card option by which a user could
provide an arbitrary serialization name. Example: /*JOBPARM
THREADNAME=xyz. Use this name on each job in the thread.

(2) Run the threaded jobs into a reader in the same order that you
want the jobs to run. (Allow subsequent SUBMITs to add to a thread,
if desired.)

(3) The first converter to pick up one of the threaded jobs will
always pick up the first one.

(4) When that converter sees the thread name, it takes ownership of
that thread such that all other converters will refuse to process
jobs having that same name.

Then, of course, the jobs would be queued for execution in the same
order by which they were read, and if only one initiator ware
assigned the thread's execution class, then they would, in fact,
execute in that same order
</snip>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

At 5/23/2008 02:23 PM, Staller, Allan wrote:
>WLM managed Init's?
>IIRC, Jobs are placed in queue in FIFO order within Service Class.

The trouble is, your "FIFO order" is the order in which the
collective converters finish processing their jobs and place them
onto the execution queues. Because multiple converters process in
parallel, and different jobs take different lengths of time to
convert, the order in which jobs complete conversion can be different
from the order in which jobs start conversion.



Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Knutson, Sam]

Hi Dave,

What you describe is pretty much what the Mellon Mods for JES2 provided.
I would like to see equivalent function added to base JES2 by IBM.
Thruput Manager provides this function too. Here is user doc for the Mellon Mods syntax for comparison.

Thanks, Sam


Users Guide - How to use the features of these Mods

- Control Statements

You take advantage of the Mellon Shared Spool mods via JECL
statements. There are currently five supported statements, they are:

"/*CNTL XEQ resource, { EXC | SHR }"

"/*ROUTE XEQ secheduling environment name | HERE "

"/*WITH jobname"

"/*AFTER jobname"

"/*BEFORE jobname"

The /*CNTL XEQ statement is used to add an additional job selection
criterion based on other executing jobs current use of the same resource
name. The "/*CNTL XEQ" must be placed in columns 1 through 10. The
resource name is arbitrary, and is made of up to eight (8) characters
with no embedded blanks. The resource name follows the literal "/*CNTL"
and must be preceded by at least one, but not more than 30 blank spaces.
If the shared (SHR) or exclusive (EXC) keywords are used, they must
immediately follow the resource name and be preceded by a comma. If
neither the SHR nor EXC keyword is specified SHR is assumed.

You may specify up to eight /*CNTL statements; additional statements are
disregarded.

Examples:

Assume jobnames ABC, and CDE are currently in execution with the
following /*CNTL XEQ statements -

//ABC JOB (other stuff)
/*CNTL XEQ MYNAME,SHR

//CDE JOB (other stuff)
/*CNTL XEQ MYNAME,SHR

Then if job EFG is submitted with the following, /*CNTL statement -

//EFG JOB (other stuff)
/*CNTL XEQ MYNAME,EXC

The job will not be selected for execution as long as either job ABC or
CDE continues to run.

Next if job XYZ is submitted with the following, /*CNTL statement -

//XYZ JOB (acctng info)
/*CNTL XEQ MYNAME Ú SHR is the default

It would be immediately available for execution.

When no jobs remain in execution with a /*CNTL XEQ MYNAME job EFG with
the EXC requirement would be available for job selection. Assume it has
now been selected, and a new job enters the system with the following
/*CNTL statement -

//WXY JOB (acctng info)
/*CNTL XEQ MYNAME

Job WXY will not be available for job execution until job XYZ that
holds the resource name exclusively ends. If other jobs are submitted
with resource names other than MYNAME, they will be treated separately
and only other jobs with /*CNTL statements that reference the same
resource name will affect their availability for job selection.

The /*CNTL statement only provides additional job selection criterion,
and does not replace other JES2 requirements for job selection such as
available initiators, appropriate job class and so on. The resource
name is arbitrary, you make it up, there is no need for anyone to add
the name to WLM, or any other table before it is used.


The /*ROUTE XEQ is a standard JES2 statement used to route your job to a
specific execution node. We have usurped the use of the statement, and
when we read an XEQ statement, we test to see if the name following the
XEQ literal is a valid WLM scheduling environment name. If the name is
a valid scheduling environment name, and if no schenv value is present
on the JOB card, we use the XEQ name in the same way the job statement
parameter SCHENV is used, otherwise we let JES2 handle it normally.

The literal "/*ROUTE" must begin in column 1. The literal "XEQ" must
follow "/*ROUTE", and may be separated by one to twenty blank spaces.
The resource name, if not a valid JES2 node name, must follow the "XEQ
literal by between 1 and 35 blank spaces. The resource name can be
between 1 and 16 characters long, if the name is longer than 16
characters, only the first 16 are used.

There is one specific exception to all of the above, if the literal
following XEQ is HERE, then the jobs system affinity is set to the
system where you submitted the job, quite a handy feature itself.

You may specify more than one /*ROUTE statement; but only the last will
be used.

Examples:

//ABC JOB (job acctng),SCHENV=BEFOREALL
/*ROUTE XEQ AFTERALL <== ignored because a valid schenv is specified

//ABC JOB (job acctng),SCHENV=BEFOREALL
/*ROUTE XEQ N6 <== a valid JES2 routing node, both jes2 routing and
//* schenv are valid for this job.

//ABC JOB (jobacctng)
/*ROUTE XEQ BEFOREALL <== BEFOREALL is setup the same as SCHENV above

//TUV JOB (jobacctng)
/*ROUTE XEQ HERE <== the jobs will only execute where submitted.

The /*WITH statement specifies that the job is only available for
selection while the jobname named on the /*WITH statement is in
execution. The condition is satisfied even if the jobname that must be
executing is executing on a different system within the same MAS
environment. If more than one /*WITH statement is read; only the last
one is kept.

Example:

//FGH JOB (acctng info)
/*WITH JKL

This job will only be selected for execution if jobname JKL is
executing at the time of job selection.


The /*AFTER jobname statement specifies that the job is only available
for selection after the jobname in the /*AFTER statement has finished.
Because we really do not track all completed jobs, from - from when -
the beginning of the day, the week, the last ipl, the last cold start,
or maybe for all time, it is more correct to say that if the jobname
specified on a /*AFTER statement is in execution at the time our job
would otherwise have been selected for execution, then our job will wait
until the jobname referenced in the /*AFTER statement has ended.
"AFTER" may have been more appropriately names "NOT WHILE", but since I
was not around when the original keywords were developed, please do not
blame me. Again, the jobname on the /*AFTER need not be executing on
the system that our job is potentially selected for execution on, it
could be on any system within the MAS complex.

If more than one /*AFTER card is read; only the last one is kept.

Example:

//ABC JOB (acctng info)
/*AFTER XYZ

Job ABC will not be available for execution while job XYZ is in
execution anywhere within the MAS complex.


The /*BEFORE jobname statement causes the jobname specified in the
statement to not be selected for execution until after this job has
completed. Specifically if jobname ABC has a /*BEFORE XYZ statement,
then if jobname XYZ is potentially selected for execution by JES2, the
Mellon Mods will examine all jobs on the input queue and when jobname
ABC is found to have a /*BEFORE for job XYZ, job XYZ will be rejected as
a potential candidate for job execution.

If more than one /*BEFORE statement is read; only the last one is kept.

Example:

//ABC JOB (acctng info)
/*BEFORE XYZ

This before statement will cause JES2 to reject job XYZ as a potential
candidate for job execution until after job ABC has completed execution.
If job XYZ was already executing at the time job ABC is submitted, the
/*BEFORE statement will not affect anything, unless there is another job
XYZ waiting to execute. Also please note, it is possible to form a
lockout condition where JOBA has a /*BEFORE JOBB, and JOBB has a
/*BEFORE JOBA statement. There is no checking done for this type of
deadly embrace.

A few final notes concerning the relationship between /*BEFORE, and
/*AFTER. Many people try to use these statements, and stack two or more
jobs in the same PDS member and submit them all at the same time with
one SUBMIT command. This usually works as expected, but sometimes JES2
will NOT PROCESS the jobs in the order they appear in the submitted
member. This can result in a job with a /*AFTER statement for a prior
job you think JES2 has already seen and processed because of the
sequence in the submitted member, being processed and initiated before
JES2 ever finishes reading the job that is the object of the /*AFTER
statement. This problem can be avoided by making sure that jobs with
/*BEFORE and /*AFTER requirements are submitted separately from each
other and in an appropriate sequence.

In relationship to any of the statements above, when routing a job to
another node, the additional selection criterion defined by the Mellon
Mods statements, will follow the job to the new node, where it will
likely no longer be appropriate. Of course if the Mellon Mods are not
installed at the receiving node, the additional job selection
requirements are not honored.

The JES2 $DJ command output has been extended to include information
about /*CNTL, up to eight names qualified with an "E" for exclusive, or
an "S" for shared, one /*WITH jobname, one /*BEFORE and one /*AFTER
jobname. Examples of the extended displays are given below, please note
that the information is included in either the standard or long versions
of the command.

Altered Display Commands -

-$DJ(25926)
$HASP890 JOB(T0SM0TTY)
$HASP890 JOB(T0SM0TTY) STATUS=(AWAITING EXECUTION),CLASS=X,
$HASP890 PRIORITY=6,SYSAFF=(ANY),HOLD=(JOB),
$HASP890 AFTER=T0SM0AF,BEFORE=T0SM0BF,WITH=T0SM0WTH,
$HASP890 CNTL=(HOWDY-E,HOWDO-S,WILDO-S,HELLO-S)


-$DJ(25926),LONG
$HASP890 JOB(T0SM0TTY)
$HASP890 JOB(T0SM0TTY) STATUS=(AWAITING EXECUTION),CLASS=X,
$HASP890 PRIORITY=6,SYSAFF=(ANY),HOLD=(JOB),
$HASP890 CMDAUTH=(LOCAL),OFFS=(),SECLABEL=,
$HASP890 USERID=T0SM0,SPOOL=(VOLUMES=(JES2T1),TGS=1,
$HASP890 PERCENT=0.0009),ARM_ELEMENT=NO,CARDS=18,
$HASP890 REBUILD=NO,SRVCLASS=BATTSTMD,SCHENV=TEST,
$HASP890 SCHENV_AFF=(),CC=(),AFTER=T0SM0AF,
$HASP890 BEFORE=T0SM0BF,WITH=T0SM0WTH,
$HASP890 CNTL=(HOWDY-E,HOWDO-S,WILDO-S,HELLO-S)


In addition informational messages, $HASP493 and $HASP494 are written to
the log as jobs with /*CNTL, /*WITH, /*BEFORE, or /*AFTER are read.
Examples of the messages follow.

These messages were issued for jobname T0SM0TTY

$HASP944 T0SM0TTY * -- WITH JOBNAME = T0SM0WTH --
$HASP944 T0SM0TTY * -- AFTER JOBNAME = T0SM0AF --
$HASP944 T0SM0TTY * -- BEFORE JOBNAME = T0SM0BF --
$HASP943 T0SM0TTY * -- CONTROL INFO = HOWDY,EXC --
$HASP943 T0SM0TTY * -- CONTROL INFO = HOWDO,SHR --
$HASP943 T0SM0TTY * -- CONTROL INFO = WILDO,SHR --
$HASP943 T0SM0TTY * -- CONTROL INFO = HELLO,SHR --


- end of text -
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

Hi Sam,

You had me until I read this:

>A few final notes concerning the relationship
>between /*BEFORE, and /*AFTER. Many people try
>to use these statements, and stack two or more
>jobs in the same PDS member and submit them all
>at the same time with one SUBMIT command. This
>usually works as expected, but sometimes JES2
>will NOT PROCESS the jobs in the order they
>appear in the submitted member. This can result
>in a job with a /*AFTER statement for a prior
>job you think JES2 has already seen and
>processed because of the sequence in the
>submitted member, being processed and initiated
>before JES2 ever finishes reading the job that
>is the object of the /*AFTER statement. This
>problem can be avoided by making sure that jobs
>with /*BEFORE and /*AFTER requirements are
>submitted separately from each other and in an appropriate sequence.

The disordering of the jobs that you refer to is
exactly the problem that my suggestion (THREADNAME=name) attempts to fix.




Thanks, though, for the memory lane stroll. I had
forgotten about /*BEFORE and friends, but your
post reminded me that I had first seen them when
I was working at a DC shop in the early '80s.

Dave






At 5/23/2008 02:35 PM, Knutson, Sam wrote:
>Hi Dave,
>
>What you describe is pretty much what the Mellon Mods for JES2 provided.
>I would like to see equivalent function added to base JES2 by IBM.
>Thruput Manager provides this function
>too. Here is user doc for the Mellon Mods syntax for comparison.
>
>Thanks, Sam
>
>
> Users Guide - How to use the features of these Mods
>
>- Control Statements
>
> You take advantage of the Mellon Shared Spool mods via JECL
>statements. There are currently five supported statements, they are:
>
>"/*CNTL XEQ resource, { EXC | SHR }"
>
>"/*ROUTE XEQ secheduling environment name | HERE "
>
>"/*WITH jobname"
>
>"/*AFTER jobname"
>
>"/*BEFORE jobname"
>
> The /*CNTL XEQ statement is used to add an additional job selection
>criterion based on other executing jobs current use of the same resource
>name. The "/*CNTL XEQ" must be placed in columns 1 through 10. The
>resource name is arbitrary, and is made of up to eight (8) characters
>with no embedded blanks. The resource name follows the literal "/*CNTL"
>and must be preceded by at least one, but not more than 30 blank spaces.
>If the shared (SHR) or exclusive (EXC) keywords are used, they must
>immediately follow the resource name and be preceded by a comma. If
>neither the SHR nor EXC keyword is specified SHR is assumed.
>
>You may specify up to eight /*CNTL statements; additional statements are
>disregarded.
>
> Examples:
>
> Assume jobnames ABC, and CDE are currently in execution with the
>following /*CNTL XEQ statements -
>
> //ABC JOB (other stuff)
> /*CNTL XEQ MYNAME,SHR
>
> //CDE JOB (other stuff)
> /*CNTL XEQ MYNAME,SHR
>
>Then if job EFG is submitted with the following, /*CNTL statement -
>
> //EFG JOB (other stuff)
> /*CNTL XEQ MYNAME,EXC
>
>The job will not be selected for execution as long as either job ABC or
>CDE continues to run.
>
>Next if job XYZ is submitted with the following, /*CNTL statement -
>
> //XYZ JOB (acctng info)
> /*CNTL XEQ MYNAME Ú SHR is the default
>
> It would be immediately available for execution.
>
>When no jobs remain in execution with a /*CNTL XEQ MYNAME job EFG with
>the EXC requirement would be available for job selection. Assume it has
>now been selected, and a new job enters the system with the following
>/*CNTL statement -
>
> //WXY JOB (acctng info)
> /*CNTL XEQ MYNAME
>
> Job WXY will not be available for job execution until job XYZ that
>holds the resource name exclusively ends. If other jobs are submitted
>with resource names other than MYNAME, they will be treated separately
>and only other jobs with /*CNTL statements that reference the same
>resource name will affect their availability for job selection.
>
> The /*CNTL statement only provides additional job selection criterion,
>and does not replace other JES2 requirements for job selection such as
>available initiators, appropriate job class and so on. The resource
>name is arbitrary, you make it up, there is no need for anyone to add
>the name to WLM, or any other table before it is used.
>
>
>The /*ROUTE XEQ is a standard JES2 statement used to route your job to a
>specific execution node. We have usurped the use of the statement, and
>when we read an XEQ statement, we test to see if the name following the
>XEQ literal is a valid WLM scheduling environment name. If the name is
>a valid scheduling environment name, and if no schenv value is present
>on the JOB card, we use the XEQ name in the same way the job statement
>parameter SCHENV is used, otherwise we let JES2 handle it normally.
>
>The literal "/*ROUTE" must begin in column 1. The literal "XEQ" must
>follow "/*ROUTE", and may be separated by one to twenty blank spaces.
>The resource name, if not a valid JES2 node name, must follow the "XEQ
>literal by between 1 and 35 blank spaces. The resource name can be
>between 1 and 16 characters long, if the name is longer than 16
>characters, only the first 16 are used.
>
>There is one specific exception to all of the above, if the literal
>following XEQ is HERE, then the jobs system affinity is set to the
>system where you submitted the job, quite a handy feature itself.
>
>You may specify more than one /*ROUTE statement; but only the last will
>be used.
>
>Examples:
>
>//ABC JOB (job acctng),SCHENV=BEFOREALL
>/*ROUTE XEQ AFTERALL <== ignored because a valid schenv is specified
>
>//ABC JOB (job acctng),SCHENV=BEFOREALL
>/*ROUTE XEQ N6 <== a valid JES2 routing node, both jes2 routing and
>//* schenv are valid for this job.
>
>//ABC JOB (jobacctng)
>/*ROUTE XEQ BEFOREALL <== BEFOREALL is setup the same as SCHENV above
>
>//TUV JOB (jobacctng)
>/*ROUTE XEQ HERE <== the jobs will only execute where submitted.
>
>The /*WITH statement specifies that the job is only available for
>selection while the jobname named on the /*WITH statement is in
>execution. The condition is satisfied even if the jobname that must be
>executing is executing on a different system within the same MAS
>environment. If more than one /*WITH statement is read; only the last
>one is kept.
>
>Example:
>
>//FGH JOB (acctng info)
>/*WITH JKL
>
>This job will only be selected for execution if jobname JKL is
>executing at the time of job selection.
>
>
>The /*AFTER jobname statement specifies that the job is only available
>for selection after the jobname in the /*AFTER statement has finished.
>Because we really do not track all completed jobs, from - from when -
>the beginning of the day, the week, the last ipl, the last cold start,
>or maybe for all time, it is more correct to say that if the jobname
>specified on a /*AFTER statement is in execution at the time our job
>would otherwise have been selected for execution, then our job will wait
>until the jobname referenced in the /*AFTER statement has ended.
>"AFTER" may have been more appropriately names "NOT WHILE", but since I
>was not around when the original keywords were developed, please do not
>blame me. Again, the jobname on the /*AFTER need not be executing on
>the system that our job is potentially selected for execution on, it
>could be on any system within the MAS complex.
>
>If more than one /*AFTER card is read; only the last one is kept.
>
>Example:
>
>//ABC JOB (acctng info)
>/*AFTER XYZ
>
>Job ABC will not be available for execution while job XYZ is in
>execution anywhere within the MAS complex.
>
>
>The /*BEFORE jobname statement causes the jobname specified in the
>statement to not be selected for execution until after this job has
>completed. Specifically if jobname ABC has a /*BEFORE XYZ statement,
>then if jobname XYZ is potentially selected for execution by JES2, the
>Mellon Mods will examine all jobs on the input queue and when jobname
>ABC is found to have a /*BEFORE for job XYZ, job XYZ will be rejected as
>a potential candidate for job execution.
>
>If more than one /*BEFORE statement is read; only the last one is kept.
>
> Example:
>
>//ABC JOB (acctng info)
>/*BEFORE XYZ
>
>This before statement will cause JES2 to reject job XYZ as a potential
>candidate for job execution until after job ABC has completed execution.
>If job XYZ was already executing at the time job ABC is submitted, the
>/*BEFORE statement will not affect anything, unless there is another job
>XYZ waiting to execute. Also please note, it is possible to form a
>lockout condition where JOBA has a /*BEFORE JOBB, and JOBB has a
>/*BEFORE JOBA statement. There is no checking done for this type of
>deadly embrace.
>
> A few final notes concerning the relationship between /*BEFORE, and
>/*AFTER. Many people try to use these statements, and stack two or more
>jobs in the same PDS member and submit them all at the same time with
>one SUBMIT command. This usually works as expected, but sometimes JES2
>will NOT PROCESS the jobs in the order they appear in the submitted
>member. This can result in a job with a /*AFTER statement for a prior
>job you think JES2 has already seen and processed because of the
>sequence in the submitted member, being processed and initiated before
>JES2 ever finishes reading the job that is the object of the /*AFTER
>statement. This problem can be avoided by making sure that jobs with
>/*BEFORE and /*AFTER requirements are submitted separately from each
>other and in an appropriate sequence.
>
> In relationship to any of the statements above, when routing a job to
>another node, the additional selection criterion defined by the Mellon
>Mods statements, will follow the job to the new node, where it will
>likely no longer be appropriate. Of course if the Mellon Mods are not
>installed at the receiving node, the additional job selection
>requirements are not honored.
>
>The JES2 $DJ command output has been extended to include information
>about /*CNTL, up to eight names qualified with an "E" for exclusive, or
>an "S" for shared, one /*WITH jobname, one /*BEFORE and one /*AFTER
>jobname. Examples of the extended displays are given below, please note
>that the information is included in either the standard or long versions
>of the command.
>
>Altered Display Commands -
>
>-$DJ(25926)
> $HASP890 JOB(T0SM0TTY)
> $HASP890 JOB(T0SM0TTY) STATUS=(AWAITING EXECUTION),CLASS=X,
> $HASP890 PRIORITY=6,SYSAFF=(ANY),HOLD=(JOB),
> $HASP890 AFTER=T0SM0AF,BEFORE=T0SM0BF,WITH=T0SM0WTH,
> $HASP890 CNTL=(HOWDY-E,HOWDO-S,WILDO-S,HELLO-S)
>
>
>-$DJ(25926),LONG
> $HASP890 JOB(T0SM0TTY)
> $HASP890 JOB(T0SM0TTY) STATUS=(AWAITING EXECUTION),CLASS=X,
> $HASP890 PRIORITY=6,SYSAFF=(ANY),HOLD=(JOB),
> $HASP890 CMDAUTH=(LOCAL),OFFS=(),SECLABEL=,
> $HASP890 USERID=T0SM0,SPOOL=(VOLUMES=(JES2T1),TGS=1,
> $HASP890 PERCENT=0.0009),ARM_ELEMENT=NO,CARDS=18,
> $HASP890 REBUILD=NO,SRVCLASS=BATTSTMD,SCHENV=TEST,
> $HASP890 SCHENV_AFF=(),CC=(),AFTER=T0SM0AF,
> $HASP890 BEFORE=T0SM0BF,WITH=T0SM0WTH,
> $HASP890 CNTL=(HOWDY-E,HOWDO-S,WILDO-S,HELLO-S)
>
>
>In addition informational messages, $HASP493 and $HASP494 are written to
>the log as jobs with /*CNTL, /*WITH, /*BEFORE, or /*AFTER are read.
>Examples of the messages follow.
>
> These messages were issued for jobname T0SM0TTY
>
>$HASP944 T0SM0TTY * -- WITH JOBNAME = T0SM0WTH --
>$HASP944 T0SM0TTY * -- AFTER JOBNAME = T0SM0AF --
>$HASP944 T0SM0TTY * -- BEFORE JOBNAME = T0SM0BF --
>$HASP943 T0SM0TTY * -- CONTROL INFO = HOWDY,EXC --
>$HASP943 T0SM0TTY * -- CONTROL INFO = HOWDO,SHR --
>$HASP943 T0SM0TTY * -- CONTROL INFO = WILDO,SHR --
>$HASP943 T0SM0TTY * -- CONTROL INFO = HELLO,SHR --
>
>
> - end of text -
>====================
>This email/fax message is for the sole use of the intended
>recipient(s) and may contain confidential and privileged information.
>Any unauthorized review, use, disclosure or distribution of this
>email/fax is prohibited. If you are not the intended recipient, please
>destroy all paper and electronic copies of the original message.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>WLM managed Init's?
IIRC, Jobs are placed in queue in FIFO order within Service Class.

Same problem -- dependent on the converter time.
And, more than one init could could be started due to goals being missed.


-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Thompson, Steve]

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of David Cole
Sent: Friday, May 23, 2008 1:17 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Controlling the execution sequence of dependant jobs in
JES2 (a suggested fix)

As noted in my prior post, I think it is a shame that the IBM-JES2 folks
make it so difficult to serialize a thread of jobs. It seems to me that
this is such an obvious thing to want to do, but when JES2 is started
with CNVTNUM=>2 (and there are strong reasons for must shops to want to
do this), such serialization becomes problematic.

The thing is, a JES2 supported solution, it seems to me, would be both
ideal and easy to implement. Here's my idea:

(1) support a //card option or a /*card option by which a user could
provide an arbitrary serialization name. Example: /*JOBPARM
THREADNAME=xyz. Use this name on each job in the thread.
<SNIP>

How about getting IBM to support //*NET in the JES2 world?

Wouldn't that get you what you are after (assuming you have used JES3
and know about NETWORKED JOBS).

Regards,
Steve Thompson

-- All opinions expressed by me are my own and may not necessarily
reflect those of my employer. --

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ted MacNEIL]

>I think it is a shame that the IBM-JES2 folks
make it so difficult to serialize a thread of jobs. It seems to me that this is such an obvious thing to want to do, but when JES2 is started with CNVTNUM=>2 (and there are strong reasons for must shops to want to do this), such serialization becomes problematic.

>The thing is, a JES2 supported solution, it seems to me, would be both ideal and easy to implement

Blather! Blather! Blather!

IBM does not take complaints on IBM-Main as requirements.

You want changes?
Go through the channels.

I'm sorry it doesn't work as desired, but b*tching here will not change anything.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Knutson, Sam]

OTOH IBM-MAIN is a great place to brain storm and refine a requirement
before submitting it to IBM as a marketing request or through SHARE.
A unique audience of customers, ISV developers, and IBM folks exists
here that is usually not available to comment unless you stumble into
the right hotel bar during the week SHARE is in town:-) Complaints
voiced here may lead to others pointing out available solutions or full
understanding of the history that lead to the current behavior.

Best Regards,

Sam Knutson, GEICO
System z Performance and Availability Management
mailto:***@geico.com
(office) 301.986.3574

"Think big, act bold, start simple, grow fast..."


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of Ted MacNEIL
Sent: Friday, May 23, 2008 6:00 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Controlling the execution sequence of dependant jobs in
JES2 (a suggested fix)

>I think it is a shame that the IBM-JES2 folks
make it so difficult to serialize a thread of jobs. It seems to me that
this is such an obvious thing to want to do, but when JES2 is started
with CNVTNUM=>2 (and there are strong reasons for must shops to want to
do this), such serialization becomes problematic.

>The thing is, a JES2 supported solution, it seems to me, would be both
ideal and easy to implement

Blather! Blather! Blather!

IBM does not take complaints on IBM-Main as requirements.

You want changes?
Go through the channels.

I'm sorry it doesn't work as desired, but b*tching here will not change
anything.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

Thanks Sam! You're response was immensely better than mine would have been.

Dave


At 5/23/2008 10:11 PM, Knutson, Sam wrote:
>OTOH IBM-MAIN is a great place to brain storm and refine a
>requirement before submitting it to IBM as a marketing request or
>through SHARE. A unique audience of customers, ISV developers, and
>IBM folks exists here that is usually not available to comment
>unless you stumble into the right hotel bar during the week SHARE is
>in town:-) Complaints voiced here may lead to others pointing out
>available solutions or full understanding of the history that lead
>to the current behavior.
>
> Best Regards,
>
> Sam Knutson, GEICO
> System z Performance and Availability Management
> mailto:***@geico.com
> (office) 301.986.3574
>
>"Think big, act bold, start simple, grow fast..."

Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]




>-----Original Message-----
>>From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
>>Behalf Of Ted MacNEIL
>>Sent: Friday, May 23, 2008 6:00 PM
>>To: IBM-***@BAMA.UA.EDU
>>Subject: Re: Controlling the execution sequence of dependant jobs in
>>JES2 (a suggested fix)
>>
>>>I think it is a shame that the IBM-JES2 folks make it so difficult
>>>to serialize a thread of jobs. It seems to me that this is such an
>>>obvious thing to want to do, but when JES2 is started with
>>>CNVTNUM=>2 (and there are strong reasons for must shops to want to
>>>do this), such serialization becomes problematic.
>>>
>>>The thing is, a JES2 supported solution, it seems to me, would be
>>>both ideal and easy to implement
>>
>>Blather! Blather! Blather!
>>
>>IBM does not take complaints on IBM-Main as requirements.
>>
>>You want changes? Go through the channels.
>>
>>I'm sorry it doesn't work as desired, but b*tching here will not
>>change anything.
>>
>>-
>>Too busy driving to stop for gas!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote:

>As noted in my prior post, I think it is a shame that the IBM-JES2
>folks make it so difficult ...
>
And that JES2 doesn't do device setup and highwater mark reservation,
and that JES2 doesn't verify data set availability, and that JES2
doesn't do better syntax checking, and that JES2 doesn't check for
duplicate DDNAMEs within a step, and that JES2 doesn't balance load
across systems, and ...

If JES2 did everything that JES3 does, it wouldn't be JES2 any
more, would it? Am I right in assuming that JES3 costs more than
JES2? Doesn't the vendor, then need to provide differentiating
features to justify the expense? Of course, it's only human
nature to wish that one's only favorite feature were added as
an enhancement to the lower priced product.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gibney, Dave]

JES2 or JES3 or both are choices when installing z/OS. No price
differential.

And I'm sure Mr. Cole does well enough enhancing and selling XDC to
believe he doesn't need a job with IBM.

On the other hand, the JES2 folks have been know to add function (exit
loader as a recent example) and some way of supporting FIFO is something
I wanted a decade ago or more. In the end we just did with out and used
carbon based processors to sort the reams of output. Putting Mellon mods
on wasn't an option then, and might not have been adequate anyway given
this latest discussion.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, May 23, 2008 8:17 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: Controlling the execution sequence of dependant jobs in
JES2
> (a suggested fix)
>
> On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote:
>
> >As noted in my prior post, I think it is a shame that the IBM-JES2
> >folks make it so difficult ...
> >
> And that JES2 doesn't do device setup and highwater mark reservation,
> and that JES2 doesn't verify data set availability, and that JES2
> doesn't do better syntax checking, and that JES2 doesn't check for
> duplicate DDNAMEs within a step, and that JES2 doesn't balance load
> across systems, and ...
>
> If JES2 did everything that JES3 does, it wouldn't be JES2 any
> more, would it? Am I right in assuming that JES3 costs more than
> JES2? Doesn't the vendor, then need to provide differentiating
> features to justify the expense? Of course, it's only human
> nature to wish that one's only favorite feature were added as
> an enhancement to the lower priced product.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Edward Jaffe]

Gibney, Dave wrote:
> JES2 or JES3 or both are choices when installing z/OS. No price
> differential.
>

Like many components installed with ServerPac, JES3 is an
optionally-priced feature of z/OS. It is activated via IFAPRDxx in parmlib.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
***@phoenixsoftware.com
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gibney, Dave]

Sorry, I didn't know it was extra. Thank you

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
> Behalf Of Edward Jaffe
> Sent: Saturday, May 24, 2008 12:27 AM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: Controlling the execution sequence of dependant jobs in
JES2
> (a suggested fix)
>
> Gibney, Dave wrote:
> > JES2 or JES3 or both are choices when installing z/OS. No price
> > differential.
> >
>
> Like many components installed with ServerPac, JES3 is an
> optionally-priced feature of z/OS. It is activated via IFAPRDxx in
> parmlib.
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 5200 W Century Blvd, Suite 800
> Los Angeles, CA 90045
> 310-338-0400 x318
> ***@phoenixsoftware.com
> http://www.phoenixsoftware.com/
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Kenneth E Tomiak]

Or even try to turn a product that does one thing to incorporate another
product for free. Job schedulers exists to manage the serialization and
coordination of jobs beyond mere submittal. The free alternative is already
there, they can put an IEBGENER step at the end of the a job to submit the
next one.

Just because David would JES2 to handle scheduling does not mean
implementing it would be easy. Laying out how he would like the interface is
but the tip of the iceberg.

Entering real requirements to IBM is one way. He can also get a job with IBM,
become the head of JES2 and fight for his cause.


On Fri, 23 May 2008 22:16:41 -0500, Paul Gilmartin <***@AIM.COM>
wrote:

>On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote:
>
>>As noted in my prior post, I think it is a shame that the IBM-JES2
>>folks make it so difficult ...
>>
> Of course, it's only human
>nature to wish that one's only favorite feature were added as
>an enhancement to the lower priced product.
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

At 5/24/2008 12:16 AM, Kenneth E Tomiak wrote:
>Just because David would JES2 to handle scheduling does not mean
>implementing it would be easy. Laying out how he would like the
>interface is but the tip of the iceberg.

As indicated in my post, I've had experience as a JES2 programmer
(about two decades worth). By that I mean, that once upon a time I
knew intimately the details of JES2's internal structures and logic,
and that I wrote many dozens of simple and complex mods to JES2 (and
HASP) for various employers from the '60s (at Rutgers, then Yale)
into the '80s (for DC bandits).

So my estimate, that implementing the support that I suggested would
not be too difficult and could be done in a matter of weeks, was
based on experience, not random guessing.

Certainly, my suggestion is potentially just a first step in a far
more complex set of issues that arise should you decide to expand my
idea into a more comprehensive job networking solution, but I was by
no means suggesting that. After all, as is well known, there already
are 3rd party solutions that deal with those complexities quite well.

All I was suggesting was a very simple mechanism by which jobs could
be guaranteed to run in the order submitted, nothing more, nothing
less. This guarantee is already there for some JES2 users (those with
CNVTNUM=1). Why not make it possible for everybody?






At 5/24/2008 12:16 AM, Kenneth E Tomiak wrote:
>Just because David would [want] JES2 to handle scheduling does not
>mean implementing it would be easy. Laying out how he would like the
>interface is but the tip of the iceberg.
>
>Entering real requirements to IBM is one way. He can also get a job
>with IBM, become the head of JES2 and fight for his cause.

Saying that what I proposed is "my cause" is a bit of an
overstatement. ;-) I was just making a suggestion, not a demand. As
I've already noted, I already have my solution to the problem.

Saying that I wanted "JES2 to handling scheduling" also is an
overstatement. All I did was suggest a very simple way by which JES2
could be changed so that it could guarantee job sequencing, should a
user want it. That is a far cry from job scheduling.






At 5/23/2008 11:16 PM, Paul Gilmartin wrote:
>On Fri, 23 May 2008 14:16:55 -0400, David Cole wrote:
>>As noted in my prior post, I think it is a shame that the IBM-JES2
>>folks make it so difficult ...
>
>And that JES2 doesn't do device setup and highwater mark
>reservation, and that JES2 doesn't verify data set availability, and
>that JES2 doesn't do better syntax checking, and that JES2 doesn't
>check for duplicate DDNAMEs within a step, and that JES2 doesn't
>balance load across systems, and ...
>
>If JES2 did everything that JES3 does, it wouldn't be JES2 any more,
>would it? Am I right in assuming that JES3 costs more than
>JES2? Doesn't the vendor, then need to provide differentiating
>features to justify the expense? Of course, it's only human nature
>to wish that one's only favorite feature were added as an
>enhancement to the lower priced product.

I am not suggesting a convergence between JES2 and JES3 (although
there has already been a considerable amount of that since the old
HASP vs. ASP wars). I also am not suggesting anything that would be
complex or difficult to implement (such as the several JES3 features
that you referenced).

I was just saying that it would be such a simple thing to do, and
that because it is so simple, I feel that it's a shame that IBM doesn't do it.






At 5/23/2008 11:16 PM, Paul Gilmartin wrote:
>Am I right in assuming that JES3 costs more than JES2?

I don't think that you are correct (at least not directly). IIRC,
JES2/JES3 is just a choice you make when ordering a system. There is
no additional charge for either. (But also IIRC, doesn't JES3 consume
more resources than JES2 and so costs would be increased in that way?
Our are my prejudices obsolete?)



Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Eric Bielefeld]

I hope your being faceteous (not sure if thats spelled right). He'll just
apply at IBM for a job, and then tell them he's going to become the
head of JES2!!

I liked Sam Knudson's response yesterday, I think on this topic, where
someone made the reply that they should go to IBM with their
complaints and requests. His response was that this is a great place
to talk about complaints, and then go to IBM.

Eric Bielefeld

On Fri, 23 May 2008 23:16:43 -0500, Kenneth E Tomiak
<***@KTOMIAK.BIZ> wrote:

>Snip
>Entering real requirements to IBM is one way. He can also get a job
with IBM,
>become the head of JES2 and fight for his cause.
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Elardus Engelbrecht]

David Cole wrote:
>All I was suggesting was a very simple mechanism by which jobs could be
guaranteed to run in the order submitted, nothing more, nothing less. This
guarantee is already there for some JES2 users (those with CNVTNUM=1).
Why not make it possible for everybody?

Seeing you got several different excellent replies, please allow me to give you
a proposed solution. It may or may not work for you:

Write a REXX or CLIST where you submit jobs using a list of members as input.
Put a waiting subroutine (a simple DO loop) between each submission long
enough to allow JES2 to convert the job and place it in the Input Queue. Wait
time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions.

Having the same jobname for all jobs and placing everything in one input
queue will help you there.

I do this for 'ad hoc' requests (Not scheduled) where I create datasets,
create several audit reports and then finally FTP them to customers together
with e-mail(s) stating that the audit reports are ready. After FTP everything is
then deleted. Some these jobs do indeed submit other jobs via IEBGENER as a
last step as suggested earlier in this thread.

Will this help you?

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

That's pretty good idea, Elardus.

Thanks,
Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]



At 5/27/2008 07:11 AM, Elardus Engelbrecht wrote:
>David Cole wrote:
> >All I was suggesting was a very simple mechanism by which jobs could be
>guaranteed to run in the order submitted, nothing more, nothing less. This
>guarantee is already there for some JES2 users (those with CNVTNUM=1).
>Why not make it possible for everybody?
>
>Seeing you got several different excellent replies, please allow me
>to give you
>a proposed solution. It may or may not work for you:
>
>Write a REXX or CLIST where you submit jobs using a list of members as input.
>Put a waiting subroutine (a simple DO loop) between each submission long
>enough to allow JES2 to convert the job and place it in the Input Queue. Wait
>time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions.
>
>Having the same jobname for all jobs and placing everything in one input
>queue will help you there.
>
>I do this for 'ad hoc' requests (Not scheduled) where I create datasets,
>create several audit reports and then finally FTP them to customers together
>with e-mail(s) stating that the audit reports are ready. After FTP
>everything is
>then deleted. Some these jobs do indeed submit other jobs via IEBGENER as a
>last step as suggested earlier in this thread.
>
>Will this help you?
>
>Groete / Greetings
>Elardus Engelbrecht
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Edward Jaffe]

Elardus Engelbrecht wrote:
> Write a REXX or CLIST where you submit jobs using a list of members as input.
> Put a waiting subroutine (a simple DO loop) between each submission long
> enough to allow JES2 to convert the job and place it in the Input Queue. Wait
> time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions.
>

If you use FTP to submit jobs, you can wait for job *completion* before
submitting the next one.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
***@phoenixsoftware.com
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Vernooy, C.P. - SPLXM]

The pittfall of this construction is in the "usually 3 to 5 seconds".
Checkout how big your problems will be in the situation that it is more
than that, due to whatever reason.

Kees.


"David Cole" <***@COLESOFT.COM> wrote in message
news:<***@ame8.swcp.com>...
> That's pretty good idea, Elardus.
>
> Thanks,
> Dave Cole REPLY TO: ***@colesoft.com
> Cole Software WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow Road VOICE: 540-456-8536
> Afton, VA 22920 FAX: [phone]
>
>
>
> At 5/27/2008 07:11 AM, Elardus Engelbrecht wrote:
> >David Cole wrote:
> > >All I was suggesting was a very simple mechanism by which jobs
could be
> >guaranteed to run in the order submitted, nothing more, nothing less.
This
> >guarantee is already there for some JES2 users (those with
CNVTNUM=1).
> >Why not make it possible for everybody?
> >
> >Seeing you got several different excellent replies, please allow me
> >to give you
> >a proposed solution. It may or may not work for you:
> >
> >Write a REXX or CLIST where you submit jobs using a list of members
as input.
> >Put a waiting subroutine (a simple DO loop) between each submission
long
> >enough to allow JES2 to convert the job and place it in the Input
Queue. Wait
> >time in a busy JES2 Sysplex is usually 3 to 5 seconds between job
conversions.
> >
> >Having the same jobname for all jobs and placing everything in one
input
> >queue will help you there.
> >
> >I do this for 'ad hoc' requests (Not scheduled) where I create
datasets,
> >create several audit reports and then finally FTP them to customers
together
> >with e-mail(s) stating that the audit reports are ready. After FTP
> >everything is
> >then deleted. Some these jobs do indeed submit other jobs via
IEBGENER as a
> >last step as suggested earlier in this thread.
> >
> >Will this help you?
> >
> >Groete / Greetings
> >Elardus Engelbrecht
> >
>
>----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to ***@bama.ua.edu with the message: GET IBM-MAIN
INFO
> >Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Chris Hoelscher]

we in fact have a in-house production "utility" that does exactly that kind
of looping suggested - except that we have the number of seconds to loop as
a parm on the exec card - not exactly a guarentee, but changing a parm on
an execute JCL is easier than re-writing a rexx or assembler ... (and
avoids the one-size fits all scenerio)


Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
***@humana.com



The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

---------------------<snip>--------------------
we in fact have a in-house production "utility" that does exactly that
kindof looping suggested - except that we have the number of seconds to
loop as a parm on the exec card - not exactly a guarentee, but changing
a parm on an execute JCL is easier than re-writing a rexx or assembler
... (and avoids the one-size fits all scenerio)
---------------------<unsnip>--------------------
That's a very good idea, Chris. Let me suggest a modification: wait
until a job has finished conversion and is queued for execution before
submitting the next job. Use the subsystem interfaces for submitting the
job and checking on it's status. Could be a gold mine in disguise.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Hal Merritt]

Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several
other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any
job, but only one of a thread at a time), and so on.

They died out many moons ago, perhaps because they mods became a upgrade
nightmare, or perhaps it was the OCO. More, the job schedulers became
sophisticated and powerful enough to handle the most complex of these
issues.

So, my $0.02 (before taxes) would be to consider a job scheduler. One
big benefit is you can have one tomorrow as opposed to waiting
potentially years for IBM to consider JES modifications.



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of David Cole
Sent: Friday, May 23, 2008 1:17 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Controlling the execution sequence of dependant jobs in
JES2 (a suggested fix)

As noted in my prior post, I think it is a shame that the IBM-JES2
folks make it so difficult to serialize a thread of jobs. It seems to
me that this is such an obvious thing to want to do, but when JES2 is
started with CNVTNUM=>2 (and there are strong reasons for must shops
to want to do this), such serialization becomes problematic.

The thing is, a JES2 supported solution, it seems to me, would be
both ideal and easy to implement. Here's my idea:

(1) support a //card option or a /*card option by which a user could
provide an arbitrary serialization name. Example: /*JOBPARM
THREADNAME=xyz. Use this name on each job in the thread.

(2) Run the threaded jobs into a reader in the same order that you
want the jobs to run. (Allow subsequent SUBMITs to add to a thread,
if desired.)

(3) The first converter to pick up one of the threaded jobs will
always pick up the first one.

(4) When that converter sees the thread name, it takes ownership of
that thread such that all other converters will refuse to process
jobs having that same name.

Then, of course, the jobs would be queued for execution in the same
order by which they were read, and if only one initiator ware
assigned the thread's execution class, then they would, in fact,
execute in that same order.

There are, of course, several ancillary details:
* Thread names will have to have some reasonable expiration
interval.
* $D/$T command will need to allow operators to display and
manipulate threads to allow them to display and fix problems.
* Some mechanism (ownerid perhaps?) need to be created to prevent
unrelated threads having the same name from colliding.
It's been several decades since I used to be a JES2 programmer, but
from what I remember, it doesn't seem to me that this should be too
hard. I'd guess that implementing such a scheme would take maybe only
a week or few of my time.

Dave Cole REPLY TO: ***@colesoft.com
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: [phone]



NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Cole]

The Mellon Bank Mods were written prior to JES2's ability to run more
than one converter process. Consequently, they do not guarantee
serialization for the same reason that CNVTNUM=>2 users don't get
serialization. For more info, see:
http://bama.ua.edu/cgi-bin/wa?A2=ind0805&L=IBM-MAIN&P=R89127&X=5479D13E719614079C&Y=dbcole%40colesoft.com

Dave

At 5/27/2008 10:51 AM, Hal Merritt wrote:
>Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several
>other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any
>job, but only one of a thread at a time), and so on.
>
>They died out many moons ago, perhaps because they mods became a upgrade
>nightmare, or perhaps it was the OCO. More, the job schedulers became
>sophisticated and powerful enough to handle the most complex of these
>issues.
>
>So, my $0.02 (before taxes) would be to consider a job scheduler. One
>big benefit is you can have one tomorrow as opposed to waiting
>potentially years for IBM to consider JES modifications.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Richards, Robert B.]

Steve is having a little trouble posting to IBM-Main, so I am posting
this for him. See below:



Howdy,



I didn't catch the beginning of this thread, but I would like you to
know that the Mellon Mods are alive and well! Although I decided a year
or so ago that we should start calling them the SHARED SPOOL MODS, since
I have maintained them for a dozen or so years now, and have done a
completed re-write twice in that time. ANYWAY, they can still be found
on the CBT TAPE website, go to "latest updates are always available to
download here" (at the bottom of the light blue box) then scroll down to
file # 766, Shared Spool Mods- "Mellon" for JES2 z/OS1.7 and 1.8. I
will do 1.9 after we get it ordered ourselves.



I have included in this distribution an INSTALLATION MANUAL, an
OPERATIONS COMMAND MANUAL, and a USER'S MANUAL to explain everything
better than in the past. We can now handle a number of different
methods of controlling how and when jobs do and do not become eligible
for selection including the following:



/*AFTER jobname (allow execution after jobname jobname runs)

/*BEFORE jobname ( same as after, but before!)

/*WITH jobname (only run if and where jobname jobname runs)

/*WITHOUT jobname (run where jobname is not running)

/*HOLDFOR hh:mm:ss (hold the job in the input queue for hh:mm:ss)

/*HOLDTIL hh:mm:ss (hold the job on the input queue until
hh:mm:ss)

/*CNTL resname,EXC (control execution of a number of jobs using

/*CNTL resname,SHR an arbitrary resname, and EXCLUSIVE or
SHARED Control(same basic logic as an ENQ but for
jobs).

/*ROUTE XEQ resname for compatibility - works just like SCHENV=

This was the original reason for these
mods.

Those are the features that are used by the users - the JCL coders.



On the operations side of things, we have begun cutting some SMF
records for some many of the actions we take. We have enhanced the $DJ
command to display reasons that a job may be delayed while in the input
queue. We implemented a number of changes specifically because of WLM
managed inits including, the ability to limit (or stop) the number of
jobs started on any lpar, for a given class, the ability to limit the
number of total jobs that match a specific jobmask, or userid mask, this
prevents one user or group of users from monopolizing resources. The
ability to limit jobs by class, within a single LPAR, gives us the
ability to use WLM managed inits for classes that must not be allowed to
execute on all systems - tape class jobs are limited in our shop for
instance and not allowed to run on some of our lpars, while WLM still
manages the class on the remaining lpars in the MAS. There are other
real advantages to limiting or stopping WLM managed jobs by class when
you start into a maintenance window if you think about it.



As has been the case for at least the last eight years, no changes to
JES2 code, this is all implemented via exits, all source is provided,
and is packaged in SMP/E format. PLUS, if anyone tells me they installed
them, I have a box of coffee cups in my basement that all say "I
INSTALLED THE SHARED SPOOL MODS", that I am still trying to give away. I
just need to know where to send them.



Future changes that I plan to make include Automatic resource routing

based on Program or PROC names. Automatic job Classing (changes the

jobclass) based on program or proc, or owning userid, step completion
notification options, HSM dataset recall at job reader time (or just
prior to job execution time for time delayed jobs), and others. In
short - if you haven't looked at the Shared Spool Mods lately - you
probably should, they do a lot more now, and will do even more in the
near future.



***@SunTrust.com



Stephen McColley

Enterprise Information Services

SunTrust Banks, Inc.

Tel: [phone]

---------------------------------------------------------

Robert B. Richards (Bob)

US Office of Personnel Management

1900 E Street NW Room: BH04L

Washington, D.C. 20415

Phone: [phone]

Email: ***@opm.gov

---------------------------------------------------------



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
Behalf Of David Cole
Sent: Tuesday, May 27, 2008 11:18 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Controlling the execution sequence of dependant jobs in
JES2 (a suggested fix)





snipped


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <***@HTXMAIL.jhacorp.com>, on
05/27/2008
at 09:51 AM, Hal Merritt <***@JACKHENRY.COM> said:

>Doesn't anyone remember the famous 'Mellon Bank Mods'?

Yes. I'd guess that about 20% of the list readership does.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Mark Zelden]

On Tue, 27 May 2008 09:51:33 -0500, Hal Merritt <***@JACKHENRY.COM> wrote:

>Doesn't anyone remember the famous 'Mellon Bank Mods'? Among several
>other useful features, they offered /*BEFORE, /*AFTER, exclusivity (any
>job, but only one of a thread at a time), and so on.
>
<snip>

Yes. I mentioned them in one of the first responses to Dave and Sam
also mentioned them (with a lot more detail).

http://bama.ua.edu/cgi-bin/wa?A2=ind0805&L=ibm-main&D=1&amp;O=D&T=0&P=193078

http://bama.ua.edu/cgi-bin/wa?A2=ind0805&L=ibm-main&D=1&amp;T=0&O=D&F=&S=&P=202977

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:***@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gary Green]

That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked.

If someone has different information, I would love to hear it.


On Tue May 27 7:09 , Edward Jaffe <***@PHOENIXSOFTWARE.COM> sent:

>Elardus Engelbrecht wrote:
>> Write a REXX or CLIST where you submit jobs using a list of members as input.
>> Put a waiting subroutine (a simple DO loop) between each submission long
>> enough to allow JES2 to convert the job and place it in the Input Queue. Wait
>> time in a busy JES2 Sysplex is usually 3 to 5 seconds between job conversions.
>>
>
>If you use FTP to submit jobs, you can wait for job *completion* before
>submitting the next one.
>
>--
>Edward E Jaffe
>Phoenix Software International, Inc
>5200 W Century Blvd, Suite 800
>Los Angeles, CA 90045
>310-338-0400 x318
>***@phoenixsoftware.com
>http://www.phoenixsoftware.com/
>
>----------------------------------------------------------------------

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Edward Jaffe]

Gary Green wrote:
> That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked.
>
> If someone has different information, I would love to hear it.
>

You should be using 'JESINTERFACE:EVEL 2'

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
***@phoenixsoftware.com
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Big Iron]

No, if you use JES interface level 2 with FTP, you can use any job name.

Bill

On Tue, 27 May 2008 12:16:30 -0400, Gary Green <***@EVERGREEN-SYSTEMS.COM>
wrote:

>That's if the job names used are the FTP logon userid +1 character. If
they are different, the jobs are not tracked.
>
>If someone has different information, I would love to hear it.
>
>
> On Tue May 27 7:09 , Edward Jaffe <***@PHOENIXSOFTWARE.COM> sent:
>
>>Elardus Engelbrecht wrote:
>>> Write a REXX or CLIST where you submit jobs using a list of members as
input.
>>> Put a waiting subroutine (a simple DO loop) between each submission long
>>> enough to allow JES2 to convert the job and place it in the Input Queue.
Wait
>>> time in a busy JES2 Sysplex is usually 3 to 5 seconds between job
conversions.
>>>
>>
>>If you use FTP to submit jobs, you can wait for job *completion* before
>>submitting the next one.
>>
>>--
>>Edward E Jaffe
>>Phoenix Software International, Inc
>>5200 W Century Blvd, Suite 800
>>Los Angeles, CA 90045
>>310-338-0400 x318
>>***@phoenixsoftware.com
>>http://www.phoenixsoftware.com/
>>
>>----------------------------------------------------------------------
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gary Green]

That makes all the off-topic discussions, admittedly some started by me, worth it!

Thanks!

On Tue May 27 10:23 , Edward Jaffe <***@PHOENIXSOFTWARE.COM> sent:

>Gary Green wrote:
>> That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked.
>>
>> If someone has different information, I would love to hear it.
>>
>
>You should be using 'JESINTERFACE:EVEL 2'
>
>--
>Edward E Jaffe
>Phoenix Software International, Inc
>5200 W Century Blvd, Suite 800
>Los Angeles, CA 90045
>310-338-0400 x318
>***@phoenixsoftware.com
>http://www.phoenixsoftware.com/
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Schmidt]

On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote:

>Gary Green wrote:
>> That's if the job names used are the FTP logon userid +1 character. If
they are different, the jobs are not tracked.
>>
>> If someone has different information, I would love to hear it.
>>
>
>You should be using 'JESINTERFACE:EVEL 2'


They spelled 'EVIL' wrong, didn't they?

--
Tom Schmidt
(I'm still working on EVIL1)


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Edward Jaffe]

Tom Schmidt wrote:
> On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote:
>
>> You should be using 'JESINTERFACE:EVEL 2'
>>
>
>
> They spelled 'EVIL' wrong, didn't they?
>

Mr. Knievel might disagree. :-)

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
***@phoenixsoftware.com
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gary Green]

My assumption was his fingers were typing faster than the Windows-controlled keyboard could handle and dropped the "L". ;-)


On Tue May 27 14:04 , Tom Schmidt <***@OASSOFTWARE.COM> sent:

>On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote:
>
>>Gary Green wrote:
>>> That's if the job names used are the FTP logon userid +1 character. If
>they are different, the jobs are not tracked.
>>>
>>> If someone has different information, I would love to hear it.
>>>
>>
>>You should be using 'JESINTERFACE:EVEL 2'
>
>
>They spelled 'EVIL' wrong, didn't they?
>
>--
>Tom Schmidt
>(I'm still working on EVIL1)
>
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Tom Schmidt]

On Tue, 27 May 2008 12:17:33 -0700, Edward Jaffe wrote:

>Tom Schmidt wrote:
>> On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote:
>>
>>> You should be using 'JESINTERFACE:EVEL 2'
>>>
>>
>>
>> They spelled 'EVIL' wrong, didn't they?
>>
>
>Mr. Knievel might disagree. :-)


So you need to be a daredevil to want to use that option?

--
Tom Schmidt
(It allows you to skip 50 batch jobs in a single jump of a virtual motorcycle??)


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gary Green]

Yes... Now that he jumped over 24 delivery vans. About 10-12 more than his father.


On Tue May 27 12:17 , Edward Jaffe <***@PHOENIXSOFTWARE.COM> sent:

>Tom Schmidt wrote:
>> On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote:
>>
>>> You should be using 'JESINTERFACE:EVEL 2'
>>>
>>
>>
>> They spelled 'EVIL' wrong, didn't they?
>>
>
>Mr. Knievel might disagree. :-)
>
>--
>Edward E Jaffe
>Phoenix Software International, Inc
>5200 W Century Blvd, Suite 800
>Los Angeles, CA 90045
>310-338-0400 x318
>***@phoenixsoftware.com
>http://www.phoenixsoftware.com/
>
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Tue, 27 May 2008 12:17:33 -0700, Edward Jaffe <***@PHOENIXSOFTWARE.COM> wrote:

>Tom Schmidt wrote:
>> On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote:
>>
>>> You should be using 'JESINTERFACE:EVEL 2'
>>>
>>
>>
>> They spelled 'EVIL' wrong, didn't they?
>>
>
>Mr. Knievel might disagree. :-)
>
We've got to stop the OT-ness. I won't prolong the
thread by posting to the list; rather to the individual.

As controversial as my remarks often are, I think I usually stay
closer to the charter than the above, even when I hijack the
topic.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Clement Clarke]

You might find this interesting to look at.

http://members.ozemail.com.au/~oscarptyltd/Jol_Scheduling_and_Networking_Guide.pdf


I will send more information tomorrow.

Thoughts create things. So we can see what we have created, people and
the universe reflect back to us. So, think beautiful thoughts. They
will come back to you.

And, in computer technology, think simplicity and ease of use. Which
was what I wanted when I created the easy network and scheduling facility.



Clement Clarke

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html