Re: Nanosecond resolution timestamps for HLL's?

[Jon Perryman]

On Tue, 20 Feb 2024 22:58:42 +, Farley, Peter  
wrote:

>the monotonically increasing real-time clock to be the “tie breaker” value.  

Real-time clocks are not monotonical. Regardless of vendor, there is 1 
real-time clock shared by all CPU cores. 

> I guess COBOL programmers aren’t supposed to be that “sophisticated”.

Cobol flawlessly implement security, flawlessly optimize programs that need to 
be optimized, flawlessly implement NOSQL, flawlessly implement private cloud 
applications and more. Cobol programmers are more likely to educate themselves 
more on their line of business.

>Or maybe the real issue is the lack of existing support in COBOL for data 
>structures 
>like heaps, queues, lists, maps and sets that are so common else where 
>in the programming language universe.  

Why implement these concepts when there are robust z/OS alternatives that 
achieve the same results?

>  if the “keys” for the heap to be attached were guaranteed by the application 
> design 
> and implementation not to have any of the keys in the heap to which it is 
> being attached,
> just keeping the highest counter value would be sufficient. 

Why bother with unique keys if all you want is LIFO or FIFO access by key. Do 
you have a problem with using duplicate keys in the heap and access using min 
or max? I'm guessing you are writing the heap logic. You can read from the left 
branch and write to the right branch.  

>In the more general case, how do we get away from needing to use assembler to 
>write COBOL?  
>Using CS, CDS, CDSG, PLO, ENQ, etc. to maintain a consistent non-timer counter 
>value would
> all need to be invoked from assembler (or possibly MetalC using 
> “builtins.h”).  

Under CICS, Cobol has direct access to ENQ and STORAGE OBTAIN. Single threaded 
COBOL does not need serialization (e.g. ENQ). Someone familiar with COBOL and 
the environment you will be using can tell you if storage obtain, 
multi-threaded and serialization is available / how to use it.

>Mind you, I am far from one to shy away from assembler, I am very comfortable 
>with it.

Trivial assembler programs should be acceptable. STORAGE OBTAIN / RELEASE is 
trivial. CSDG for serialization update of a counter is trivial. Metal C could 
probably achieve the same functionality.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DD SYMLIST?

[Paul Gilmartin]

On Thu, 22 Feb 2024 13:45:18 +1000, Peter Vels  wrote:

>https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-symlist-parameter
>
I'm  looking at Page 263 of  SA23-1385-60
z/OS 3.1 MVS JCL Reference
with the page heading DD: SYMLIST

>On Thu, 22 Feb 2024 at 12:46, Paul Gilmartin  wrote:
>
>> What does the SYMLIST parameter of the JCL DD statement do?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DD SYMLIST?

[Peter Vels]

https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-symlist-parameter



On Thu, 22 Feb 2024 at 12:46, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> What does the SYMLIST parameter of the JCL DD statement do?
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: zsh for z/OS

[Rick Troth]

For scripting, most recommend Bourne-compatible, which includes BASH, 
ZSH, DASH, and [PD]KSH.
In my experience, when you stick with a certain subset of what these all 
do you'll be "safe" and your scripts will not break if/when you carry 
them around.
I have tried to distill some of the lessons learned in recent years into 
a "best practice" doc.


https://github.com/trothr/best/blob/main/Shell.md

We talked briefly here about profiling. Easiest way to have consistent 
profiling is to *not* use the shell-specific variants.
(For example, if your login shell is BASH, then use ~/.profile and avoid 
~/.bash_profile.)

I really need to add this info to that page.

Some people like CSH for interactive work, for which there is TCSH in 
open source land. But CSH variants are *not* recommended for scripting.


Coming to closure, I have recently built the following for the Chicory 
project:


 * bash-5.2.21
 * zsh-5.9
 * dash-0.5.12
 * pdksh-5.2.14
 * tcsh-6.24.10


I don't have access to a USS environment which I'm free to use for 
public things, so I don't have any of these built for MVS.
The platforms I *do* have include: Linux-i386, Linux-x86_64, Linux-s390, 
Linux-s390x, Linux-arm, FreeBSD-amd64, SunOS-i386, SunOS-x86_64.
You can find most of them under rsync://chic.casita.net/opt. (If they're 
not there now, they should be in the next 24 hours.)


I hope this helps.

-- R; <><


On 2/19/24 14:31, Pew, Curtis G wrote:

On Feb 17, 2024, at 11:00 AM, Paul 
Gilmartin<042bfe9c879d-dmarc-requ...@listserv.ua.edu>  wrote:

What are the benefits of zsh?  Are there incompatibilities?

I largely stay with POSIX shell for portability of scripts and skills.

Apple switched to zsh because newer versions of bash are covered by the GPLv3 
license, which is less corporate-friendly than the older GPLv2. I would assume 
that IBM has similar motivation.

If you’re still seeing bash on a Mac that probably means you started using it 
before the switch. It’s been a while, but when they switched the default I had 
to do something (probably in Terminal) to get it to switch for me. (It used to 
prompt you to switch if you opened with a bash shell.) There’s still bash 
available on MacOS, but it’s a rather old version, 3.2.57 while the current 
stable release is 5.2.21.


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

DD SYMLIST?

[Paul Gilmartin]

What does the SYMLIST parameter of the JCL DD statement do?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

The runtime is all part of LE.

Our shop does not have the C/C++ compiler.  Never had a business need for it.  
Never even looked in to it, so I don't know the cost.

From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 21, 2024 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

Michael,

I do not think it requires the C/C++ compiler to use the C RTL subroutines 
delivered in CEE.SCEELKEX.  You only need the C/C++ documentation to look up 
the routine names, though working out how the C "header" files define the 
parameters and return value and translating those to COBOL would be challenging 
without the headers installed.

