Michael,

The number you are looking for is 123 not 128. Search the VSE/VSAM
Commands manual for 123 and you will find the details.

Many many years ago in a shop with very fragmented VSAM space I had a
test file that used 120+ extents.

have a good weekend,
Glen Gunselman

>>> mrosinger@cciws.com 1/21/2005 5:19:02 AM >>>
List,

Someone is telling me that it is possible to have up to 128 extents
for
a VSAM dataset on a single volume. Everything that I've always read
and
heard is that the maximum is 16 extents per volume. Is this true? If
it
is, is it true for VSAM-managed SAM datasets as well or just true
VSAM?

If there is any basis for this claim, could you point me to the proper
place in one of the VSAM books? TIA

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : 336-761-8852
email : mrosinger at cciws dot com

From:	Michael Rosinger
Subject:	Re: calling all VSAM experts...
Date:	Fri, 21 Jan 2005 10:05:05 -0500

Glen,

Yes, that must be what they are referring to. Can you tell me if this
applies to VSAM-managed SAM?

We use a whole lot of *implicitly* defined VSAM/SAM for transient data
files. We never get more than 16 extents per volume in the catalog. From
what I can tell in the books, to take advantage of the 123 extents the
dataset has to be defined REUSE and it seems to hint that it must be
defined *explicitly*. If that's the case, that would explain why we never
see more than 16 extents per volume. What do you think?

Glen Gunselman wrote:

> Michael,
>
> The number you are looking for is 123 not 128. Search the VSE/VSAM
> Commands manual for 123 and you will find the details.
>

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : 336-761-8852
email : mrosinger at cciws dot com

From:	RJacobson at decare.com
Subject:	Re: calling all VSAM experts...
Date:	21 Jan 2005 07:29:56 -0800

For a VSAM file to have more than 16 extents per volume it must be defined
NOREUSE. When managed-SAM files are defined implicitly, they are defined
REUSE, so they are subject to the 16 extent per volume limit. Therefore,
your only chance to have a managed-SAM file with more than 16 extents per
volume is to define it explicitly.

Bob Jacobson
(651) 994-5329
rjacobson@decare.com

Michael Rosinger
com> To
Sent by: "VSE Discussion List"
owner-vse-l@Lehig
h.EDU cc

Subject
01/21/2005 09:05 Re: calling all VSAM experts...
AM

Please respond to
vse-l@Lehigh.EDU

Glen,

Yes, that must be what they are referring to. Can you tell me if this
applies to VSAM-managed SAM?

We use a whole lot of *implicitly* defined VSAM/SAM for transient data
files. We never get more than 16 extents per volume in the catalog. From
what I can tell in the books, to take advantage of the 123 extents the
dataset has to be defined REUSE and it seems to hint that it must be
defined *explicitly*. If that's the case, that would explain why we never
see more than 16 extents per volume. What do you think?

Glen Gunselman wrote:

> Michael,
>
> The number you are looking for is 123 not 128. Search the VSE/VSAM
> Commands manual for 123 and you will find the details.
>

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : 336-761-8852
email : mrosinger at cciws dot com

From:	Kevin Corkery
Subject:	RE: calling all VSAM experts...
Date:	21 Jan 2005 07:40:13 -0800

A side benefit of explicit definition is that the CISZ can be made larger
than it would normally default. During an implicit define the CISZ is set
to hold 2 physical buffers. VSAM will only double buffer a managed sam
file. If you explicitely define the file you can set the CISZ to hold more
than 2 physical buffers per CI. This can lead to bettere device utilization
and overall faster processing by minimizing I/O. And yes, NOREUSE doe not
have the 16 extent/volume limitation.

Kevin P Corkery
Independent Consultant
Voorhees, New Jersey

-----Original Message-----
From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] On Behalf Of
RJacobson@decare.com
Sent: Friday, January 21, 2005 10:28 AM
To: VSE Discussion List
Subject: Re: calling all VSAM experts...

For a VSAM file to have more than 16 extents per volume it must be defined
NOREUSE. When managed-SAM files are defined implicitly, they are defined
REUSE, so they are subject to the 16 extent per volume limit. Therefore,
your only chance to have a managed-SAM file with more than 16 extents per
volume is to define it explicitly.

