An amusing REXX program - JES2DISK == copies JES output to disk using REXX's SDSF API
McKown, John
Invocation: JES2DISK jobname_or_prefix_with_a_* 'disk_hlq_or_UNIX_subdirectory'
example: copy all ABC* jobs to ABC001.SPOOL.jobname.jobid dataset: JES2DISK ABC* 'ACB001.SPOOL'
copy all ABC* jobs to /u/ACB001/sysout/jobname.jobid.txt: JES2DISK ABC* '/u/ACB001/sysout'
I thought the .txt at the end of the UNIX filename would be helpful if downloaded to Windows.
<program language='REXX'>
/* REXX */
PARSE ARG JOBNAME HLQ .
IF JOBNAME='' THEN JOBNAME='*'
HLQ=STRIP(HLQ,'B',"'")
IF HLQ='' THEN HLQ='SYSJO'
XX=ISFCALLS('ON')
ISFSORT='JOBID'
ISFPREFIX=JOBNAME
IF XX <> 0 THEN DO
SAY 'ISFCALLS RC='XX
RETURN XX
END
ADDRESS SDSF 'ISFEXEC ST (DELAYED)'
IF RC <> 0 THEN DO
SAY 'ISFEXEC RC='RC
RETURN RC
END
DO IX=1 TO JNAME.0
/* "LISTALC SYSNAMES STATUS" */
IF QUEUE.IX <> 'PRINT' & ,
QUEUE.IX <> 'OUTPUT' ,
THEN ITERATE
SAY 'JBN='JNAME.IX' JOBNUMBER='JOBID.IX' QUEUE='QUEUE.IX
IF '/' = LEFT(HLQ,1) THEN DO
SAY ,
'CC=BPXWDYN("ALLOC DD(SYSJO) FILEDATA(TEXT) "'||,
"PATH('"HLQ"/"JNAME.IX"."JOBID.IX".txt') " ||,
" PATHMODE(SIRWXU) PATHOPTS(OEXCL,OCREAT,OWRONLY) " ||,
" MSG(WTP)"
CC=BPXWDYN("ALLOC DD(SYSJO) FILEDATA(TEXT) ",
"PATH('"HLQ"/"JNAME.IX"."JOBID.IX".txt') ",
" PATHMODE(SIRWXU) PATHOPTS(OEXCL,OCREAT,OWRONLY) ",
" MSG(WTP)")
END
ELSE DO
SAY ,
"ALLOC DDN(SYSJO) DSN('"HLQ"."JNAME.IX"."JOBID.IX"')",
" RECFM(V B A) LRECL(255) BLKSIZE(27998) ",
" NEW CATALOG SPACE(10,50) CYLINDERS RELEASE"
"ALLOC DDN(SYSJO) DSN('"HLQ"."JNAME.IX"."JOBID.IX"')",
" RECFM(V B A) LRECL(255) BLKSIZE(27998) ",
" NEW CATALOG SPACE(10,50) CYLINDERS RELEASE"
CC=RC
END
IF CC <> 0 THEN DO
SAY "FAILED TO ALLOCATE "JNAME.IX"."JOBID.IX
ITERATE
END
ADDRESS SDSF "ISFACT ST TOKEN('"TOKEN.IX"') PARM(NP SA)"
DO JX=1 TO ISFDDNAME.0
DO FOREVER
"EXECIO 10000 DISKR "ISFDDNAME.JX"(STEM LINE. "
LINES = LINE.0
IF RC=2 THEN RC=0
IF RC <> 0 THEN DO
SAY "LINES READ="LINES" RC="RC
EXIT 12;
END
"EXECIO * DISKW SYSJO (STEM LINE."
DROP LINE.
IF LINES<10000 THEN LEAVE
END
"EXECIO 0 DISKR "ISFDDNAME.JX"(FINIS"
END
DROP ISFDDNAME.
"EXECIO 0 DISKW SYSJO (FINIS"
"FREE DDN(SYSJO)"
END
</program>
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Elliot, David
By the way, surely UNIX must be approaching legacy status by now. Or is that expression reserved for the despised IBM mainframe?
David Elliot
zSeries Software Support
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Elliot, David
> Sent: Friday, March 26, 2010 2:51 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: An amusing REXX program - JES2DISK == copies JES
> output to disk using REXX's SDSF API
>
> on a boring Friday afternoon and a ready made program drops
> into my lap. A sort of DIY sysout archiver. Better keep it to
> ourselves though. I know people who, having no trust in
> schedulers, return codes, SMF or any of that nonsense, use
> this sort of thing to determine whether their job worked or not.
>
> By the way, surely UNIX must be approaching legacy status by
> now. Or is that expression reserved for the despised IBM mainframe?
>
> David Elliot
>
> zSeries Software Support
Well, I use "legacy" around here because so many of us mainframers still think of z/OS UNIX as "that new upstart" to "our beloved z/OS". Today, everything is "legacy". Even that mangy cur of a Windows system. UNIX is almost as old as MVT.
--
Paul Gilmartin
>
>By the way, surely UNIX must be approaching legacy status by now. Or is that expression reserved for the despised IBM mainframe?
>
Partly because it's not burdened with the legacy of a CKD FS.
Partly because UNIX eluded the severe storage constraints of
early OS which prohibited valuable design abstraction, requiring
programmers to deal too directly with hardware specifics. (Why
isn't z/OS a 64-bit OS? Why isn't z/OS even a 31-bit OS?)
Partly because IBM considered PL/S a strategic advantage and
didn't make it available to the customer base (at a suitable
price). This deprived customers of an abstraction layer,
imprisoning them in a mid-20th Century architecture, in turn
likewise imprisoning IBM's designers themselves.
Partly because the UNIX designers had a culture or mindset such that
they when given a requirement, they thought, "How can we implement
this so it benefits the greatest part of the user community?"
rather than "What is the minimal implementation that meets the
letter of the given requirement?" JES is a case in point.
Prior to JES, Data Management facilities were unsuitable for
the needs of spooling. So the designers devised a new filesystem
for JES, but stopped there, short of making the benefits of the
JES FS available to the user community generally.
-- gil
Mark Zelden
spool and restoring to a test spool back at the home shop, or writing all
the output via external writer to a single data set, we use the program
at DR. It creates a flat file for each job in the spool using "ST" as
the list of jobs to process. Then we "reverse" mirror the output disk
volume so we have all the data back at the shop. People can easily
find the jobname / job number they are looking for.
Below is the execution JCL that shows the options. The code was trivial
and developed from a sample.
The nice thing about it is that is even catches all the output of running
STCs at
the time I run it. In other words, we don't have to worry about shutting
everything down (including VTAM) and running this to get the joblogs from
those active STCs.
//*
//* EXEC REXX CLIST IN BATCH
//*
//* PARM VALUE IS THE CLIST AND ARGUMENTS TO BE EXECUTED
//* SYSEXEC DD POINTS TO THE CLIST PDS
//*
//* 1ST ARG FOR SDSF@DR IS THE OUTPUT VOLSER (DEFAULT IS GOHOME)
//* 2ND ARG FOR SDSF@DR IS THE JOBNAME PREFIX (DEFAULT IS *)
//* 3RD ARG FOR SDSF@DR IS THE OUTPUT DSN HLQ (DEFAULT IS SYSDR)
//* 4TH ARG FOR SDSF@DR IS THE SMS STORCLAS (DEFAULT IS NONE USED)
//*
//* SAMPLE OUTPUT DATA SET NAME:
//* SYSDR.DR.SYSA.SYSLOG.STC00002.Y2010.D021
//*
//*
//S1 EXEC PGM=IRXJCL,PARM='SDSF@DR'
//*S1 EXEC PGM=IRXJCL,PARM='SDSF@DR GOHOME'
//*S1 EXEC PGM=IRXJCL,PARM='SDSF@DR GOHOME * MYHLQ'
//*S1 EXEC PGM=IRXJCL,PARM='SDSF@DR GOHOME MYJOBS*'
//*S1 EXEC PGM=IRXJCL,PARM='SDSF@DR GOHOME MYJOBS* MYHLQ'
//*S1 EXEC PGM=IRXJCL,PARM='SDSF@DR GOHOME MYJOBS* MYHLQ NONSMS'
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//SYSEXEC DD DSN=SYSDR.EXEC,DISP=SHR
Maybe I should add this to my web site / CBT file 434.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Lizette Koehler
That would be great. Either or both (website or CBT Tape) would be acceptable. I was looking into writing something like this for our DR process.
Lizette
----------------------------------------------------------------------
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Friday, March 26, 2010 3:46 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: An amusing REXX program - JES2DISK == copies JES
> output to disk using REXX's SDSF API
>
> Partly because the UNIX designers had a culture or mindset such that
> they when given a requirement, they thought, "How can we implement
> this so it benefits the greatest part of the user community?"
> rather than "What is the minimal implementation that meets the
> letter of the given requirement?" JES is a case in point.
> Prior to JES, Data Management facilities were unsuitable for
> the needs of spooling. So the designers devised a new filesystem
> for JES, but stopped there, short of making the benefits of the
> JES FS available to the user community generally.
>
> -- gil
And this last continues into the z/OS UNIX arena. Why isn't there a way to "mount" the SPOOL onto a subdirectory? Oh, yeah, that would: (1) cost more to develop and (2) impact the possibility to make an "SDSF for z/OS UNIX" product for sale.
Why didn't IBM do __something__ to make it easier to port GNU utilities to z/OS?
Why is the UNIX filesystem stored in EBCDIC instead of Unicode? "To be compatable with legacy"? Well, then have the data be stored in Unicode, with "automagic" code translation when read/written from "legacy" code. Or when the appropriate environment variable is set (_BPX_AUTOCVT doesn't cut it).
The reason, IMO, is that IBM originally designed z/OS UNIX (OpenEdition) strictly to be POSIX compliant so that they could bid on US government contracts. And, as you said, "What is the minimal implementation that meet the letter of the given requirement?" Little thought for the future.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Sam Siegel
> On Fri, 26 Mar 2010 14:51:12 -0500, Elliot, David wrote:
> >
> >By the way, surely UNIX must be approaching legacy status by now. Or is
> that expression reserved for the despised IBM mainframe?
> >
> UNIX ages more gracefully than OS.
>
> Partly because it's not burdened with the legacy of a CKD FS.
>
> Partly because UNIX eluded the severe storage constraints of
> early OS which prohibited valuable design abstraction, requiring
> programmers to deal too directly with hardware specifics. (Why
> isn't z/OS a 64-bit OS? Why isn't z/OS even a 31-bit OS?)
>
> Partly because IBM considered PL/S a strategic advantage and
> didn't make it available to the customer base (at a suitable
> price). This deprived customers of an abstraction layer,
> imprisoning them in a mid-20th Century architecture, in turn
> likewise imprisoning IBM's designers themselves.
>
> Partly because the UNIX designers had a culture or mindset such that
> they when given a requirement, they thought, "How can we implement
> this so it benefits the greatest part of the user community?"
> rather than "What is the minimal implementation that meets the
> letter of the given requirement?" JES is a case in point.
> Prior to JES, Data Management facilities were unsuitable for
> the needs of spooling. So the designers devised a new filesystem
> for JES, but stopped there, short of making the benefits of the
> JES FS available to the user community generally.
>
I beg to differ on this one. Unix ages more gracefully because for many
years the source code was available at universities at no cost. This
created legions of programmers and instructors. These people carried unix
forward into the commercial world.
Jes is an extremely poor point in fact. Take a look at the
native equivalent of jes on unix and you will find (I'm pretty sure) that it
does not even exist.
Job logging, job classes, sysout management, resource allocation. These are
quite foreign concepts to the unix world. You need to buy this stuff or
RYO.
Regards,
Sam
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Lizette Koehler
> Sent: Friday, March 26, 2010 3:56 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: An amusing REXX program - JES2DISK == copies JES
> output to disk using REXX's SDSF API
>
>
> That would be great. Either or both (website or CBT Tape)
> would be acceptable. I was looking into writing something
> like this for our DR process.
>
> Lizette
And it is exactly what I wrote mine for. To bring sysout back from DR. But I wrote it "quick and dirty" while at DR.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Elliot, David
Sorry.
David Elliot
zSeries Software Support
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Sam Siegel
Sent: Friday, March 26, 2010 4:01 PM
To: IBM-...@bama.ua.edu
Subject: Re: An amusing REXX program - JES2DISK == copies JES output to disk using REXX's SDSF API
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Sam Siegel
> Sent: Friday, March 26, 2010 4:01 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: An amusing REXX program - JES2DISK == copies JES
> output to disk using REXX's SDSF API
> I beg to differ on this one. Unix ages more gracefully
> because for many
> years the source code was available at universities at no cost. This
> created legions of programmers and instructors. These people
> carried unix
> forward into the commercial world.
Very true. And it's why Linux is advancing so well today.
>
> Jes is an extremely poor point in fact. Take a look at the
> native equivalent of jes on unix and you will find (I'm
> pretty sure) that it
> does not even exist.
Also true. UNIX was originally designed for interactive use. It is not very good at what we would think of as "batch" work. It would be as if the original OS/360 started off with TSO, not batch.
>
> Job logging, job classes, sysout management, resource
> allocation. These are
> quite foreign concepts to the unix world. You need to buy
> this stuff or
> RYO.
>
> Regards,
> Sam
>
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Sam Siegel
> wrote:
> > -----Original Message-----
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-...@bama.ua.edu] On Behalf Of Sam Siegel
> > Sent: Friday, March 26, 2010 4:01 PM
> > To: IBM-...@bama.ua.edu
> > Subject: Re: An amusing REXX program - JES2DISK == copies JES
> > output to disk using REXX's SDSF API
>
> > I beg to differ on this one. Unix ages more gracefully
> > because for many
> > years the source code was available at universities at no cost. This
> > created legions of programmers and instructors. These people
> > carried unix
> > forward into the commercial world.
>
> Very true. And it's why Linux is advancing so well today.
>
> >
> > Jes is an extremely poor point in fact. Take a look at the
> > native equivalent of jes on unix and you will find (I'm
> > pretty sure) that it
> > does not even exist.
>
> Also true. UNIX was originally designed for interactive use. It is not very
> good at what we would think of as "batch" work. It would be as if the
> original OS/360 started off with TSO, not batch.
>
Then there are things like checkpoint restart. On unix, that is "something
the database does". There is now OS level facility that lets you restart
where you left off.
There are also file system issues. It seems lately that there have been
many comments regards ckd disk, etc. Consider the flip side. Unix does not
have anything close to vsam. If you want keyed file access, you either use
a database, ryo or purchase a third party product. Vsam goes a long way to
solve many problems. Most unix developers are very surprised at
vsam's capabilities.
Tapes and tape management are woefully lacking on unix. There are still
many cases, outside of backup, were tape plays an important role. With a
unix system, using tape is difficult at best.
Take a look at JCL. Many unix developers don't see the true facility of
JCL. That is indirect specification of resources. JCL (svc 99, etc.)
allows a program to address different input and output as well as printers
and other external devices without the underlying program knowing which
specific resource is being used. On Unix you must pass very specific
information to fopen or open to obtain the resource. A "smart" program can
read this information from a configuration file or
via environment variables. However, there is no standardized way of doing
this. This makes every "production" job on a unix machine that much
more difficult to manage.
Regards,
Sam
Pommier, Rex R.
Rex
Sorry.
Regards,
Sam
----------------------------------------------------------------------
Kirk Wolf
I like z/OS as much as the next guy, but I have to disagree with most
of your comparisons.
On Fri, Mar 26, 2010 at 4:20 PM, Sam Siegel <s...@pscsi.net> wrote:
>
> Then there are things like checkpoint restart. �On unix, that is "something
> the database does". �There is now OS level facility that lets you restart
> where you left off.
>
So, you can checkpoint your position in a sequential dataset and
synchronize this with a DB2 commit for convenient restart processing
without buying a third party product? z/OS checkpoint/restart is
pretty archaic IMO. It is much easier to do this on *nux, since a
file pointer is just a number.
> There are also file system issues. �It seems lately that there have been
> many comments regards ckd disk, etc. �Consider the flip side. �Unix does not
> have anything close to vsam. �If you want keyed file access, you either use
> a database, ryo or purchase a third party product. �Vsam goes a long way to
> solve many problems. �Most unix developers are very surprised at
> vsam's capabilities.
>
There are several popular *free* databases, like MySQL. Not to
mention free b-tree implementations.
Maybe the problem is that *nix developers just don't understand how
cool VSAM is....
Just explain the details of VSAM SHAREOPTIONS to them, that will
convince them :-)
> �Tapes and tape management are woefully lacking on unix. �There are still
> many cases, outside of backup, were tape plays an important role. �With a
> unix system, using tape is difficult at best.
>
Seems to me like you have to buy a vendor product on any OS to do tape
management well.
Virtual tape subsystems are the future anyway, and that technology is
more or less platform neutral IMO.
> Take a look at JCL. �Many unix developers don't see the true facility of
> JCL. �That is indirect specification of resources. �JCL (svc 99, etc.)
> allows a program to address different input and output as well as printers
> and other external devices without the underlying program knowing which
> specific resource is being used. �On Unix you must pass very specific
> information to fopen or open to obtain the resource. �A "smart" program can
> read this information from a configuration file or
> via environment variables. � However, there is no standardized way of doing
> this. �This makes every "production" job on a unix machine that much
> more difficult to manage.
>
It is simply done differently on Unix... on Unix you use shell scripts
to parameterize file names as shell variables which are used as
arguments to programs.
If anything, shell scripts are *more* flexible than JCL. (But on
z/OS, you can do both, even in a batch job!)
You didn't really mention the things that I see as the biggest
advantages of z/OS of Unix:
- massive multiprocessing with great resource management (WLM)
- JES (but I guess you did cover this)
- stability, backwards compatibility, reliability...
FWIW, did IBM sell more net-new z engines last year for z/OS or for Linux?
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
> Regards,
> Sam
Sam Siegel
Kirk,
Points made ...
Sam
Shmuel Metz , Seymour J.
In <4e2421a41003261420t52b...@mail.gmail.com>, on
03/26/2010
at 09:20 PM, Sam Siegel <s...@PSCSI.NET> said:
>Then there are things like checkpoint restart. On unix, that is
>"something the database does". There is now (sic) OS level facility
>that lets you restart where you left off.
ITYM "There is no OS level facility". OS C/R has such severe restrictions
that I question its utility in the real world.
--
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)
Shmuel Metz , Seymour J.
at 03:46 PM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Prior to JES, Data Management facilities were unsuitable for the needs of
>spooling.
In what way?
--
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)
----------------------------------------------------------------------
Sam Siegel
shmuel+...@patriot.net <shmuel%2Bibm...@patriot.net>> wrote:
> I agree with much of what you write, but must challenge on item.
>
> In <4e2421a41003261420t52b...@mail.gmail.com>, on
> 03/26/2010
> at 09:20 PM, Sam Siegel <s...@PSCSI.NET> said:
>
> >Then there are things like checkpoint restart. On unix, that is
> >"something the database does". There is now (sic) OS level facility
> >that lets you restart where you left off.
>
> ITYM "There is no OS level facility". OS C/R has such severe restrictions
> that I question its utility in the real world.
>
C/R was not the best example.
Mark Zelden
sent off an updated CBT file to Sam.
Cheers,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
On Fri, 26 Mar 2010 16:55:36 -0400, Lizette Koehler
<star...@MINDSPRING.COM> wrote:
>Mark,
>
>That would be great. Either or both (website or CBT Tape) would be
acceptable. I was looking into writing something like this for our DR process.
>
>Lizette
>
>
>
>>
>>I have something similar I wrote for DR. Instead of dumping the
>>spool and restoring to a test spool back at the home shop, or writing all
>>the output via external writer to a single data set, we use the program
>>at DR. It creates a flat file for each job in the spool using "ST" as
>>the list of jobs to process. Then we "reverse" mirror the output disk
>>volume so we have all the data back at the shop. People can easily
>>find the jobname / job number they are looking for.
>>
>>Below is the execution JCL that shows the options. The code was trivial
>>and developed from a sample.
>>
>>The nice thing about it is that is even catches all the output of running
>>STCs at
>>the time I run it. In other words, we don't have to worry about shutting
>>everything down (including VTAM) and running this to get the joblogs from
>>those active STCs.
>>
----------------------------------------------------------------------
Rick Fochtman
Prior to JES, Data Management facilities were unsuitable for the needs
of spooling.
>
>In what way?
>
>
>
-----------------------------<unsnip>------------------------------------------
I can think of several possible scenarios:
1. Data compression. Just trimming the trailing blanks can be a
wonderful space-saver.
2. Data retention. By that, I mean the mechanisms to determine the
appropriate print train for impact printers,forms control buffers,
character sets for laser printers, etc. Not to mention forms
information, either names or basic images. And copy counts, as well as
COPYMOD information.
3. Writing all the data to a common file would be a major headache just
in managing the space in that file. Not to mention managing
discontinuous ranges of records scattered around that file in order to
keep a single SYSOUT group together and in the proper order.
The various management mechanisms involved in the JES Checkpoint and
Spool space can be coordinated very nicely when everything filters
through the same mechanism, but approaches anarchy when users can come
and go at will. With JES, everything goes through a common mechanism,
follows the same protocols and is handled in identical fashion.
Just my two cents worth.
Rick
Rick Fochtman
ITYM "There is no OS level facility". OS C/R has such severe
restrictions that I question its utility in the real world.
I'm inclined to agree with that assessment. In my experience, a step
restart via JCL features is far more useful.
Rick
Paul Gilmartin
>----------------------------------<snip>---------------------------------
>Prior to JES, Data Management facilities were unsuitable for the needs
>of spooling.
>
>>In what way?
>>
>-----------------------------<unsnip>------------------------------------------
I wasn't there, so I'm relying on rumors.
>I can think of several possible scenarios:
>
>1. Data compression. Just trimming the trailing blanks can be a
>wonderful space-saver.
>
Programmers converting between attached printers and spool
tended to leave RECFM=F (not FB). This resulted in adverse
space utilization before JES. JES blocks regardless.
When the spool was kept in PS data sets, the programmer
was required to manage SPACE allocation. Sometimes
(always) this was done by SYSOUT class, a quite inflexible
mechanism. JES simply grabs the space it needs as it
proceeds.
-- gil
Shmuel Metz , Seymour J.
at 05:00 PM, Rick Fochtman <rfoc...@YNC.NET> said:
>1. Data compression.
There I agree; lots of programs used FBA and FBM.
>2. Data retention.
It's in there. More precisely, it's in there for all of the printers
supported on the pre-JES systems.
>3. Writing all the data to a common file would be a major headache just
>in managing the space in that file.
OS spooling didn't do that.
>The various management mechanisms involved in the JES Checkpoint and
>Spool space can be coordinated very nicely when everything filters
>through the same mechanism, but approaches anarchy when users can come
>and go at will.
No. Users don't come and go by magic; every job has an entry in the job
queue.
>With JES, everything goes through a common mechanism,
Just as they did with OS spooling.
Perhaps you're thinking of applications directing their printed output to,
e.g., tape, but that's not OS spooling. OS spooling is defining data sets
as SYSIN (DD * and DATA) or SYSOUT (SYSOUT=) data sets, and those are
automatically managed by well defined system services.
Or perhaps you're thinking of PCP and MFT (not MFT II) rather than MFT II,
MVT and SVS.
--
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)
----------------------------------------------------------------------