Is any large commercial shop actually NOT licensing the XL C/C++ compiler these 
days?  I would hope the cost is not be so prohibitive as to bedevil the 
bean-counters looking for $$ savings.  Don't at least some vendor products 
coded in C/C++ require at least the RTL subroutines (and maybe also the C++ 
DLL's) installed in order to execute at all?  Or is that all delivered in LE?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, February 21, 2024 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?



And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 12:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Nanosecond resolution timestamps for HLL's?



Try this.



   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.

   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.

   end program 'cgettime_test'.





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu>

Sent: Monday, February 19, 2024 5:30 PM

To: IBM-MAIN@LISTSERV.UA.EDU 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>

Subject: Re: Nanosecond resolution timestamps for HLL's?



My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.



Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker 

Re: Nanosecond resolution timestamps for HLL's?

[Frank Swarbrick]

No C compiler required.  The C runtime is required, but that comes with the OS 
(Language Environment).

You bind against SCEELKEX.  No Unix required.

From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Sent: Wednesday, February 21, 2024 4:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?

And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

Try this.


   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.



   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.



   end program 'cgettime_test'.




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.

Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker value.  I would much prefer an IBM-maintained solution that 
crosses the epoch barrier transparently.

A reasonably-well-performing implementation of the C function "clock_gettime()" 
would probably do the trick, if it was callable from COBOL.  David C. pointed 
out in an earlier reply that IBM XL C now has this function, if I can figure 
out how to invoke it from COBOL.  IBM is not always very good at providing 
illustrative examples for inter-language cases like this.

As for the actual business purpose, I'm not at liberty to discuss that.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Monday, February 19, 2024 4:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


I don't understand how you will use this.



What is the business purpose?



On Sun, 18 Feb 2024 18:22:53 -0600 Peter Farley

<031df298a9da-dmarc-requ...@listserv.ua.edu>
 wrote:



:>I have been reviewing all the documentation I can find to provide nano-second 
resolution timestamps from a calling HLL batch program.  STCK and STCKE 
instructions of course provide this (and more) resolution, but using them from 
any HLL besides C/C++ 

Re: Something keeps releasing space on a large (annual) DS

[Paul Feller]

I need to correct myself.  The limit is 16 extents per volume for standard 
datasets and for extended it is 123 extents per volume.  I guess I was typing 
faster than my brain was thinking.


>From the DFSMSdfp Storage Administration manual (z/OS 2.5)

The maximum number of extents per volume and the maximum number of volumes per 
data set vary
depending on data set type as follows:
 • A basic-format or large-format sequential data set and a direct data set can 
have up to 16 extents
 per volume and up to 59 volumes.
 • An extended-format sequential data set can have up to 123 extents per volume 
and up to 59
 volumes. Either all or none of these volumes can be arranged into stripes for 
parallel processing.
 • A non-system-managed VSAM data set can have up to 255 extents per component 
and up to 59
 volumes.
 • A system-managed VSAM data set can have up to 255 extents per stripe and up 
to 59 volumes. This
 extent limit can be removed if the associated data class has extent constraint 
removal specified. Up
 to 16 volumes at a time can be read or written in parallel due to striping.
 • A PDS can have up to 16 extents and only one volume.
 • A PDSE can have up to 123 extents and only one volume.
 • An HFS data set can have up to 123 extents per volume and up to 59 volumes.

Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Wednesday, February 21, 2024 4:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

DSNTYPE=LARGE allows the 65,535 track (4,369 cylinder) limit to be exceeded. 
This should be restricted to SPOOL datasets and the like.

DSNTYPE=EXTENDED does NOT allow this size limit to be exceeded.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Feller
Sent: Wednesday, February 21, 2024 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Bob, sorry we should have answered some of your questions at the end of your 
email

Let me start by saying your storage management team should be able to answer 
all your questions.  That said I'll answer some of your questions based on what 
I know.  These are general answers.  The SMS environment you are running under 
could have overrides that may affect what happens.

You asked "What IS extended PS, anyway?  I'm told it allows more than 16 
extents, but a) how many more? And b) how else is it different?"

Basically, an extended format dataset is allowed to be bigger than a standard 
(or none extended) in several ways.
Extended format allows for 123 volumes where non-extended is 16 volumes.
Extended format allows for far larger allocation of a dataset on one volume 
then a non-extended.  If I recall a non-extended max size is 65,535 tracks.


As far as I know using 3.2 to allocate the data should not be an issue.  It 
should (as far as I know) drive the same SMS ACS routines that are used in 
batch.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know 

Re: Nanosecond resolution timestamps for HLL's?

[Farley, Peter]

Michael,

I do not think it requires the C/C++ compiler to use the C RTL subroutines 
delivered in CEE.SCEELKEX.  You only need the C/C++ documentation to look up 
the routine names, though working out how the C "header" files define the 
parameters and return value and translating those to COBOL would be challenging 
without the headers installed.

Is any large commercial shop actually NOT licensing the XL C/C++ compiler these 
days?  I would hope the cost is not be so prohibitive as to bedevil the 
bean-counters looking for $$ savings.  Don't at least some vendor products 
coded in C/C++ require at least the RTL subroutines (and maybe also the C++ 
DLL's) installed in order to execute at all?  Or is that all delivered in LE?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, February 21, 2024 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?



And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Frank 
Swarbrick

Sent: Tuesday, February 20, 2024 12:01 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Nanosecond resolution timestamps for HLL's?



Try this.



   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.

   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.

   end program 'cgettime_test'.





From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu>

Sent: Monday, February 19, 2024 5:30 PM

To: IBM-MAIN@LISTSERV.UA.EDU 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>

Subject: Re: Nanosecond resolution timestamps for HLL's?



My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.



Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker value.  I would much prefer an IBM-maintained solution that 
crosses the epoch barrier transparently.



A reasonably-well-performing implementation of the C function "clock_gettime()" 
would probably do the trick, if it was callable from COBOL.  David C. pointed 
out in an earlier reply that IBM XL C now has this function, if I can figure 
out how to invoke it from COBOL.  IBM is not always very good at providing 
illustrative examples for 

Re: Something keeps releasing space on a large (annual) DS

[Mike Schwab]

Our site submitted defrag jobs.  Not part of release processing.

On Wed, Feb 21, 2024 at 3:33 PM Ed Jaffe
<05acc3c79bf7-dmarc-requ...@listserv.ua.edu> wrote:
>
> On 2/21/2024 12:52 PM, Gibney, Dave wrote:
> > However, HSM Partial Release should consolidate extents...
>
> Not in my experience. It removes "extraneous" extents (if any), but
> doesn't actually do any sort of consolidation of occupied extents.
>
> That said, I believe if you migrate and then later recall a data set, a
> consolidation does occur.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AI is the real deal.

[Dave Beagle]

Well, today was NVIDIA earnings day. They are the bellwether for AI. Theirs is 
the premier AI chip commanding top dollar. And they didn’t disappoint. Their 
revenues are up 400% in the last year. To 22 billion in the latest quarter. 
They’ve got another chip on tap this year which should continue the incredible 
growth. If you had invested $10,000 five years ago, you’d have earned 2000%, 
and would have $200,000. If you had invested $10,000 ten years ago, you’d have 
earned over 16,465%. And have 1.65 million. AI is only in its infancy. It will 
be bigger than the internet. Microsoft, META, Google, and nearly every IT 
company is betting big on AI. That spending will continue. NVIDIA’s market cap 
is approaching 2 trillion.  It’s now the 3rd largest company in the world by 
market cap. (Behind Microsoft & Apple) To think AI is just a passing fad is 
foolish. 




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Nanosecond resolution timestamps for HLL's?

[Schmitt, Michael]

This requires a C compiler to be installed on z/OS, which doesn't come 
standard, correct?

And if you had z/OS XL C, how would you bind this? I mean, is this one of those 
things where you're binding against a path on the OEMVS side?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Frank Swarbrick
Sent: Tuesday, February 20, 2024 12:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?

Try this.


   process pgmname(longmixed) nodynam

   id division.

   program-id. 'cgettime_test'.

   data division.

   working-storage section.

   01  errno-ref   pointer.

   01  strerror-refpointer.

   01  len pic s9(9) comp-5.

   01  display-x.

   05  pic x occurs 0 to 1025 depending on len.



   01  clock_idpic s9(9) comp-5.

   01  timespec.

   05  secspic s9(9) comp-5.

   05  nsecs   pic s9(9) comp-5.

   01  rc  pic s9(9) comp-5.



   linkage section.

   01  errno   pic s9(9) comp-5.

   01  h_errno pic s9(9) comp-5.

   01  strerrorpic x(256).



   procedure division.

   call 'clock_gettime' using value clock_id

  reference timespec

returning rc

   if rc = zero

   display 'seconds: ' secs

   display 'nanoseconds:' nsecs

   else

   perform handle-error

   end-if

   goback.



   handle-error.

   call '__errno' returning errno-ref

   set address of errno to errno-ref

   call 'strerror' using value errno

returning strerror-ref

   set address of strerror to strerror-ref

   move 1025 to len

   unstring strerror delimited by x'00'

into display-x count len

   display quote display-x quote

   exit.



   end program 'cgettime_test'.




From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Nanosecond resolution timestamps for HLL's?

My initial purpose is actually part of implementing COBOL-compatible min-heap 
priority queue functions that return equal-priority nodes in FIFO insert order 
when popped.  A timestamp or some other monotonically increasing integer 
tie-breaker provided with the input priority value is necessary to preserve 
FIFO order when pushing new items into the queue.  As Paul (gil) pointed out, 
named counters might provide a similar function but would be far more 
performance-expensive compared to a simple STCK value.

Yes, I am aware that STCK breaks at the epoch in 2038 (or is it 2042? I forget 
now), which isn't ALL that far away.  A MetalC implementation for STCK values 
has been coded and works acceptably, as does of course a straight-forward 
assembler implementation.  Extension to use STCKE instead of STCK would be 
trivial in either case, but of course that also doubles the space occupied by 
the tiebreaker value.  I would much prefer an IBM-maintained solution that 
crosses the epoch barrier transparently.

A reasonably-well-performing implementation of the C function "clock_gettime()" 
would probably do the trick, if it was callable from COBOL.  David C. pointed 
out in an earlier reply that IBM XL C now has this function, if I can figure 
out how to invoke it from COBOL.  IBM is not always very good at providing 
illustrative examples for inter-language cases like this.

As for the actual business purpose, I'm not at liberty to discuss that.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Monday, February 19, 2024 4:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Nanosecond resolution timestamps for HLL's?


I don't understand how you will use this.



What is the business purpose?



On Sun, 18 Feb 2024 18:22:53 -0600 Peter Farley

<031df298a9da-dmarc-requ...@listserv.ua.edu>
 wrote:



:>I have been reviewing all the documentation I can find to provide nano-second 
resolution timestamps from a calling HLL batch program.  STCK and STCKE 
instructions of course provide this (and more) resolution, but using them from 
any HLL besides C/C++ requires an assembler subroutine (however simple that may 
be for those of us who are already comfortable in assembler).  In shops where 
any new assembler functionality is proscribed or strongly discouraged can't or 
would strongly prefer not to use assembler for this functionality.



:>The only HLL-callable function already provided in z/OS that I can find that 
provides 

Re: Something keeps releasing space on a large (annual) DS

[Michael Watkins]

DSNTYPE=LARGE allows the 65,535 track (4,369 cylinder) limit to be exceeded. 
This should be restricted to SPOOL datasets and the like.

DSNTYPE=EXTENDED does NOT allow this size limit to be exceeded.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Feller
Sent: Wednesday, February 21, 2024 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Bob, sorry we should have answered some of your questions at the end of your 
email

Let me start by saying your storage management team should be able to answer 
all your questions.  That said I'll answer some of your questions based on what 
I know.  These are general answers.  The SMS environment you are running under 
could have overrides that may affect what happens.

You asked "What IS extended PS, anyway?  I'm told it allows more than 16 
extents, but a) how many more? And b) how else is it different?"