Bob Jacobson
(651) 994-5329
rjacobson@decare.com

Michael Rosinger
com> To
Sent by: "VSE Discussion List"
owner-vse-l@Lehig
h.EDU cc

Subject
01/21/2005 09:05 Re: calling all VSAM experts...
AM

Please respond to
vse-l@Lehigh.EDU

Glen,

Yes, that must be what they are referring to. Can you tell me if this
applies to VSAM-managed SAM?

We use a whole lot of *implicitly* defined VSAM/SAM for transient data
files. We never get more than 16 extents per volume in the catalog. From
what I can tell in the books, to take advantage of the 123 extents the
dataset has to be defined REUSE and it seems to hint that it must be defined
*explicitly*. If that's the case, that would explain why we never see more
than 16 extents per volume. What do you think?

Glen Gunselman wrote:

> Michael,
>
> The number you are looking for is 123 not 128. Search the VSE/VSAM
> Commands manual for 123 and you will find the details.
>

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : 336-761-8852
email : mrosinger at cciws dot com

From:	The Family
Subject:	Re: calling all VSAM experts...
Date:	Fri, 21 Jan 2005 16:55:50 GMT

oops!

"From what I can tell in the books, to take advantage of the 123 extents the
dataset has to be defined (NO)REUSE".

Which, pretty much dictates explicit definition.

Thanks,

Gary Walker

"Michael Rosinger" wrote in message
news:41F11A21.ACDD71AF@cciws.com...
> Glen,
>
> Yes, that must be what they are referring to. Can you tell me if this
> applies to VSAM-managed SAM?
>
> We use a whole lot of *implicitly* defined VSAM/SAM for transient data
> files. We never get more than 16 extents per volume in the catalog. From
> what I can tell in the books, to take advantage of the 123 extents the
> dataset has to be defined REUSE and it seems to hint that it must be
> defined *explicitly*. If that's the case, that would explain why we never
> see more than 16 extents per volume. What do you think?
>
> Glen Gunselman wrote:
>
> > Michael,
> >
> > The number you are looking for is 123 not 128. Search the VSE/VSAM
> > Commands manual for 123 and you will find the details.
> >
>
> --
> Michael Rosinger
> Systems Programmer/DBA
> Computer Credit, Inc.
> 640 W. 4th Street
> Winston-Salem, NC 27101
> voice : 336-761-1524
> fax : 336-761-8852
> email : mrosinger at cciws dot com
>
>

From:	Eugene S. Hudders
Subject:	RE: calling all VSAM experts...
Date:	21 Jan 2005 10:36:16 -0800

Hi Michael:

I am not sure that you have this correct. VSAM allows up to 123 extents per
component, that is, either the data or the index can have up to 123 extents.
Files with the REUSE attribute are limited to 16 extents as well as files
that have the UNIQUE designation. In one of the replies this AM I believe I
saw that the manual says that you are limited to 16 extents for a SAM
managed file.

Regards,
Gene

From:	industrynews at dapsco.com
Subject:	* $$ PUN DISP=I processing
Date:	21 Jan 2005 07:32:56 -0800

Am I correct that punching multiple * $$ JOB and * $$ EOJ cards
through the DISP=I process has no effect in terms creating separate POWER
jobs in the RDR queue? If so, is the only way to achieve separate entries
is to use the SEGMENT macro? ...or, is there another way?

Sincerely,

Dave Clark

DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331

From:	The Family
Subject:	*Re: $$ PUN DISP=I processing**
Date:	Fri, 21 Jan 2005 16:55:50 GMT

wrote in message
news:OF7022DC68.8BC04F44-ON85256F90.0054A3CF-85256F90.00556213@winwholesale.com...
> Am I correct that punching multiple * $$ JOB and * $$ EOJ cards
> through the DISP=I process has no effect in terms creating separate POWER
> jobs in the RDR queue? If so, is the only way to achieve separate entries
> is to use the SEGMENT macro? ...or, is there another way?
>
> Sincerely,
>
> Dave Clark
>
> DAPSCO Information Systems
> 3110 Kettering Boulevard
> Dayton, Ohio 45439
> (937) 294-5331
>

