Wrapper Application

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

Bill Woodger · Posted: Sun Sep 11, 2011 2:45 am

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.

enrico-sorichetti · Posted: Sun Sep 11, 2011 4:20 am

dick scherrer · Posted: Sun Sep 11, 2011 9:21 am

Hello,

Nic Clouston · Posted: Sun Sep 11, 2011 9:53 am

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.

parsesource · New User Joined: 06 Feb 2006 Posts: 97

parsesource · New User Joined: 06 Feb 2006 Posts: 97

PeterHolland · Posted: Sun Sep 11, 2011 5:19 pm

I think DFSRRC00 is a nice example of a "wrapper".

Bill Woodger · Posted: Sun Sep 11, 2011 5:52 pm

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?

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.

enrico-sorichetti · Posted: Mon Sep 12, 2011 4:03 am

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