Basically, an extended format dataset is allowed to be bigger than a standard 
(or none extended) in several ways.
Extended format allows for 123 volumes where non-extended is 16 volumes.
Extended format allows for far larger allocation of a dataset on one volume 
then a non-extended.  If I recall a non-extended max size is 65,535 tracks.


As far as I know using 3.2 to allocate the data should not be an issue.  It 
should (as far as I know) drive the same SMS ACS routines that are used in 
batch.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 

Re: Something keeps releasing space on a large (annual) DS

[Paul Feller]

Bob, sorry we should have answered some of your questions at the end of your 
email

Let me start by saying your storage management team should be able to answer 
all your questions.  That said I'll answer some of your questions based on what 
I know.  These are general answers.  The SMS environment you are running under 
could have overrides that may affect what happens.

You asked "What IS extended PS, anyway?  I'm told it allows more than 16 
extents, but a) how many more? And b) how else is it different?"

Basically, an extended format dataset is allowed to be bigger than a standard 
(or none extended) in several ways.
Extended format allows for 123 volumes where non-extended is 16 volumes.
Extended format allows for far larger allocation of a dataset on one volume 
then a non-extended.  If I recall a non-extended max size is 65,535 tracks.


As far as I know using 3.2 to allocate the data should not be an issue.  It 
should (as far as I know) drive the same SMS ACS routines that are used in 
batch.


Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Michael Watkins]

Also, forgot to add: list the dataset and note the management class (MGMTCLAS). 
This will tell you how DFSMShsm is managing the dataset and whether space is 
routinely being released.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Wednesday, February 21, 2024 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

Yes, always allocate anything other than a very small dataset in cylinders.

Also, keep in mind that an extended PS appends a 32-byte suffix onto every 
block of data (an 8-byte prefix onto blocks of datasets allocated as  
DSNTYPE=LARGE). Specifying BLKSIZE=27998 may mean that you only have 1 block on 
each virtual 3390 track on your RAID storage frame. Perhaps code BLKSIZE=0 and 
let the system determine the BLKSIZE.

One advantage extended format datasets enjoy is that up to 123 extents can be 
allocated on each volume, although the 65,535 tracks (4,369 CYLs) per volume 
z/OS limit is still adhered to.

Unless there are limits imposed by your application, do not hesitate to span up 
to the z/OS limit of 59 volumes or take advantage of zEDC compression.

Also: Not all applications, particularly those that have a special internal 
format (like SAS) or that write their own I/O (like Adabase) can use extended 
format datasets.

Inquire with your storage manager whether there is an existing DATACLAS that 
meets your needs. Or explain your issues and perhaps the storage manager will 
design a DATACLAS for you.

Good luck!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, February 21, 2024 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.

On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 

Re: Something keeps releasing space on a large (annual) DS

[Michael Watkins]

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

Yes, always allocate anything other than a very small dataset in cylinders.

Also, keep in mind that an extended PS appends a 32-byte suffix onto every 
block of data (an 8-byte prefix onto blocks of datasets allocated as  
DSNTYPE=LARGE). Specifying BLKSIZE=27998 may mean that you only have 1 block on 
each virtual 3390 track on your RAID storage frame. Perhaps code BLKSIZE=0 and 
let the system determine the BLKSIZE.

One advantage extended format datasets enjoy is that up to 123 extents can be 
allocated on each volume, although the 65,535 tracks (4,369 CYLs) per volume 
z/OS limit is still adhered to. 

Unless there are limits imposed by your application, do not hesitate to span up 
to the z/OS limit of 59 volumes or take advantage of zEDC compression.

Also: Not all applications, particularly those that have a special internal 
format (like SAS) or that write their own I/O (like Adabase) can use extended 
format datasets.

Inquire with your storage manager whether there is an existing DATACLAS that 
meets your needs. Or explain your issues and perhaps the storage manager will 
design a DATACLAS for you.

Good luck!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Wednesday, February 21, 2024 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.

On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE", "SPACE(300,30) CYLINDERS 
RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

 ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Re: Something keeps releasing space on a large (annual) DS

[Gibney, Dave]