Yes, you are correct, *$$job & *$$eoj have no effect when used
in disp=i processing. Yes, the other way is subsequent *$$pun ...
disp=i statements.

But, by your segment reference. it sounds like your disp=i process-
ing is programmatic. If true, and since you are operating inside a
program, I can think of no other way to slice up the pun output/
rdr input, other than segment.

However, if it's Cobol(really any language) one used to be able to
apply an alternative segmentation technique(I think is was called
event segmentation?) by placing one/more *$$pun ...disp=i state-
ments behind the program's execute statement, and just "accepting"
(Cobol) them one at a time. Of course, the following caveats apply:

.. Your application program probably should forego any control
statement input using accept for jecl & data.
.. Traditionally, you wouldn't know(variable) the # of jecl *$$pun
statements to supply until during program execution. However,
since your not dealing with reports/jcl log, this might not be a
problem for you.

I haven't done this in a very long time, but I'd give it a try. It might
circumvent an assembly routine for segment.

* $$ job jnm=...
* $$ lst disp=....
// job ....
// log ....
// exec pgm=program
* $$ pun disp=i,class=....
* $$ pun disp=i,class=...

Any pun statements remaining at program conclusion probably will
just run on through, without creating a dummy/zero record spool
entry. However, with lst entries, you will often get the dummy entry.

