View previous topic :: View next topic
|
Author |
Message |
parsesource
New User
Joined: 06 Feb 2006 Posts: 97
|
|
|
|
Is there a way to achieve the following
Instead of executing a program the usual way with JCL
a) EXEC PGM=XYZ,PARM=parmstring
execute it in a 100% transparent way using a wrapper
b) EXEC PGM=WRAPPER,PARM=parmstring
WRAPPER gives control to XYZ in some way.
100% transparent means the STEP return code or Abend code of a) and b) should be equal (except WRAPPER fails)
XYZ may be anything (IDCAMS, IEBCOPY, otherpgm, APF or no APF ...)
I think if WRAPPER is written in a HLL like PLI at least some parts must be asm to XCTL to XYZ.
What i try to achieve: WRAPPER should e.g. create/ change a control card etc. before calling XYZ
Usually it´s possible to do this in a two step process using rexx, but i prefer a single step solution.
Are such apps available somewhere (cbttape? - difficult to search there...)
thanks |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
How is your "wrapper" to know what program to invoke?
Write a little program in whatever lanaguage you feel happy with.
Takes the parm (in whatever way for that language). Messes about with it.
"Calls" the program you want to invoke passing on the new parm. Then return (in whatever way) to the operating system when you regain control.
I've done it with application programs. I'm not aware that it would not work with any program you wish to invoke. I don't think the operating system does anything different with PGM=utility-of-some-type and PGM=application-program.
I'd suggest you go ahead and try it, and let us know the results. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
difficult to search there... |
why ?
cbtf1 has a very good description of the tape content ! |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
I think if WRAPPER is written in a HLL like PLI at least some parts must be asm to XCTL to XYZ. |
There is no reason to use pl/i or asm. Unless i misunderstand what you want, you can do what you want with COBOL. . .
Your experience with CALL must be rather limited. . . |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
We used to run 90% of our programs under one of 2 'wrappers'. These 'wrappers' maintained control records to allow automatic restart via a retrun code from a prolog step, automatic deletion of datasets and maintenance of control totals. Also allowed a bit of dependency checking. They may have been written in PL/1 as that was the language of choice at the company. |
|
Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006 Posts: 97
|
|
|
|
Bill Woodger wrote: |
How is your "wrapper" to know what program to invoke?
I'd suggest you go ahead and try it, and let us know the results. |
Either the program to invoke is hardcoded somewhere or are the first eight char of PARM or sg. equivalent.
i´ve already written such an app, but with rexx within tso-batch environment. it works, but it´s not transparent and entries in IKJTSOxx are neccessary etc.
basically the wrapper app should circumvent the 100 char parm limit in jcl and allow use system symbols in instream-data. one of my approach is to use (misuse) the PATH Statement for this. i have made no tests so far. |
|
Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006 Posts: 97
|
|
|
|
dick scherrer wrote: |
Hello,
Quote: |
I think if WRAPPER is written in a HLL like PLI at least some parts must be asm to XCTL to XYZ. |
There is no reason to use pl/i or asm. Unless i misunderstand what you want, you can do what you want with COBOL. . .
Your experience with CALL must be rather limited. . . |
experience in cobol is rather limited. only little cobol here in europe :-) |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
I think DFSRRC00 is a nice example of a "wrapper". |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Define "it works" please.
If any utility accepts more than 100 characters of parm:
- I'd be surprised
- Don't count on it working with any sort of update to the utility
If your wrapper allows more than 100 character of a parm to be passed to an application program that uses the data, then the program can not be run without the wrapper. I'd hardly call that "transparent" - with the wrapper it works, without the wrapper it doesn't.
You want to parameterise instream data inside the step that is using the instream data? How do you think you are going to go about that?
What is the purpose of all this? |
|
Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006 Posts: 97
|
|
|
|
My description was not precise enough.
example
A rexx skript or Tso Command can be executed in batch either with PARM=.. or in DD SYSTSIN.
PARM is limited to 100char, jcl-symbol-use is possible.
In SYSTSIN there is no length-limit. But JCL Symbols cannot be used there.
Eg. using the xmitip mail package parm-length in systsin can be much longer than 100char.
So there is no single step Solution to provide more than about 90 char to a rexx app from jcl symbols.
The rexx app I have some sort of file-tailoring before calling the pgm. it does not extend the char limit yet.
in a non-tso batch environment the problems are similar.
So the wrapper should allow to transfer >100chars from jcl-symbols to the application. Usually within a control-card. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
if the issue is so stringent evaluate the installation and use of the CCSS
Control card subsystem CBT file 364 ( at al. )
easy to install, very easy to use , provides parametrization of the program input |
|
Back to top |
|
|
|