At some point in the past, and maybe for  greater than n? extents, HSM 
accomplished partial release by a migrate/recall under the covers. The may also 
be an additional SETSYS needed to enable extent reduction

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ed Jaffe
> Sent: Wednesday, February 21, 2024 1:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Something keeps releasing space on a large (annual) DS
> 
> [EXTERNAL EMAIL]
> 
> On 2/21/2024 12:52 PM, Gibney, Dave wrote:
> > However, HSM Partial Release should consolidate extents...
> 
> Not in my experience. It removes "extraneous" extents (if any), but doesn't
> actually do any sort of consolidation of occupied extents.
> 
> That said, I believe if you migrate and then later recall a data set, a
> consolidation does occur.
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.phoenixsoftware.com%2F__
> %3B!!JmPEgBY0HMszNaDT!v19RPyz3qPLVbvxhsix3B5bt02NriXaW69j3ZFop
> m3wyEcoykkW9OjkXgCYvsKFGT1LZCYk7Yzlh1Pjwm0kgfYr-
> M8m5TqZg%24=05%7C02%7CGIBNEY%40WSU.EDU%7C64fa6b8b02a
> f404c10a908dc3324b77f%7Cb52be471f7f147b4a8790c799bb53db5%7C0
> %7C0%7C638441479982068087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C=eun2fYIkexK6nTob2BBNvsRaMZQ3SWbAxumeMiUENB
> g%3D=0
> 
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended 
> recipient(s).
> If you are not an intended recipient or have otherwise received this email
> message in error, any use, dissemination, distribution, review, storage or
> copying of this e-mail message and the information contained therein is 
> strictly
> prohibited. If you are not an intended recipient, please contact the sender by
> reply e-mail and destroy all copies of this email message and do not otherwise
> utilize or retain this email message or any or all of the information 
> contained
> therein. Although this email message and any attachments or appended
> messages are believed to be free of any virus or other defect that might 
> affect
> any computer system into which it is received and opened, it is the
> responsibility of the recipient to ensure that it is virus free and no
> responsibility is accepted by the sender for any loss or damage arising in any
> way from its opening or use.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Ed Jaffe]

On 2/21/2024 12:52 PM, Gibney, Dave wrote:

However, HSM Partial Release should consolidate extents...


Not in my experience. It removes "extraneous" extents (if any), but 
doesn't actually do any sort of consolidation of occupied extents.


That said, I believe if you migrate and then later recall a data set, a 
consolidation does occur.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Mike Schwab]

Its probably doing a release.
Do a cylinder allocation to at average 7 tracks after release.
Defragment to consolidate extents weekly / twice a week / MWF / daily.


On Wed, Feb 21, 2024 at 11:45 AM Bob Bridges
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
>
> I'm not a sysprog (just a security geek), but I can at least allocate 
> datasets, and at the start of this year it fell to me to allocate a new 
> dataset in which are logged all changes made in the security system.  Past 
> year's log are in the 12000-track range, so I started with a smaller 
> allocation while I took the time to talk to our sysprog about space 
> requirements.  It's populated from a daily production job, by the way.
>
> When I re-allocated it, on his advice I tried a multi-volume and extended 
> allocation (PS-E).  Almost immediately the job started bombing, claiming that 
> the first four volumes it tried didn't have the necessary space to add an 
> extension.  The sysprog is puzzled - says it should have looked in volumes 
> that DO have the space, not the ones that don't.
>
> Second attempt (I don't count the temporary smaller allocation) I kept PS-E 
> but dropped the multi-volume requirement.  I've never done one of those 
> anyway, and don't trust 'em.  The system promptly dropped the extra tracks I 
> allocated, and a day or two later the job started bombing with a B37-04.
>
> Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
> SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
> noticed that something, somewhere, has released extra space AGAIN; 3.4 tells 
> me it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later 
> in the year I'm guessing it's going to.
>
> Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
> space although I never specified RLSE?  The sysprog doesn't know either - but 
> he's an external contractor who just took over the system a few months ago 
> and if it's something simple he may not be aware yet of ... I dunno, 
> something in SMS maybe?
>
> Some wrinkles that may or may not be relevant:
>
> 1) The dataset is written using a REXX exec that calculates the DSN by 
> reference to the current year.  This relieves folks from having to update the 
> JCL every year, but maybe something about the way the exec does the allocate 
> is causing the problem?  I'm guessing not, because as far as I now this job 
> has run correctly for years.  But just in case:
>
>   "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
>   "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"
>
> 2) I don't know anything about SMS, but could something there be releasing 
> space?
>
> 3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
> a) how many more? And b) how else is it different?
>
> 4) I allocated the dataset each time using not batch JCL but 3.2 ... 
> expecting there's no difference.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Law #6 of combat operations:  If it's stupid but it works, it isn't 
> stupid. */
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Gibney, Dave]