Using the jnm= option, you could even name the entries, but that will
require much more synchronization between program execution and
*$$pun statements.
.....
/*
/&
* $$ eoj

From:	Tony Thigpen
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 18:46:08 -0800

You need a dummy card between each of the * $$ PUN statements.
* $$ job jnm=...
* $$ lst disp=....
// job ....
// log ....
// exec pgm=program
* $$ pun disp=i,class=....
junk
* $$ pun disp=i,class=...
junk

Tony Thigpen

-----Original Message -----
From: The Family
Sent: 01/21/2005 11:55 AM
> wrote in message
> news:OF7022DC68.8BC04F44-ON85256F90.0054A3CF-85256F90.00556213@winwholesale.com...
>
>> Am I correct that punching multiple * $$ JOB and * $$ EOJ cards
>>through the DISP=I process has no effect in terms creating separate POWER
>>jobs in the RDR queue? If so, is the only way to achieve separate entries
>>is to use the SEGMENT macro? ...or, is there another way?
>>
>>Sincerely,
>>
>>Dave Clark
>>
>>DAPSCO Information Systems
>>3110 Kettering Boulevard
>>Dayton, Ohio 45439
>>(937) 294-5331
>>
>
>
> Yes, you are correct, *$$job & *$$eoj have no effect when used
> in disp=i processing. Yes, the other way is subsequent *$$pun ...
> disp=i statements.
>
> But, by your segment reference. it sounds like your disp=i process-
> ing is programmatic. If true, and since you are operating inside a
> program, I can think of no other way to slice up the pun output/
> rdr input, other than segment.
>
> However, if it's Cobol(really any language) one used to be able to
> apply an alternative segmentation technique(I think is was called
> event segmentation?) by placing one/more *$$pun ...disp=i state-
> ments behind the program's execute statement, and just "accepting"
> (Cobol) them one at a time. Of course, the following caveats apply:
>
> . Your application program probably should forego any control
> statement input using accept for jecl & data.
> . Traditionally, you wouldn't know(variable) the # of jecl *$$pun
> statements to supply until during program execution. However,
> since your not dealing with reports/jcl log, this might not be a
> problem for you.
>
> I haven't done this in a very long time, but I'd give it a try. It might
> circumvent an assembly routine for segment.
>
> * $$ job jnm=...
> * $$ lst disp=....
> // job ....
> // log ....
> // exec pgm=program
> * $$ pun disp=i,class=....
> * $$ pun disp=i,class=...
>
> Any pun statements remaining at program conclusion probably will
> just run on through, without creating a dummy/zero record spool
> entry. However, with lst entries, you will often get the dummy entry.
>
> Using the jnm= option, you could even name the entries, but that will
> require much more synchronization between program execution and
> *$$pun statements.
> ....
> /*
> /&
> * $$ eoj
>
>
>

From:	industrynews at dapsco.com
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 10:23:55 -0800

owner-vse-l@Lehigh.EDU wrote on 01/21/2005 11:55:50 AM:
> Yes, you are correct, *$$job & *$$eoj have no effect when used
> in disp=i processing. Yes, the other way is subsequent *$$pun ...
> disp=i statements.

All output is from a single execution of a single program (RPG).

> However, if it's Cobol(really any language) one used to be able to
> apply an alternative segmentation technique(I think is was called
> event segmentation?) by placing one/more *$$pun ...disp=i state-
> ments behind the program's execute statement, and just "accepting"
> (Cobol) them one at a time.

I'm sorry, but I do not understand the value/benefit of reading the *
$$ PUN card from SYSIPT. Perhaps you could explain this further. However,
so that we are clear, I currently have the following job which would like
to "submit" one or more (variable number up to 100) additional jobs that
all run as separate POWER jobs.

* $$ JOB ...
* $$ LST ...
* $$ PUN DISP=I,...
// JOB DILFXTNS ...
// UPSI 00001000
// DATE 12/31/05
// EXEC PGM=LFEXTRCT,SIZE=AUTO
#LCL088DI
203204205206
/* EOD
/& EOJ
* $$ EOJ

The reason for the separate jobs is because I need to dynamically
capture the SYSLST output from each job for the purpose of using FTP to
send that report from the LST queue to a particular AS/400 output queue for
printing by an AS/400 user. The submitted job will have the following
content:

* $$ JOB ...
* $$ LST CLASS=Y,DISP=L,DEST=(,D203P1)
* $$ PUN DISP=I,...
// JOB DILFXTNS
// DATE 12/31/05
// UPSI 00001000
// EXEC PGM=LFEXTION,SIZE=AUTO
203
/* EOD
// SETPARM CO='203'
* $$ SLI LFXTNLCL
/& EOJ
* $$ EOJ

Thus, the SLI in the job above (with the following content) will capture
the POWER job name and number and pass these as parameters into a dynamic
FTP process.

/. FTP &CO TO WINSRV1
* $. LST DISP=D,CLASS=Z
// LIBDEF *,SEARCH=(PRD2.CONFIG,ESP.BSI),TEMP
// SETPARM JOBNM=' '
// SETPARM JOBNO=' '
// EXEC REXX=JOBINFO,JOBNM,JOBNO
// EXEC REXX=BSIREXXC,PARM='BSIFTP',JOBNM,JOBNO,CO
ID 00
OPEN WINSRV1.WINWHOLESALE.COM
USER xxxxxxxx
PASS xxxxxxxx
SYST
TYPE A
SITE NAMEFMT 1
SEND RCMD CALL PGM(PGM460/ACFTPPRTCL) PARM('EXTENSION' '')
CWD QSYS.LIB/DTA.LIB
*
* input from power queue
INPUT POWER LST *
STOR EXTENSION.FILE/EXTENSION.MBR
QUIT
/* EOD

So, to finish this long story, if there is another way to dynamically
determine the job name and number of more than one LST queue entry that are
all created out of a single job execution -- then I'm all ears. ;-)

Sincerely,

Dave Clark

DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331

From:	Gustavo Torres
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 10:49:23 -0800

Dave,

The next sample illustrates the reading of the
* $$ PUN card from SYSIPT:

* $$ JOB JNM=DTSUTIL,CLASS=P
// JOB DTSUTIL
// EXEC PROC=DTRICCF
// EXEC DTSUTIL
* $$ PUN CLASS=Q,JNM=MEMBER1
PUNCH MEMBER (66 MEMBER1 )
* $$ PUN CLASS=Q,JNM=MEMBER2
PUNCH MEMBER (66 MEMBER2 )
* $$ PUN CLASS=Q,JNM=MEMBER3
PUNCH MEMBER (66 MEMBER3 )
/*
/&
* $$ EOJ

On Fri, 21 Jan 2005 13:23:25 -0500, industrynews@dapsco.com
wrote:
> owner-vse-l@Lehigh.EDU wrote on 01/21/2005 11:55:50 AM:
> > Yes, you are correct, *$$job & *$$eoj have no effect when used
> > in disp=i processing. Yes, the other way is subsequent *$$pun ...
> > disp=i statements.
>
> All output is from a single execution of a single program (RPG).
>
> > However, if it's Cobol(really any language) one used to be able to
> > apply an alternative segmentation technique(I think is was called
> > event segmentation?) by placing one/more *$$pun ...disp=i state-
> > ments behind the program's execute statement, and just "accepting"
> > (Cobol) them one at a time.
>
> I'm sorry, but I do not understand the value/benefit of reading the *
> $$ PUN card from SYSIPT. Perhaps you could explain this further. However,
> so that we are clear, I currently have the following job which would like
> to "submit" one or more (variable number up to 100) additional jobs that
> all run as separate POWER jobs.
>
> * $$ JOB ...
> * $$ LST ...
> * $$ PUN DISP=I,...
> // JOB DILFXTNS ...
> // UPSI 00001000
> // DATE 12/31/05
> // EXEC PGM=LFEXTRCT,SIZE=AUTO
> #LCL088DI
> 203204205206
> /* EOD
> /& EOJ
> * $$ EOJ
>
> The reason for the separate jobs is because I need to dynamically
> capture the SYSLST output from each job for the purpose of using FTP to
> send that report from the LST queue to a particular AS/400 output queue for
> printing by an AS/400 user. The submitted job will have the following
> content:
>
> * $$ JOB ...
> * $$ LST CLASS=Y,DISP=L,DEST=(,D203P1)
> * $$ PUN DISP=I,...
> // JOB DILFXTNS
> // DATE 12/31/05
> // UPSI 00001000
> // EXEC PGM=LFEXTION,SIZE=AUTO
> 203
> /* EOD
> // SETPARM CO='203'
> * $$ SLI LFXTNLCL
> /& EOJ
> * $$ EOJ
>
> Thus, the SLI in the job above (with the following content) will capture
> the POWER job name and number and pass these as parameters into a dynamic
> FTP process.
>
> /. FTP &CO TO WINSRV1
> * $. LST DISP=D,CLASS=Z
> // LIBDEF *,SEARCH=(PRD2.CONFIG,ESP.BSI),TEMP
> // SETPARM JOBNM=' '
> // SETPARM JOBNO=' '
> // EXEC REXX=JOBINFO,JOBNM,JOBNO
> // EXEC REXX=BSIREXXC,PARM='BSIFTP',JOBNM,JOBNO,CO
> ID 00
> OPEN WINSRV1.WINWHOLESALE.COM
> USER xxxxxxxx
> PASS xxxxxxxx
> SYST
> TYPE A
> SITE NAMEFMT 1
> SEND RCMD CALL PGM(PGM460/ACFTPPRTCL) PARM('EXTENSION' '')
> CWD QSYS.LIB/DTA.LIB
> *
> * input from power queue
> INPUT POWER LST *
> STOR EXTENSION.FILE/EXTENSION.MBR
> QUIT
> /* EOD
>
> So, to finish this long story, if there is another way to dynamically
> determine the job name and number of more than one LST queue entry that are
> all created out of a single job execution -- then I'm all ears. ;-)
>
> Sincerely,
>
> Dave Clark
>
> DAPSCO Information Systems
> 3110 Kettering Boulevard
> Dayton, Ohio 45439
> (937) 294-5331
>
>

From:	industrynews at dapsco.com
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 11:08:45 -0800

owner-vse-l@Lehigh.EDU wrote on 01/21/2005 01:48:39 PM:
> The next sample illustrates the reading of the
> * $$ PUN card from SYSIPT:

> * $$ JOB JNM=DTSUTIL,CLASS=P
> // JOB DTSUTIL
> // EXEC PROC=DTRICCF
> // EXEC DTSUTIL
> * $$ PUN CLASS=Q,JNM=MEMBER1
> PUNCH MEMBER (66 MEMBER1 )
> * $$ PUN CLASS=Q,JNM=MEMBER2
> PUNCH MEMBER (66 MEMBER2 )
> * $$ PUN CLASS=Q,JNM=MEMBER3
> PUNCH MEMBER (66 MEMBER3 )
> /*
> /&
> * $$ EOJ

Yes, but is that because DTSUTIL specifically supports programmatic
segmentation every time DTSUTIL reads in a PUN card? ...or, is that
because POWER inherently interprets the reading of the PUN card as a signal
to segment the current punch stream?

Sincerely,

Dave Clark

DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331

From:	Gustavo Torres
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 11:15:28 -0800

No, DTSUTIL don't know about PUN cards into SYSIPT,
the second (about POWER) is true. You can try this with your RPG pgm.

Gustavo

On Fri, 21 Jan 2005 14:08:38 -0500, industrynews@dapsco.com
wrote:
> owner-vse-l@Lehigh.EDU wrote on 01/21/2005 01:48:39 PM:
> > The next sample illustrates the reading of the
> > * $$ PUN card from SYSIPT:
>
> > * $$ JOB JNM=DTSUTIL,CLASS=P
> > // JOB DTSUTIL
> > // EXEC PROC=DTRICCF
> > // EXEC DTSUTIL
> > * $$ PUN CLASS=Q,JNM=MEMBER1
> > PUNCH MEMBER (66 MEMBER1 )
> > * $$ PUN CLASS=Q,JNM=MEMBER2
> > PUNCH MEMBER (66 MEMBER2 )
> > * $$ PUN CLASS=Q,JNM=MEMBER3
> > PUNCH MEMBER (66 MEMBER3 )
> > /*
> > /&
> > * $$ EOJ
>
> Yes, but is that because DTSUTIL specifically supports programmatic
> segmentation every time DTSUTIL reads in a PUN card? ...or, is that
> because POWER inherently interprets the reading of the PUN card as a signal
> to segment the current punch stream?
>
> Sincerely,
>
> Dave Clark
>
> DAPSCO Information Systems
> 3110 Kettering Boulevard
> Dayton, Ohio 45439
> (937) 294-5331
>
>

From:	industrynews at dapsco.com
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 11:32:14 -0800

owner-vse-l@Lehigh.EDU wrote on 01/21/2005 02:14:45 PM:
> No, DTSUTIL don't know about PUN cards into SYSIPT,
> the second (about POWER) is true.
> You can try this with your RPG pgm.

So, you're saying that I can have a program punch 100 internally
generated cards and every 10 cards read from SYSIPT, as shown in the
following, and I will get 10 separate decks in the PUN queue? If my
program isn't actually reading these cards (as you say with DTSUTIL) and
POWER is, what kind of a result am I going to get on my READ effort within
the program? Very strange. Is the only reason it works with DTSUTIL is
because there are other SYSIPT cards in the stream?

* $$ PUN JNM=DECK0
// EXEC MYPGM,SIZE=AUTO
* $$ PUN JNM=DECK1
* $$ PUN JNM=DECK2
* $$ PUN JNM=DECK3
* $$ PUN JNM=DECK4
* $$ PUN JNM=DECK5
* $$ PUN JNM=DECK6
* $$ PUN JNM=DECK7
* $$ PUN JNM=DECK8
* $$ PUN JNM=DECK9
/* EOD

Sincerely,

Dave Clark

DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331

From:	Gustavo Torres
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 11:44:25 -0800

> Is the only reason it works with DTSUTIL is
> because there are other SYSIPT cards in the stream?

Yes, you need to insert sysipt data in order to work:

* $$ PUN JNM=DECK0
// EXEC MYPGM,SIZE=AUTO
data0
* $$ PUN JNM=DECK1
data1
* $$ PUN JNM=DECK2
data2
* $$ PUN JNM=DECK3
data3
...
...
...
/* EOD

On Fri, 21 Jan 2005 14:31:51 -0500, industrynews@dapsco.com
wrote:
> owner-vse-l@Lehigh.EDU wrote on 01/21/2005 02:14:45 PM:
> > No, DTSUTIL don't know about PUN cards into SYSIPT,
> > the second (about POWER) is true.
> > You can try this with your RPG pgm.
>
> So, you're saying that I can have a program punch 100 internally
> generated cards and every 10 cards read from SYSIPT, as shown in the
> following, and I will get 10 separate decks in the PUN queue? If my
> program isn't actually reading these cards (as you say with DTSUTIL) and
> POWER is, what kind of a result am I going to get on my READ effort within
> the program? Very strange. Is the only reason it works with DTSUTIL is
> because there are other SYSIPT cards in the stream?
>
> * $$ PUN JNM=DECK0
> // EXEC MYPGM,SIZE=AUTO
> * $$ PUN JNM=DECK1
> * $$ PUN JNM=DECK2
> * $$ PUN JNM=DECK3
> * $$ PUN JNM=DECK4
> * $$ PUN JNM=DECK5
> * $$ PUN JNM=DECK6
> * $$ PUN JNM=DECK7
> * $$ PUN JNM=DECK8
> * $$ PUN JNM=DECK9
> /* EOD
>
> Sincerely,
>
> Dave Clark
>
> DAPSCO Information Systems
> 3110 Kettering Boulevard
> Dayton, Ohio 45439
> (937) 294-5331
>
>

From:	RJacobson at decare.com
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 11:54:34 -0800

DTSUTIL's interaction with the POWER PUN statements is as follows.

1. DTSUTIL starts and immediately requests a card from SYSIPT.

2. When POWER goes to satisfy DTSUTIL's request, it encounters the PUN
statement in the JCL, which is recognizes as its own and processes it. In
this case, that means that it starts a new punch file with whatever
attributes are called out on the PUN statement.

3. Once POWER has processed the PUN statement, it reads the next card in
the JCL and sends it to DTSUTIL. If that is a request to punch a member
from ICCF, then DTSUTIL punches it.

4. POWER loads the punched output into the open punch spool file whose
attributes were given in the PUN statement.

5. DTSUTIL requests another card to see what it is to do next.

6. POWER encounters another PUN statement. Since it for the same device as
the first PUN statement, POWER closes the current punch file and opens a
new one using the attributes from the latest PUN statement.

7. POWER reads the next card in the JCL and sends it to DTSUTIL.

This cycle continues until DTSUTIL terminates. For your program to punch
multiple jobs using this technique, it will need to read a card either
before or after each job is punched and the JCL will need to include a data
card for your program in between each of the PUN statements to force POWER
to segment the punch stream coming out of your program into separate spool
files.

Bob Jacobson
(651) 994-5329
rjacobson@decare.com

industrynews@daps
co.com
Sent by: To
owner-vse-l@Lehig "VSE Discussion List"
h.EDU
cc

01/21/2005 01:31 Subject
PM Re: * $$ PUN DISP=I processing

Please respond to
vse-l@Lehigh.EDU

owner-vse-l@Lehigh.EDU wrote on 01/21/2005 02:14:45 PM:
> No, DTSUTIL don't know about PUN cards into SYSIPT,
> the second (about POWER) is true.
> You can try this with your RPG pgm.

So, you're saying that I can have a program punch 100 internally
generated cards and every 10 cards read from SYSIPT, as shown in the
following, and I will get 10 separate decks in the PUN queue? If my
program isn't actually reading these cards (as you say with DTSUTIL) and
POWER is, what kind of a result am I going to get on my READ effort within
the program? Very strange. Is the only reason it works with DTSUTIL is
because there are other SYSIPT cards in the stream?

* $$ PUN JNM=DECK0
// EXEC MYPGM,SIZE=AUTO
* $$ PUN JNM=DECK1
* $$ PUN JNM=DECK2
* $$ PUN JNM=DECK3
* $$ PUN JNM=DECK4
* $$ PUN JNM=DECK5
* $$ PUN JNM=DECK6
* $$ PUN JNM=DECK7
* $$ PUN JNM=DECK8
* $$ PUN JNM=DECK9
/* EOD

Sincerely,

Dave Clark

DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331

From:	industrynews at dapsco.com
Subject:	*Re: $$ PUN DISP=I processing**
Date:	21 Jan 2005 12:27:13 -0800

OK, thanks much. I've learned my new thing for the day. Time to go
home. ;-)

Sincerely,

Dave Clark

DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331

From:	The Family
Subject:	*Re: $$ PUN DISP=I processing**
Date:	Fri, 21 Jan 2005 23:14:14 GMT

You asked for additional explanation(s), but it appears that many
such explanations have been submitted by others. In summary,
Power does pull off the *$$pun statement in response to the
ipt read. However, I did forget to mention the interspersed
statement, such as:

// exec pgm=
* $$ pun
"empty statement"
* $$ pun
"empty statement"
/*

However, my oversight was corrected by another respondent.

Unfortunately, although I was once conversant in RPG, I'm either
not any longer, or choose not to be. However, I'm sure the opera-
tion is identical, whether RPG, Cobol, Assembly, or ??.

Based on your final update, I'll assume the only questions remaining
may be answered by related testing. Please notify, if this is incorrect.

Thanks,

Gary Walker

wrote in message
news:OFC5C81071.76A61302-ON85256F90.0062CA74-85256F90.00650587@winwholesale.com...
> owner-vse-l@Lehigh.EDU wrote on 01/21/2005 11:55:50 AM:
> > Yes, you are correct, *$$job & *$$eoj have no effect when used
> > in disp=i processing. Yes, the other way is subsequent *$$pun ...
> > disp=i statements.
>
> All output is from a single execution of a single program (RPG).
>
> > However, if it's Cobol(really any language) one used to be able to
> > apply an alternative segmentation technique(I think is was called
> > event segmentation?) by placing one/more *$$pun ...disp=i state-
> > ments behind the program's execute statement, and just "accepting"
> > (Cobol) them one at a time.
>
> I'm sorry, but I do not understand the value/benefit of reading the *
> $$ PUN card from SYSIPT. Perhaps you could explain this further.
However,
> so that we are clear, I currently have the following job which would like
> to "submit" one or more (variable number up to 100) additional jobs that
> all run as separate POWER jobs.
>
> * $$ JOB ...
> * $$ LST ...
> * $$ PUN DISP=I,...
> // JOB DILFXTNS ...
> // UPSI 00001000
> // DATE 12/31/05
> // EXEC PGM=LFEXTRCT,SIZE=AUTO
> #LCL088DI
> 203204205206
> /* EOD
> /& EOJ
> * $$ EOJ
>
> The reason for the separate jobs is because I need to dynamically
> capture the SYSLST output from each job for the purpose of using FTP to
> send that report from the LST queue to a particular AS/400 output queue
for
> printing by an AS/400 user. The submitted job will have the following
> content:
>
> * $$ JOB ...
> * $$ LST CLASS=Y,DISP=L,DEST=(,D203P1)
> * $$ PUN DISP=I,...
> // JOB DILFXTNS
> // DATE 12/31/05
> // UPSI 00001000
> // EXEC PGM=LFEXTION,SIZE=AUTO
> 203
> /* EOD
> // SETPARM CO='203'
> * $$ SLI LFXTNLCL
> /& EOJ
> * $$ EOJ
>
> Thus, the SLI in the job above (with the following content) will capture
> the POWER job name and number and pass these as parameters into a dynamic
> FTP process.
>
> /. FTP &CO TO WINSRV1
> * $. LST DISP=D,CLASS=Z
> // LIBDEF *,SEARCH=(PRD2.CONFIG,ESP.BSI),TEMP
> // SETPARM JOBNM=' '
> // SETPARM JOBNO=' '
> // EXEC REXX=JOBINFO,JOBNM,JOBNO
> // EXEC REXX=BSIREXXC,PARM='BSIFTP',JOBNM,JOBNO,CO
> ID 00
> OPEN WINSRV1.WINWHOLESALE.COM
> USER xxxxxxxx
> PASS xxxxxxxx
> SYST
> TYPE A
> SITE NAMEFMT 1
> SEND RCMD CALL PGM(PGM460/ACFTPPRTCL) PARM('EXTENSION' '')
> CWD QSYS.LIB/DTA.LIB
> *
> * input from power queue
> INPUT POWER LST *
> STOR EXTENSION.FILE/EXTENSION.MBR
> QUIT
> /* EOD
>
> So, to finish this long story, if there is another way to
dynamically
> determine the job name and number of more than one LST queue entry that
are
> all created out of a single job execution -- then I'm all ears. ;-)
>
> Sincerely,
>
> Dave Clark
>
> DAPSCO Information Systems
> 3110 Kettering Boulevard
> Dayton, Ohio 45439
> (937) 294-5331
>