However, HSM Partial Release should consolidate extents, so a properly sized 
(big) secondary should keep the abends at bay

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Feller
> Sent: Wednesday, February 21, 2024 12:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Something keeps releasing space on a large (annual) DS
> 
> [EXTERNAL EMAIL]
> 
> Bob as Steve said you might want to talk to your storge management team.
> What I think is happening is your dataset is getting a management class that
> has Partial Release set and then HSM is doing space management and releasing
> any unused space.  I've seen this happen before and it has happened to me.
> 
> Good luck.
> 
> Paul
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Steve Thompson
> Sent: Wednesday, February 21, 2024 1:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Something keeps releasing space on a large (annual) DS
> 
> Ask the storage guys about the preferred method to allocate a file that will 
> get
> very large during production runs. And you don't want production to fail with
> a storage ABEND. And let them know about the current behavior. They may
> have made a change that is the cause of your problem.
> 
> Then you can modify the REXX code to include the class info they give you.
> 
> Also, I suggest you allocate in CYLS not TRKS in the case they are doing
> compression of space on data sets allocated in tracks...
> 
> I've seen various odd things done to recover space for files that can't be on 
> the
> tracks after 65xxx (forgot the last track accessible by the old NOTE/POINT 
> that
> causes products like Panvalet to break).
> 
> And if I remember correctly, compression/decompression is done by the
> access method. Double check to make sure this isn't a VSAM thing.
> 
> I've not had to deal with these features for a few years So things slip 
> from
> one's mind.
> 
> Steve Thompson
> 
> On 2/21/2024 2:33 PM, Bob Bridges wrote:
> > Ooh, now that's interesting!  The content of this file would lend
> > itself well to compression - all alphanumeric with a few parens,
> > colons and the like.  But what happens when someone needs to view it?
> > Does it compress automatically or is another step required?
> >
> > It's not something I can bring up now, because everyone's busy with a
> > z/OS upgrade.  But next month...
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* For Sale: Parachute.  Only used once, never opened, small stain. */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Michael Oujesky
> > Sent: Wednesday, February 21, 2024 13:49
> >
> > You might consider SMS compression to reduce the physical size of the file.
> > If you do, change the BLKSIZE to 32760 as SMS compression writes full
> > tracks and the BLKSIZE becomes logical (the size of the buffer used in
> > passing date to/from the application).
> >
> > --- At 11:44 AM 2/21/2024, Bob Bridges wrote:
> >> I'm not a sysprog (just a security geek), but I can at least allocate
> >> datasets, and at the start of this year it fell to me to allocate a
> >> new dataset in which are logged all changes made in the security system.
> >> Past year's log are in the 12000-track range, so I started with a
> >> smaller allocation while I took the time to talk to our sysprog about
> >> space requirements.  It's populated from a daily production job, by
> >> the way.
> >>
> >> When I re-allocated it, on his advice I tried a multi-volume and
> >> extended allocation (PS-E).  Almost immediately the job started
> >> bombing, claiming that the first four volumes it tried didn't have
> >> the necessary space to add an extension.  The sysprog is puzzled -
> >> says it should have looked in volumes that DO have the space, not the
> >> ones that don't.
> >>
> >> Second attempt (I don't count the temporary smaller allocation) I
> >> kept PS-E but dropped the multi-volume requirement.  I've never done
> >> one of those anyway, and don't trust 'em.  The system promptly
> >> dropped the extra tracks I allocated, and a day or two later the job
> >> started bombing with a B37-04.
> >>
> >> Third attempt: Forget PS-E (I'm unfamiliar with that too) and just
> >> used SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week,
> >> but I just noticed that something, somewhere, has released extra
> >> space AGAIN;
> >> 3.4 tells me it's now 1960 tracks and 83%.  The job isn't bombing
> >> yet; some time later in the year I'm guessing it's going to.
> >>
> >> Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep
> >> releasing space although I never specified RLSE?  The sysprog doesn't
> >> know either - but he's an external contractor who just took over the
> >> system a few months ago and if it's something simple he may not be
> >> aware yet of ... I dunno, something in SMS maybe?
> >>
> >> Some wrinkles that may or may not be 

Re: Something keeps releasing space on a large (annual) DS

[Paul Feller]

Bob as Steve said you might want to talk to your storge management team.  What 
I think is happening is your dataset is getting a management class that has 
Partial Release set and then HSM is doing space management and releasing any 
unused space.  I've seen this happen before and it has happened to me.

Good luck.

Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Wednesday, February 21, 2024 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Something keeps releasing space on a large (annual) DS

Ask the storage guys about the preferred method to allocate a file that will 
get very large during production runs. And you don't want production to fail 
with a storage ABEND. And let them know about the current behavior. They may 
have made a change that is the cause of your problem.

Then you can modify the REXX code to include the class info they give you.

Also, I suggest you allocate in CYLS not TRKS in the case they are doing 
compression of space on data sets allocated in tracks...

I've seen various odd things done to recover space for files that can't be on 
the tracks after 65xxx (forgot the last track accessible by the old NOTE/POINT 
that causes products like Panvalet to break).

And if I remember correctly, compression/decompression is done by the access 
method. Double check to make sure this isn't a VSAM thing.

I've not had to deal with these features for a few years So things slip 
from one's mind.

Steve Thompson

On 2/21/2024 2:33 PM, Bob Bridges wrote:
> Ooh, now that's interesting!  The content of this file would lend 
> itself well to compression - all alphanumeric with a few parens, 
> colons and the like.  But what happens when someone needs to view it?  
> Does it compress automatically or is another step required?
>
> It's not something I can bring up now, because everyone's busy with a 
> z/OS upgrade.  But next month...
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* For Sale: Parachute.  Only used once, never opened, small stain. */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Michael Oujesky
> Sent: Wednesday, February 21, 2024 13:49
>
> You might consider SMS compression to reduce the physical size of the file.
> If you do, change the BLKSIZE to 32760 as SMS compression writes full 
> tracks and the BLKSIZE becomes logical (the size of the buffer used in 
> passing date to/from the application).
>
> --- At 11:44 AM 2/21/2024, Bob Bridges wrote:
>> I'm not a sysprog (just a security geek), but I can at least allocate 
>> datasets, and at the start of this year it fell to me to allocate a 
>> new dataset in which are logged all changes made in the security system.
>> Past year's log are in the 12000-track range, so I started with a 
>> smaller allocation while I took the time to talk to our sysprog about 
>> space requirements.  It's populated from a daily production job, by 
>> the way.
>>
>> When I re-allocated it, on his advice I tried a multi-volume and 
>> extended allocation (PS-E).  Almost immediately the job started 
>> bombing, claiming that the first four volumes it tried didn't have 
>> the necessary space to add an extension.  The sysprog is puzzled - 
>> says it should have looked in volumes that DO have the space, not the 
>> ones that don't.
>>
>> Second attempt (I don't count the temporary smaller allocation) I 
>> kept PS-E but dropped the multi-volume requirement.  I've never done 
>> one of those anyway, and don't trust 'em.  The system promptly 
>> dropped the extra tracks I allocated, and a day or two later the job 
>> started bombing with a B37-04.
>>
>> Third attempt: Forget PS-E (I'm unfamiliar with that too) and just 
>> used SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, 
>> but I just noticed that something, somewhere, has released extra 
>> space AGAIN;
>> 3.4 tells me it's now 1960 tracks and 83%.  The job isn't bombing 
>> yet; some time later in the year I'm guessing it's going to.
>>
>> Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep 
>> releasing space although I never specified RLSE?  The sysprog doesn't 
>> know either - but he's an external contractor who just took over the 
>> system a few months ago and if it's something simple he may not be 
>> aware yet of ... I dunno, something in SMS maybe?
>>
>> Some wrinkles that may or may not be relevant:
>>
>> 1) The dataset is written using a REXX exec that calculates the DSN 
>> by reference to the current year.  This relieves folks from having to 
>> update the JCL every year, but maybe something about the way the exec 
>> does the allocate is causing the problem?  I'm guessing not, because 
>> as far as I now this job has run correctly for years.  But just in case:
>>
>>"ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
>>"SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"
>>
>> 2) I don't know anything about SMS, but 

Re: Something keeps releasing space on a large (annual) DS

[Michael Oujesky]

SMS compression/de-compression is done by the access method 
(presuming regular QSAM/BSAM) and is usually transparent to the 
application.  A long time ago, tailored compression had a bug that 
lost track of where the tailored dictionary was kept and 
caused  abends when trying to read the file.  HMIGRATE/recall of the 
dataset corrected the error.  I would expect y'all have zEDC 
available and that operates on a block level providing better 
compression than either generic or tailored compression options.


Michael

At 01:33 PM 2/21/2024, Bob Bridges wrote:
Ooh, now that's interesting!  The content of this file would lend 
itself well to compression - all alphanumeric with a few parens, 
colons and the like.  But what happens when someone needs to view 
it?  Does it compress automatically or is another step required?


It's not something I can bring up now, because everyone's busy with a z/OS
upgrade.  But next month...

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* For Sale: Parachute.  Only used once, never opened, small stain. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Michael Oujesky
Sent: Wednesday, February 21, 2024 13:49

You might consider SMS compression to reduce the physical size of the file.
If you do, change the BLKSIZE to 32760 as SMS compression writes full tracks
and the BLKSIZE becomes logical (the size of the buffer used in passing date
to/from the application).

--- At 11:44 AM 2/21/2024, Bob Bridges wrote:
>I'm not a sysprog (just a security geek), but I can at least allocate
>datasets, and at the start of this year it fell to me to allocate a new
>dataset in which are logged all changes made in the security system.
>Past year's log are in the 12000-track range, so I started with a
>smaller allocation while I took the time to talk to our sysprog about
>space requirements.  It's populated from a daily production job, by the
>way.
>
>When I re-allocated it, on his advice I tried a multi-volume and
>extended allocation (PS-E).  Almost immediately the job started
>bombing, claiming that the first four volumes it tried didn't have the
>necessary space to add an extension.  The sysprog is puzzled - says it
>should have looked in volumes that DO have the space, not the ones that
>don't.
>
>Second attempt (I don't count the temporary smaller allocation) I kept
>PS-E but dropped the multi-volume requirement.  I've never done one of
>those anyway, and don't trust 'em.  The system promptly dropped the
>extra tracks I allocated, and a day or two later the job started
>bombing with a B37-04.
>
>Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used
>SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I
>just noticed that something, somewhere, has released extra space AGAIN;
>3.4 tells me it's now 1960 tracks and 83%.  The job isn't bombing yet;
>some time later in the year I'm guessing it's going to.
>
>Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep
>releasing space although I never specified RLSE?  The sysprog doesn't
>know either - but he's an external contractor who just took over the
>system a few months ago and if it's something simple he may not be
>aware yet of ... I dunno, something in SMS maybe?
>
>Some wrinkles that may or may not be relevant:
>
>1) The dataset is written using a REXX exec that calculates the DSN by
>reference to the current year.  This relieves folks from having to
>update the JCL every year, but maybe something about the way the exec
>does the allocate is causing the problem?  I'm guessing not, because as
>far as I now this job has run correctly for years.  But just in case:
>
>   "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
>   "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"
>
>2) I don't know anything about SMS, but could something there be
>releasing space?
>
>3) What IS extended PS, anyway?  I'm told it allows more than 16
>extents, but a) how many more? And b) how else is it different?
>
>4) I allocated the dataset each time using not batch JCL but 3.2 ...
>expecting there's no difference.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Steve Thompson]

Ask the storage guys about the preferred method to allocate a 
file that will get very large during production runs. And you 
don't want production to fail with a storage ABEND. And let them 
know about the current behavior. They may have made a change that 
is the cause of your problem.


Then you can modify the REXX code to include the class info they 
give you.


Also, I suggest you allocate in CYLS not TRKS in the case they 
are doing compression of space on data sets allocated in tracks...


I've seen various odd things done to recover space for files that 
can't be on the tracks after 65xxx (forgot the last track 
accessible by the old NOTE/POINT that causes products like 
Panvalet to break).


And if I remember correctly, compression/decompression is done by 
the access method. Double check to make sure this isn't a VSAM 
thing.


I've not had to deal with these features for a few years So 
things slip from one's mind.


Steve Thompson

On 2/21/2024 2:33 PM, Bob Bridges wrote:

Ooh, now that's interesting!  The content of this file would lend itself
well to compression - all alphanumeric with a few parens, colons and the
like.  But what happens when someone needs to view it?  Does it compress
automatically or is another step required?

It's not something I can bring up now, because everyone's busy with a z/OS
upgrade.  But next month...

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* For Sale: Parachute.  Only used once, never opened, small stain. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Michael Oujesky
Sent: Wednesday, February 21, 2024 13:49

You might consider SMS compression to reduce the physical size of the file.
If you do, change the BLKSIZE to 32760 as SMS compression writes full tracks
and the BLKSIZE becomes logical (the size of the buffer used in passing date
to/from the application).

--- At 11:44 AM 2/21/2024, Bob Bridges wrote:

I'm not a sysprog (just a security geek), but I can at least allocate
datasets, and at the start of this year it fell to me to allocate a new
dataset in which are logged all changes made in the security system.
Past year's log are in the 12000-track range, so I started with a
smaller allocation while I took the time to talk to our sysprog about
space requirements.  It's populated from a daily production job, by the
way.

When I re-allocated it, on his advice I tried a multi-volume and
extended allocation (PS-E).  Almost immediately the job started
bombing, claiming that the first four volumes it tried didn't have the
necessary space to add an extension.  The sysprog is puzzled - says it
should have looked in volumes that DO have the space, not the ones that
don't.

Second attempt (I don't count the temporary smaller allocation) I kept
PS-E but dropped the multi-volume requirement.  I've never done one of
those anyway, and don't trust 'em.  The system promptly dropped the
extra tracks I allocated, and a day or two later the job started
bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I
just noticed that something, somewhere, has released extra space AGAIN;
3.4 tells me it's now 1960 tracks and 83%.  The job isn't bombing yet;
some time later in the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep
releasing space although I never specified RLSE?  The sysprog doesn't
know either - but he's an external contractor who just took over the
system a few months ago and if it's something simple he may not be
aware yet of ... I dunno, something in SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by
reference to the current year.  This relieves folks from having to
update the JCL every year, but maybe something about the way the exec
does the allocate is causing the problem?  I'm guessing not, because as
far as I now this job has run correctly for years.  But just in case:

   "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
   "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be
releasing space?

3) What IS extended PS, anyway?  I'm told it allows more than 16
extents, but a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ...
expecting there's no difference.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Bob Bridges]

Ooh, now that's interesting!  The content of this file would lend itself
well to compression - all alphanumeric with a few parens, colons and the
like.  But what happens when someone needs to view it?  Does it compress
automatically or is another step required?

It's not something I can bring up now, because everyone's busy with a z/OS
upgrade.  But next month...

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* For Sale: Parachute.  Only used once, never opened, small stain. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Michael Oujesky
Sent: Wednesday, February 21, 2024 13:49

You might consider SMS compression to reduce the physical size of the file.
If you do, change the BLKSIZE to 32760 as SMS compression writes full tracks
and the BLKSIZE becomes logical (the size of the buffer used in passing date
to/from the application).

--- At 11:44 AM 2/21/2024, Bob Bridges wrote:
>I'm not a sysprog (just a security geek), but I can at least allocate 
>datasets, and at the start of this year it fell to me to allocate a new 
>dataset in which are logged all changes made in the security system.  
>Past year's log are in the 12000-track range, so I started with a 
>smaller allocation while I took the time to talk to our sysprog about 
>space requirements.  It's populated from a daily production job, by the 
>way.
>
>When I re-allocated it, on his advice I tried a multi-volume and 
>extended allocation (PS-E).  Almost immediately the job started 
>bombing, claiming that the first four volumes it tried didn't have the 
>necessary space to add an extension.  The sysprog is puzzled - says it 
>should have looked in volumes that DO have the space, not the ones that 
>don't.
>
>Second attempt (I don't count the temporary smaller allocation) I kept 
>PS-E but dropped the multi-volume requirement.  I've never done one of 
>those anyway, and don't trust 'em.  The system promptly dropped the 
>extra tracks I allocated, and a day or two later the job started 
>bombing with a B37-04.
>
>Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
>SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I 
>just noticed that something, somewhere, has released extra space AGAIN; 
>3.4 tells me it's now 1960 tracks and 83%.  The job isn't bombing yet; 
>some time later in the year I'm guessing it's going to.
>
>Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep 
>releasing space although I never specified RLSE?  The sysprog doesn't 
>know either - but he's an external contractor who just took over the 
>system a few months ago and if it's something simple he may not be 
>aware yet of ... I dunno, something in SMS maybe?
>
>Some wrinkles that may or may not be relevant:
>
>1) The dataset is written using a REXX exec that calculates the DSN by 
>reference to the current year.  This relieves folks from having to 
>update the JCL every year, but maybe something about the way the exec 
>does the allocate is causing the problem?  I'm guessing not, because as 
>far as I now this job has run correctly for years.  But just in case:
>
>   "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
>   "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"
>
>2) I don't know anything about SMS, but could something there be 
>releasing space?
>
>3) What IS extended PS, anyway?  I'm told it allows more than 16 
>extents, but a) how many more? And b) how else is it different?
>
>4) I allocated the dataset each time using not batch JCL but 3.2 ... 
>expecting there's no difference.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[Paul Gilmartin]

On Wed, 21 Feb 2024 11:32:26 -0600, Joe DeChirico wrote:

>
>Thanks for all the responses, it appears that there was garbage in included 
>module, once I removed if from inline and used a ++MOD(VSHMNTSK) 
>TXLIB(ZPROTOBJ) . the problem went away.
>
I'm surprised that makes a difference?

How did you build the JCL with instream  ++MOD?  Could the
binary data have been corrupted by that process?

Does RECEIVE verify instream  ++MOD elements?

What were the messages in the failing case?

//SMPPTFIN DD DATA,DLM=@@   
 

the DLM=@@ should have no effect with your data.

What happens if you include the binary by concatenation
rather than instream?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Allan Staller]

Classification: Confidential

The most likely reason is the DATACLAS(? Possibly MGMTCLAS)  ACS Routine. This  
is where partial space release is specified.
It is possible, but un likely that dfHSM is doing the partial space release. 
HSM would be honoring the "dictates" of the DATACLAS.

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, February 21, 2024 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Something keeps releasing space on a large (annual) DS

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with 

Re: Something keeps releasing space on a large (annual) DS

[Michael Oujesky]

You might consider SMS compression to reduce the physical size of the 
file.  If you do, change the BLKSIZE to 32760 as SMS compression 
writes full tracks and the BLKSIZE becomes logical (the size of the 
buffer used in passing date to/from the application).


Michael

At 11:44 AM 2/21/2024, Bob Bridges wrote:

I'm not a sysprog (just a security geek), but I can at least 
allocate datasets, and at the start of this year it fell to me to 
allocate a new dataset in which are logged all changes made in the 
security system.  Past year's log are in the 12000-track range, so I 
started with a smaller allocation while I took the time to talk to 
our sysprog about space requirements.  It's populated from a daily 
production job, by the way.


When I re-allocated it, on his advice I tried a multi-volume and 
extended allocation (PS-E).  Almost immediately the job started 
bombing, claiming that the first four volumes it tried didn't have 
the necessary space to add an extension.  The sysprog is puzzled - 
says it should have looked in volumes that DO have the space, not 
the ones that don't.


Second attempt (I don't count the temporary smaller allocation) I 
kept PS-E but dropped the multi-volume requirement.  I've never done 
one of those anyway, and don't trust 'em.  The system promptly 
dropped the extra tracks I allocated, and a day or two later the job 
started bombing with a B37-04.


Third attempt: Forget PS-E (I'm unfamiliar with that too) and just 
used SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, 
but I just noticed that something, somewhere, has released extra 
space AGAIN; 3.4 tells me it's now 1960 tracks and 83%.  The job 
isn't bombing yet; some time later in the year I'm guessing it's going to.


Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep 
releasing space although I never specified RLSE?  The sysprog 
doesn't know either - but he's an external contractor who just took 
over the system a few months ago and if it's something simple he may 
not be aware yet of ... I dunno, something in SMS maybe?


Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN 
by reference to the current year.  This relieves folks from having 
to update the JCL every year, but maybe something about the way the 
exec does the allocate is causing the problem?  I'm guessing not, 
because as far as I now this job has run correctly for years.  But 
just in case:


  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be 
releasing space?


3) What IS extended PS, anyway?  I'm told it allows more than 16 
extents, but a) how many more? And b) how else is it different?


4) I allocated the dataset each time using not batch JCL but 3.2 ... 
expecting there's no difference.


---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #6 of combat operations:  If it's stupid but it works, it 
isn't stupid. */


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Something keeps releasing space on a large (annual) DS

[Mark Jacobs]

PS-E (extended format) allows for 123 extents on a single volume. If the 
allocated dataset is SMS managed its assigned management class is likely the 
reason why free space is being released. 

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


On Wednesday, February 21st, 2024 at 12:44 PM, Bob Bridges 
<0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:

> I'm not a sysprog (just a security geek), but I can at least allocate 
> datasets, and at the start of this year it fell to me to allocate a new 
> dataset in which are logged all changes made in the security system. Past 
> year's log are in the 12000-track range, so I started with a smaller 
> allocation while I took the time to talk to our sysprog about space 
> requirements. It's populated from a daily production job, by the way.
> 
> When I re-allocated it, on his advice I tried a multi-volume and extended 
> allocation (PS-E). Almost immediately the job started bombing, claiming that 
> the first four volumes it tried didn't have the necessary space to add an 
> extension. The sysprog is puzzled - says it should have looked in volumes 
> that DO have the space, not the ones that don't.
> 
> Second attempt (I don't count the temporary smaller allocation) I kept PS-E 
> but dropped the multi-volume requirement. I've never done one of those 
> anyway, and don't trust 'em. The system promptly dropped the extra tracks I 
> allocated, and a day or two later the job started bombing with a B37-04.
> 
> Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
> SPACE=(TRK,(9000,1000)). That seemed to work for a whole week, but I just 
> noticed that something, somewhere, has released extra space AGAIN; 3.4 tells 
> me it's now 1960 tracks and 83%. The job isn’t bombing yet; some time later 
> in the year I'm guessing it's going to.
> 
> Pardon my frustration: WHAT THE HECK IS GOING ON? Why does it keep releasing 
> space although I never specified RLSE? The sysprog doesn't know either - but 
> he's an external contractor who just took over the system a few months ago 
> and if it's something simple he may not be aware yet of ... I dunno, 
> something in SMS maybe?
> 
> Some wrinkles that may or may not be relevant:
> 
> 1) The dataset is written using a REXX exec that calculates the DSN by 
> reference to the current year. This relieves folks from having to update the 
> JCL every year, but maybe something about the way the exec does the allocate 
> is causing the problem? I'm guessing not, because as far as I now this job 
> has run correctly for years. But just in case:
> 
> "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
> 
> "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"
> 
> 2) I don't know anything about SMS, but could something there be releasing 
> space?
> 
> 3) What IS extended PS, anyway? I'm told it allows more than 16 extents, but 
> a) how many more? And b) how else is it different?
> 
> 4) I allocated the dataset each time using not batch JCL but 3.2 ... 
> expecting there's no difference.
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* Law #6 of combat operations: If it's stupid but it works, it isn't stupid. 
> */
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Something keeps releasing space on a large (annual) DS

[Bob Bridges]

I'm not a sysprog (just a security geek), but I can at least allocate datasets, 
and at the start of this year it fell to me to allocate a new dataset in which 
are logged all changes made in the security system.  Past year's log are in the 
12000-track range, so I started with a smaller allocation while I took the time 
to talk to our sysprog about space requirements.  It's populated from a daily 
production job, by the way.

When I re-allocated it, on his advice I tried a multi-volume and extended 
allocation (PS-E).  Almost immediately the job started bombing, claiming that 
the first four volumes it tried didn't have the necessary space to add an 
extension.  The sysprog is puzzled - says it should have looked in volumes that 
DO have the space, not the ones that don't.

Second attempt (I don't count the temporary smaller allocation) I kept PS-E but 
dropped the multi-volume requirement.  I've never done one of those anyway, and 
don't trust 'em.  The system promptly dropped the extra tracks I allocated, and 
a day or two later the job started bombing with a B37-04.

Third attempt: Forget PS-E (I'm unfamiliar with that too) and just used 
SPACE=(TRK,(9000,1000)).  That seemed to work for a whole week, but I just 
noticed that something, somewhere, has released extra space AGAIN; 3.4 tells me 
it's now 1960 tracks and 83%.  The job isn’t bombing yet; some time later in 
the year I'm guessing it's going to.

Pardon my frustration: WHAT THE HECK IS GOING ON?  Why does it keep releasing 
space although I never specified RLSE?  The sysprog doesn't know either - but 
he's an external contractor who just took over the system a few months ago and 
if it's something simple he may not be aware yet of ... I dunno, something in 
SMS maybe?

Some wrinkles that may or may not be relevant:

1) The dataset is written using a REXX exec that calculates the DSN by 
reference to the current year.  This relieves folks from having to update the 
JCL every year, but maybe something about the way the exec does the allocate is 
causing the problem?  I'm guessing not, because as far as I now this job has 
run correctly for years.  But just in case:

  "ALLOC DDN(CHG$$OT) DSN('') MOD CATALOG REUSE",
  "SPACE(300,30) CYLINDERS RECFM(V,B) LRECL(304) BLKSIZE(27998)"

2) I don't know anything about SMS, but could something there be releasing 
space?

3) What IS extended PS, anyway?  I'm told it allows more than 16 extents, but 
a) how many more? And b) how else is it different?

4) I allocated the dataset each time using not batch JCL but 3.2 ... expecting 
there's no difference.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #6 of combat operations:  If it's stupid but it works, it isn't stupid. 
*/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[Joe DeChirico]

All,

Thanks for all the responses, it appears that there was garbage in included 
module, once I removed if from inline and used a ++MOD(VSHMNTSK) 
TXLIB(ZPROTOBJ) . the problem went away.

Joe DeChirico

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[Binyamin Dissen]

On Wed, 21 Feb 2024 07:00:23 -0600 Joe DeChirico
<05694ada0b0a-dmarc-requ...@listserv.ua.edu> wrote:

:>I have been trying to package a ptf using smpe and appear to be missing 
something, I have attached the job that I submitting Can anyone give me some 
idea about what I am doing wrong?

JCL error?

SMP abend?

SMP messages?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[Paul Gilmartin]

On Wed, 21 Feb 2024 13:07:24 +, Chalk, Shelia  wrote:

>Get rid of the numbers on the right hand side.
>
Why?  Those are almost standard..

>...  Then resubmit.  What error message are you getting?
>
Yes.

I prefer to rely on DDDEFs rather than DD in the JCL.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[David Spiegel]

Hi Joe,
Please list the messages too.

Regards,
David

On 2024-02-21 08:00, Joe DeChirico wrote:

Hi,

I have been trying to package a ptf using smpe and appear to be missing 
something, I have attached the job that I submitting Can anyone give me some 
idea about what I am doing wrong?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[Kurt Quackenbush]

> I have been trying to package a ptf using smpe and appear to be missing 
> something, I have attached the job that I submitting Can anyone give me some 
> idea about what I am doing wrong?

Upon a quick glance nothing is obviously wrong with your JCL.  If you show us 
the error messages or describe what you perceive to be wrong then perhaps 
someone can help.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP Packaging a PTF module replacement.

[Chalk, Shelia]

Get rid of the numbers on the right hand side.  Then resubmit.  What error 
message are you getting?

Thanks  

Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
DeChirico
Sent: Wednesday, February 21, 2024 7:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] SMP Packaging a PTF module replacement.

Please Note: This email is from an [EXTERNAL] sender. Do not click on links or 
attachments unless you expect them from the sender and know the content is 
safe. Please contact the Service Desk if you have any concerns regarding this 
message.



Hi,

I have been trying to package a ptf using smpe and appear to be missing 
something, I have attached the job that I submitting Can anyone give me some 
idea about what I am doing wrong?



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

SMP Packaging a PTF module replacement.

[Joe DeChirico]

Hi,

I have been trying to package a ptf using smpe and appear to be missing 
something, I have attached the job that I submitting Can anyone give me some 
idea about what I am doing wrong?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
//J02RECV  JOB  MSGLEVEL=(1,1),MSGCLASS=A,NOTIFY=
JOB09004 
//  
 
//* 
 
//* Change the next line to specify the library where JXXSETS resides   
 
// JCLLIB  ORDER=ZXP.INSTALL.JCL
 
//* 
 
//  
 
// INCLUDE MEMBER=JXXSETS   
 
//**
 
//* 
 
//SMP  EXEC PGM=GIMSMP,REGION=0M
 
//SMPCSI   DD DSN=,DISP=SHR 
 
//SMPLOG   DD SYSOUT=*  
 
//SMPOUT   DD SYSOUT=*  
 
//SMPRPT   DD SYSOUT=*  
 
//SMPLIST  DD SYSOUT=*  
 
//SMPTLIB  DD UNIT=,VOL=SER=,SPACE=(CYL,(10,10,100))
 
//SMPPTS   DD DISP=SHR,DSN=  
 
//SMPPTFIN DD DATA,DLM=@@   
 
++PTF(ZXP8400) .
00010003 
++VER(Z038) FMID(VZXP840) . 
00041800 
++MOD(ZXPSNAPD) .   
00042004 
 ESDZXPSNAPD
0001 
 TXT¥  \ {0  ^õ  ^^ ª D ¥   ì D   ì0Dàì\  ìÓ  ìÓ 
µ¥ \  J Òì2 
 TXTD y\  åØ{øå {øå {øå {à    0 À    i 
åØ{øå0{ 0003 
 TXT   øK } Dç¥ñ  & }UK J ì\  ì\\@ìØ\y&ØJ j d{å A ì D<  
ì0D&0004 
 TXT   yì\  ìÓ  ìÓ µ¥ \  j&°d¯K±° Fµ  °°ì Dè 
\Dqì0Dìy   åØA å A 0005 
 TXT   \å A å {Ü     0 H    i åØA å0{M \°  0°ì&0\ 
K \ Dø0006 
 TXTo d{ì°d¯K °°D*nOJèåØBÎnCJèåØBMnSJèåØA>K 
°°D-×|°°åØA<  ì 0007 
 TXT   &D x8  ì\  ìÓ  ìÓ ö¥ \  4  K °°DÀj d{å\AàK 
°°D*nNJíåØ0008 
 TXT   hAþ(\C ì d¯nYJîåØA8ì J & °©ì J & °½oØ°½  °©ì 
J & °öoØ°ö &0009 
 TXT   {°ö Ïäø°^  kç&   k   o#  oØ  &   &&  âø 
?!øDÇâø°^å0BÀ0010 
 TXT   8ì J & °¯ì Jà& °{oØ°{K °DJ<ì J & °öoØ°ö 
Ïäø°^  °¯¥   é k-0011 
 TXTk   &   k   º   oÌ  oý  &   ºà  âø¥
?!øDÇâø°^nNJí0012 
 TXT   ÇåØBø(\Cµ 6å0AàK °°D*j d{å B}nNJíåØB°(\C ì d¯K 
JØG   JØm00013 
 TXT   µ  o     ° &   åØB{K °°D%o 
d{nNJíåØB}(\Cµå0AàK °°0014 
 TXT   QD*j d{å\C nNJíåØBÓ(\C ì d¯K JhG   Jh  ° & 
mÙd{nN0015 
 TXTJíåØC (\Cµå0Aà&\JÈP °Q°Q  °8P"k   k   k    
\°Q&\   \0016 
 TXT   çDa&\  K   DaK  ÎDØm"  ì\  ìÓ  ìÓ %x   ¥ \ &0°}& 
°Mß0DÀå}0017 
 TXT   ØCª° }Y     0 J    i   ì\JÈ Ú&\JÌ  jµP"k    
\°Q&\0018 
 TXT   ½  ì\  ìÓ  ìÓ %x   ¥ \ &0°}& °M  åØC4° }Y     0 K 
   i   0019 
 TXT   0ì\JÌ Ú  
0020 
 TXT
0021 
 TXT   °   ÊF1SA   °
0022 
 TXT   øLOGSNAPDLOGSNAPD LOGSNAPD.SNAPSOUT  
0023 
 TXT   q
0024 
 TXT   }
0025 
 TXT   & #Ø-   À Ìý 
0026 
 TXT   h   m
0027 
 TXT   µ   8d   è   LOGSNAPD
0028 
 TXT   Q   Ê   'DCBE d  
0029 
 TXT   ʱ   Ø   
0030 
 RLD

Re: April Hillgang Meeting

[Neale Ferguson]

https://download.sinenomine.net/hillgang/hillgang-2024-01/Hillgang%202024-01v4.pdf

$*@#*! 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

April Hillgang Meeting

[Neale Ferguson]

With URL to flyer...

The next meeting of “Hillgang”: the DC, Virginia, and Maryland z/VM and Linux 
on z User Group will be held on 18 April 2024.
https://download.sinenomine.net/hillgang/hillgang-2024-01/Hillgang 2024-01v4.pdf
Location:
Broadcom/VMware
12100 Sunset Hills Rd
4th FL
Reston VA 20190

Time:
8am until ~1pm Eastern time zone

Agenda:
Becoming IBM – Bill Bitner
Velocity Software’s Resource Manager zVRM – Barton Robinson
Snack break/TechBytes – Quick Announcements
What You Can Do With LinuxONE That You Can’t Do With x86 – Pedro Acosta, IBM
LinuxONE at Citi – Kurt Acker and Len Santalucia

Breakfast brought to you by Velocity Software.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN