Re: Documentation RCF entry and tracking proposal on idea portal - please read and vote

[Farley, Peter]

Thank you for that link Ann, but I quote from the page you sent:

"You will not receive a direct response to your feedback."

Why not?  Wouldn't a mechanism to engage in dialog about the documentation 
error(s)/omission(s) be far more customer-friendly and responsive to customer 
perceptions?

Surely the volume of documentation suggestions/comments is not large enough 
(even world-wide) for it to be cost-prohibitive for IBM to provide a dialog 
mechanism of some kind and a team that responds in dialog with the customer, 
even if it is only a simple message board.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ann 
DePaolo
Sent: Thursday, May 18, 2023 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Documentation RCF entry and tracking proposal on idea portal - 
please read and vote

Hello Peter,

For information on how to leave feedback for IBM product documentation, visit: 
https://urldefense.com/v3/__https://www.ibm.com/docs/en/about?topic=how-provide-feedback__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!MQTQaSBasGKRH1dMI40r-PHLzY7IKeOeAUqwQMNodxrx9x6Y09h-ASEYtfWkDUG8YCzmgwz8rrHe-_RD0w$
 .

Thank you,
Ann DePaolo
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Documentation RCF entry and tracking proposal on idea portal - please read and vote

[Ann DePaolo]

Hello Peter,

For information on how to leave feedback for IBM product documentation, visit: 
https://www.ibm.com/docs/en/about?topic=how-provide-feedback.


Thank you,
Ann DePaolo

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

Re: ISPF HILITE Question

[Robert Prins]

On Thu, 18 May 2023 at 20:20, Steve Thompson  wrote:

> Or have I stumbled on a situation where ISPF and COBOL 6.x are
> not in synch?
>

This used to be the "normal" situation for PL/I, and with PL/I builtins
multiplying like rabbits, it may well be the case again. Ditto for COBOL...

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

ISPF HILITE Question

[Steve Thompson]

I have been chasing through a few IBM ISPF manuals and I am 
trying to figure out why, when HILITE is COBOL, certain words are 
"pink". Now I thought this was used to show a logic error, such 
as an "IF" with a missing "END-IF", or an extraneous "END-IF".


Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of 
one, but it is getting colored pink. Could this be because ISPF 
doesn't know about new functions in COBOL? In this case it is 
"BYTE-LENGTH" (because I need to know at execution time what the 
size of the named label is -- "Depending on" is being used).


Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are 
not in synch?


TIA,
Steve Thompson

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

Re: Typo in "Summary of changes"?

[Phil Smith III]

Paul Gilmartin wrote, in part:
>But I notice that in both XEDIT and Vim, Undo can
>leave a spurious memorandum of a change.

XEDIT has Undo? Since when? (No, it doesn't.) Did you mean the business where 
hitting ERASE EOF at the start of a line marks the MDT so XEDIT thinks the line 
has been changed?  Yeah, that's always been like that, and is a bit weird.

Just curious-when does it bite you? I have my DMSXUM that marks all changed 
lines so a SET DISPLAY shows only the changed ones, but for most folks, this 
would only matter in CMS UPDATE mode. So I'm not challenging it being 
weird/irritating, just curious when/how you even notice it! Maybe just if it's 
the ONLY thing you've done, and then PQUIT says 
DMSXSU577E File has been changed; type QQUIT to quit anyway
?


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

Re: VBS file read in windows - end of record issue

[Paul Gilmartin]

On Thu, 18 May 2023 11:37:18 -0500, Kirk Wolf wrote:
>
>To answer your other question (preserving SDW):  if you copy a RECFM=VBS 
>dataset using DCB=RECFM=U, you will get BDWs and SDWs.
> 
Yes.  I did that with REXX in an era when REXX supported nether
VBS nor U.  I first used a utility (REPRO, IIRC) to copy (overriden)
RECFM=U to RECFM=V, adding generated BDW/RDW in a
temp file, then using EXECIO.  REXX is better nowadays.  But
LRECL=X?

Yes.  But PDSE prohibits such overrides.  Why!?  (I suspect some
limitation of NOTE/POINT.)

Beware FTP!  I've fount it undoes allocation overrides rather than
using QSAM with allocated attributes.

What's recommended for continuous stream data, as for lab
instruments?

o RECFM=U?

o RECFM=VBS,LRECL=X?

o zFS?

o Other (specify)?

-- 
gil

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

Re: VBS file read in windows - end of record issue

[Kirk Wolf]

I apologize if this has already been covered on this thread, but using LF/CRLF 
etc on a VBS file will result in problems with binary records since they could 
easily contain a line terminator.

To answer your other question (preserving SDW):  if you copy a RECFM=VBS 
dataset using DCB=RECFM=U, you will get BDWs and SDWs.

Kirk Wolf
Dovetailed Technologies

PS>  Co:Z SFTP and Co:Z Dataset Pipes have options for converting z/OS records 
like RECFM=VBS into streams of bytes with various terminators, like  cr, crlf, 
rdw, l4 (4 byte length prefix), mfrdw (Microfocus), an aribtrary hex separator, 
or no separators.   For binary records you would want to use rdw, l4, or mfrdw 
options.  You can download and use it under the terms of our free Community 
License.
https://coztoolkit.com/docs/dspipes/dsp-ref_fromdsn.html


You might also consider writing a z/OS program yourself that converts RECFM=VBS 
into a simple length prefixed stream.  If you are a little comfortable with 
Java, the com.ibm.jzos.RecordReader class makes that super simple.

On Mon, May 15, 2023, at 11:20 PM, Prashant Joshi wrote:
> Thank for your response, Paul.
> 
> I agree, CRLF irrelevant to binary files. Surprisingly, only after using CRLF 
> option, I get those binary records in proper record length.
> I tried to force it to U format but did not work for m. I will try again with 
> different methods.
> 
> I can preserve RDW and BDW. How to preserve SDW? I did not see mention of SDW 
> in these options. May be SDW is the key to maintain record length.
> 
> Thank you,
> Prashant Joshi
> Mainframe Architect
> +91 9743 440 503 (Mobile) 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Paul Gilmartin
> Sent: Tuesday, May 16, 2023 1:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: VBS file read in windows - end of record issue
> 
> On Mon, 15 May 2023 18:54:40 +, Prashant Joshi  wrote:
> >...
> >For some files, when I transfer using IND$FILE (option 6) using Binary and 
> >CRLF option checked, I gets record properly. But it does not work for every 
> >file. And due to different file sizes, IND$FILE may not be option for me.
> >
> CRLF should be irrelevant for binary files.
> 
> 
> >Need your help to find, what am I missing?
> >
> Allocate your data set overriding to RECFM=U.  Tne BDWs and SDWs should 
> appear ad data.
> 
> Transfer the file with a method that preserves those BDWs and SDWs.  (I don't 
> recommend
> IND$FILE.)
> 
> Decode the SDWs and translate to UTF-8  with your Python.
> 
> I hate EBCDIC!
> 
> --
> 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
> 

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

Re: VBS file read in windows - end of record issue

[Michael Oujesky]

Long time ago IFASMFDP had a default BLKSIZE of 
4096, but today uses SDB to match to device 
characteristics.  However, LRECL is set to 32767 
and SMF did write records that long.  At last 
check, still did use DCBE, so  features like LBI 
could not be used for it's output files.


Note that if you SMS compress the output file, 
BLKIZE becomes logical as the data is physically 
written full track (roughly 56K bytes).


Michael


At 10:09 AM 5/18/2023, Lennie Dymoke-Bradshaw wrote:


Radoslaw,

If you specify the LRECL and/or BLKSIZE in your 
program, then you can set a  value that appears 
to flout the JCL rules. For example it used to 
be that IFASMFDP wrote data sets with a BLKSIZE 
of 32767. I am unsure if it still does.


Lennie Dymoke-Bradshaw
https://rsclweb.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List 
 On Behalf Of Radoslaw Skorupka

Sent: 18 May 2023 10:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VBS file read in windows - end of record issue

Well, can you show me a JCL job to allocate such dataset?
My experience say that any attempt to create PS 
dataset with LRECL > ~32kB ends with JCL error 
and IEF638I JCL Reference clearly say that for 
non-VSAM dataset the maximum is 32760. For VSAM it is 32761.
"Additional Syntax" says it is possible to use 
LRECL=nK when n is up to 16,383. However 
it is possible only for ISO/ANSI V3 tapes.
And there is LRECL=X, which is applicable only 
to QSAM VS/VBS. It is not cheating in the 
meaning I provided earlier, but it is not quite simple dataset usage.



Note: despite of the above it is possible to 
allocate PS VBS file with LRECL=32767, but the 
LRECL cannot be specified in JCL. LIKE is the trick.



Regarding a little bit off-topic compressed extended format datasets:
system reports "legal" BLKSIZE 32760 (SDB was used). What's inside - it
is covered by media manager IMHO.


(irrelevant)
My local "cheating" definition used before: user creates
records/segments, *including* SDW. IMHO tools like File Manager allow
such cheating. However it is just track editing play, not dataset usage.


Regards
--
Radoslaw Skorupka
Lodz, Poland




W dniu 17.05.2023 o 21:14, Michael Oujesky pisze:
> Having read and written records longer than three MB, it is not
> "cheating". Especially with RMF 74.5 records with 59 "broken" (split)
> records to reassemble into one very long record. See the SMF manual on
> RMF record reassembly area.
>
> JCL allows LRECL=16384K.  And SMS compressed files write full tracks
> (roughly 56KB).
>
> Michael
>
> At 01:20 PM 5/17/2023, Radoslaw Skorupka wrote:
>> Content-Transfer-Encoding: 8bit
>>
>> Well, not really.
>> There is LRECL=X, but besides we have not very strict limitation of
>> LRECL. It is 32760 or 32767.
>> First value is limited by JCL syntax, but the second is available
>> when allocation PS using LIKE= keyword.
>> Of course one may automagically write segments with custom-created
>> SDWs, but I would call it cheating.
>>
>> BTW: The purpose of VBS was not veeery long record, but records
>> up to 32k, even on DASD with shorter track. Hint: the track is
>> natural limit of BLKSIZE. It is no longer important since 3380
>> (80's), because track size exceeded 32k.
>>
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>>
>>
>>
>>
>> W dniu 16.05.2023 o 18:52, Michael Oujesky pisze:
>>> Just another tidbit, but when combining the record segments, while
>>> the VBS architecture does not specify a maximum record length, you
>>> can expect the full records to be up to 16,777,215 (16384K - 1)
>>> bytes in length.
>>>
>>> Realizing that the RDW is actually a SDW.
>>>
>>> Michael
>>>
>>> At 01:26 AM 5/16/2023, Michael Stein wrote:
 On Tue, May 16, 2023 at 04:14:07AM +, Prashant Joshi wrote:
 >> Did you specify binary mode on the python open call? --

 > Yes. And I can read the data.

 How are you reading the data.  Assuming an open like:

 myfile = open("filename", "rb")

 You need to either read it all into memory:

 alldata = myfile.read()

 or read specific lengths which is messier as you need to read specific
 lengths, first 4 bytes for the RDW and then the length of the record
 in the RDW-4 (as you already read the RDW).

 The 4 byte RDW includes the length of the record in the first 2 bytes
 (bigendian order) and the spanning bits in the last 2 bytes.

 Either way you need to walk your way through the binary data, any code
 looking for CR or NL or space isn't correct.

 A description of VBS records formats:

 z/OS 2.4 DFSMS Using Data Sets SC23-6855-40
 
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf 




 pdf page 273 Variable-Length Record Formats
 (near bottom of page and continues on to more pages)

 > its just that I don't get proper end 

Re: VBS file read in windows - end of record issue

[Michael Oujesky]

See the references on XLRI.

This should be a good start - 
Processing 
Records Longer than 32 760 Bytes - IBM Documentation


This also might help - 
Additional 
syntax for LRECL=(bytes) - IBM Documentation


You will perhaps need to review transmittal modes in - 
z/OS: 
z/OS DFSMS Using Data Sets (ibm.com)


LRECL=16384K in JCL ends up providing a lrecl of 16384k-1, but guess 
the folks coding JCL interpretation thought 16384K was enough of a keyword.


LRECL=X gives you a lrecl of 32768 which appears to signal that SDW 
are present and that BFTEK=A (which doesn't support logical records 
longer than 32767) will not work to reassemble the logical 
record.  For such file, reassembly (de-segmentation) of the logical 
record is left to the application program.


Note that when working with records longer than 32767 the length of 
the record is now three bytes long (i.e. 16384K - 1). Also see DCB 
field DCBXLREC.


Michael


At 04:35 AM 5/18/2023, Radoslaw Skorupka wrote:

Content-Transfer-Encoding: 8bit

Well, can you show me a JCL job to allocate such dataset?
My experience say that any attempt to create PS dataset with LRECL > 
~32kB ends with JCL error and IEF638I
JCL Reference clearly say that for non-VSAM dataset the maximum is 
32760. For VSAM it is 32761.
"Additional Syntax" says it is possible to use LRECL=nK when 
n is up to 16,383. However it is possible only for ISO/ANSI V3 tapes.
And there is LRECL=X, which is applicable only to QSAM VS/VBS. It is 
not cheating in the meaning I provided earlier, but it is not quite 
simple dataset usage.



Note: despite of the above it is possible to allocate PS VBS file 
with LRECL=32767, but the LRECL cannot be specified in JCL. LIKE is the trick.



Regarding a little bit off-topic compressed extended format 
datasets: system reports "legal" BLKSIZE 32760 (SDB was used). 
What's inside - it is covered by media manager IMHO.



(irrelevant)
My local "cheating" definition used before: user creates 
records/segments, *including* SDW. IMHO tools like File Manager 
allow such cheating. However it is just track editing play, not dataset usage.



Regards
--
Radoslaw Skorupka
Lodz, Poland




W dniu 17.05.2023 o 21:14, Michael Oujesky pisze:
Having read and written records longer than three MB, it is not 
"cheating". Especially with RMF 74.5 records with 59 "broken" 
(split) records to reassemble into one very long record. See the 
SMF manual on RMF record reassembly area.


JCL allows LRECL=16384K.  And SMS compressed files write full 
tracks (roughly 56KB).


Michael

At 01:20 PM 5/17/2023, Radoslaw Skorupka wrote:

Content-Transfer-Encoding: 8bit

Well, not really.
There is LRECL=X, but besides we have not very strict limitation 
of LRECL. It is 32760 or 32767.
First value is limited by JCL syntax, but the second is available 
when allocation PS using LIKE= keyword.
Of course one may automagically write segments with custom-created 
SDWs, but I would call it cheating.


BTW: The purpose of VBS was not veeery long record, but 
records up to 32k, even on DASD with shorter track. Hint: the 
track is natural limit of BLKSIZE. It is no longer important since 
3380 (80's), because track size exceeded 32k.



--
Radoslaw Skorupka
Lodz, Poland




W dniu 16.05.2023 o 18:52, Michael Oujesky pisze:
Just another tidbit, but when combining the record segments, 
while the VBS architecture does not specify a maximum record 
length, you can expect the full records to be up to 16,777,215 
(16384K - 1) bytes in length.


Realizing that the RDW is actually a SDW.

Michael

At 01:26 AM 5/16/2023, Michael Stein wrote:

On Tue, May 16, 2023 at 04:14:07AM +, Prashant Joshi wrote:
>> Did you specify binary mode on the python open call? --

> Yes. And I can read the data.

How are you reading the data.  Assuming an open like:

myfile = open("filename", "rb")

You need to either read it all into memory:

alldata = myfile.read()

or read specific lengths which is messier as you need to read specific
lengths, first 4 bytes for the RDW and then the length of the record
in the RDW-4 (as you already read the RDW).

The 4 byte RDW includes the length of the record in the first 2 bytes
(bigendian order) and the spanning bits in the last 2 bytes.

Either way you need to walk your way through the binary data, any code
looking for CR or NL or space isn't correct.

A description of VBS records formats:

z/OS 2.4 DFSMS Using Data Sets SC23-6855-40
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf 



pdf page 273 Variable-Length Record Formats
(near bottom of page and continues on to more pages)

> its just that I don't get proper end of 

Re: VBS file read in windows - end of record issue

[Lennie Dymoke-Bradshaw]

Radoslaw,

If you specify the LRECL and/or BLKSIZE in your program, then you can set a  
value that appears to flout the JCL rules. For example it used to be that 
IFASMFDP wrote data sets with a BLKSIZE of 32767. I am unsure if it still does.

Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 18 May 2023 10:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VBS file read in windows - end of record issue

Well, can you show me a JCL job to allocate such dataset?
My experience say that any attempt to create PS dataset with LRECL > ~32kB ends 
with JCL error and IEF638I JCL Reference clearly say that for non-VSAM dataset 
the maximum is 32760. For VSAM it is 32761.
"Additional Syntax" says it is possible to use LRECL=nK when n is up to 
16,383. However it is possible only for ISO/ANSI V3 tapes.
And there is LRECL=X, which is applicable only to QSAM VS/VBS. It is not 
cheating in the meaning I provided earlier, but it is not quite simple dataset 
usage.


Note: despite of the above it is possible to allocate PS VBS file with 
LRECL=32767, but the LRECL cannot be specified in JCL. LIKE is the trick.


Regarding a little bit off-topic compressed extended format datasets: 
system reports "legal" BLKSIZE 32760 (SDB was used). What's inside - it 
is covered by media manager IMHO.


(irrelevant)
My local "cheating" definition used before: user creates 
records/segments, *including* SDW. IMHO tools like File Manager allow 
such cheating. However it is just track editing play, not dataset usage.


Regards
-- 
Radoslaw Skorupka
Lodz, Poland




W dniu 17.05.2023 o 21:14, Michael Oujesky pisze:
> Having read and written records longer than three MB, it is not 
> "cheating". Especially with RMF 74.5 records with 59 "broken" (split) 
> records to reassemble into one very long record. See the SMF manual on 
> RMF record reassembly area.
>
> JCL allows LRECL=16384K.  And SMS compressed files write full tracks 
> (roughly 56KB).
>
> Michael
>
> At 01:20 PM 5/17/2023, Radoslaw Skorupka wrote:
>> Content-Transfer-Encoding: 8bit
>>
>> Well, not really.
>> There is LRECL=X, but besides we have not very strict limitation of 
>> LRECL. It is 32760 or 32767.
>> First value is limited by JCL syntax, but the second is available 
>> when allocation PS using LIKE= keyword.
>> Of course one may automagically write segments with custom-created 
>> SDWs, but I would call it cheating.
>>
>> BTW: The purpose of VBS was not veeery long record, but records 
>> up to 32k, even on DASD with shorter track. Hint: the track is 
>> natural limit of BLKSIZE. It is no longer important since 3380 
>> (80's), because track size exceeded 32k.
>>
>>
>> -- 
>> Radoslaw Skorupka
>> Lodz, Poland
>>
>>
>>
>>
>> W dniu 16.05.2023 o 18:52, Michael Oujesky pisze:
>>> Just another tidbit, but when combining the record segments, while 
>>> the VBS architecture does not specify a maximum record length, you 
>>> can expect the full records to be up to 16,777,215 (16384K - 1) 
>>> bytes in length.
>>>
>>> Realizing that the RDW is actually a SDW.
>>>
>>> Michael
>>>
>>> At 01:26 AM 5/16/2023, Michael Stein wrote:
 On Tue, May 16, 2023 at 04:14:07AM +, Prashant Joshi wrote:
 >> Did you specify binary mode on the python open call? --

 > Yes. And I can read the data.

 How are you reading the data.  Assuming an open like:

 myfile = open("filename", "rb")

 You need to either read it all into memory:

 alldata = myfile.read()

 or read specific lengths which is messier as you need to read specific
 lengths, first 4 bytes for the RDW and then the length of the record
 in the RDW-4 (as you already read the RDW).

 The 4 byte RDW includes the length of the record in the first 2 bytes
 (bigendian order) and the spanning bits in the last 2 bytes.

 Either way you need to walk your way through the binary data, any code
 looking for CR or NL or space isn't correct.

 A description of VBS records formats:

 z/OS 2.4 DFSMS Using Data Sets SC23-6855-40
 https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf
  


 pdf page 273 Variable-Length Record Formats
 (near bottom of page and continues on to more pages)

 > its just that I don't get proper end of reord. Hence every time I
 > read record, I get random record length (multiple records/half 
 records
 > combined)

 There aren't any "end of records" in a VBS file.  At the begining of
 the file you know you are at the start of a RDW (Well, BDW/RDW but I'm
 assuming the FTP removed the BDWs).

 You can find the next record by going the length specified in the RDW
 into the file -- that is the start of the next RDW. Continue until

Re: z/OSMF log size

[Allan Staller]

Classification: Confidential

Glad to be of help

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

[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.]

Thanks
I removed that, restarted IZUSVR1, and it seems to work.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: יום ה 18 מאי 2023 15:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Classification: Confidential

YUP!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 7:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

[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 found JVM_OPTIONS=-Djavax.net.debug=all in 
/global/zosmf/configuration/active_configuration.cfg
and in /global/zosmf/configuration/local_override.cfg

Could this be causing the excessive logging?

Gadi


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: יום ה 18 מאי 2023 14:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Classification: Confidential

1) try Sthe SPIN (JCL?) parameter. Possibly w/Free=close on the DD statement.
2) check the log or debug levels in IZUPRMxx.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OSMF log size

[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.]

Hi,
The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
million lines.

Can anyone suggest how to make it a bit smaller?

We are running under z/OS v2.3.

Thanks

Gadi


--
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 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

--
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

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

Re: Announcement Letters

[Mohammad Khan]

Reminds me of someone's email signature from a long time ago which went 
something like:

"No trees were cut down in sending this message but a large number of electrons 
were seriously inconvenienced."

mkk


On Wed, 17 May 2023 19:00:10 -0400, Bob Bridges  wrote:

>Wait, "improve life on the planet"?  Does someone argue that email harms the
>planet in some way?  That's a new one on me.
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>

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

Re: z/OSMF log size

[Gadi Ben-Avi]

Thanks
I removed that, restarted IZUSVR1, and it seems to work.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: יום ה 18 מאי 2023 15:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Classification: Confidential

YUP!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 7:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

[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 found JVM_OPTIONS=-Djavax.net.debug=all in 
/global/zosmf/configuration/active_configuration.cfg
and in /global/zosmf/configuration/local_override.cfg

Could this be causing the excessive logging?

Gadi


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: יום ה 18 מאי 2023 14:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Classification: Confidential

1) try Sthe SPIN (JCL?) parameter. Possibly w/Free=close on the DD statement.
2) check the log or debug levels in IZUPRMxx.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OSMF log size

[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.]

Hi,
The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
million lines.

Can anyone suggest how to make it a bit smaller?

We are running under z/OS v2.3.

Thanks

Gadi


--
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 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

--
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: z/OSMF log size

[Allan Staller]

Classification: Confidential

YUP!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 7:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

[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 found JVM_OPTIONS=-Djavax.net.debug=all in 
/global/zosmf/configuration/active_configuration.cfg
and in /global/zosmf/configuration/local_override.cfg

Could this be causing the excessive logging?

Gadi


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: יום ה 18 מאי 2023 14:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Classification: Confidential

1) try Sthe SPIN (JCL?) parameter. Possibly w/Free=close on the DD statement.
2) check the log or debug levels in IZUPRMxx.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OSMF log size

[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.]

Hi,
The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
million lines.

Can anyone suggest how to make it a bit smaller?

We are running under z/OS v2.3.

Thanks

Gadi


--
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 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

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

Re: z/OSMF log size

[Gadi Ben-Avi]

I found JVM_OPTIONS=-Djavax.net.debug=all in 
/global/zosmf/configuration/active_configuration.cfg
and in /global/zosmf/configuration/local_override.cfg

Could this be causing the excessive logging?

Gadi


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: יום ה 18 מאי 2023 14:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Classification: Confidential

1) try Sthe SPIN (JCL?) parameter. Possibly w/Free=close on the DD statement.
2) check the log or debug levels in IZUPRMxx.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OSMF log size

[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.]

Hi,
The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
million lines.

Can anyone suggest how to make it a bit smaller?

We are running under z/OS v2.3.

Thanks

Gadi


--
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 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: z/OSMF log size

[Gadi Ben-Avi]

Hi,
It says TRACE-N
The first STDOUT in the output also says TRACE-N
There are no TRACE or DEBUG options set in IZUPRM00.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: יום ה 18 מאי 2023 15:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

TRACE=Y in the STC JCL?

Dave Jousma



From: IBM Mainframe Discussion List  on behalf of 
Gadi Ben-Avi 
Date: Thursday, May 18, 2023 at 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OSMF log size
Thanks, But it looks like z/OSMF is writing to much information for normal 
operations. I'm looking for some kind of setting to fix it. Gadi -Original 
Message- From: IBM Mainframe Discussion List  
On Behalf ZjQcmQRYFpfptBannerStart CAUTION EXTERNAL EMAIL This message came 
from outside your organization.
DO NOT open attachments or click on links from unknown senders or unexpected 
emails.
ZjQcmQRYFpfptBannerEnd

Thanks,

But it looks like z/OSMF is writing to much information for normal operations.



I'm looking for some kind of setting to fix it.



Gadi



-Original Message-

From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron

Sent: יום ה 18 מאי 2023 09:42

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: z/OSMF log size



Sorry, I don't know the exact name for it, but there's some timed cut-off 
capability that can be used to archive or make cuts in some intervals.

Then, let them get actually archived into some archival product or datasets.



- KB



--- Original Message ---

On Thursday, May 18th, 2023 at 11:31 AM, Gadi Ben-Avi  wrote:





> Hi,

> The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
> million lines.

>

> Can anyone suggest how to make it a bit smaller?

>

> We are running under z/OS v2.3.

>

> Thanks

>

> Gadi

>

>

> --

> 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



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This 
e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.





--
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: z/OSMF log size

[Jousma, David]

TRACE=Y in the STC JCL?

Dave Jousma



From: IBM Mainframe Discussion List  on behalf of 
Gadi Ben-Avi 
Date: Thursday, May 18, 2023 at 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OSMF log size
Thanks, But it looks like z/OSMF is writing to much information for normal 
operations. I'm looking for some kind of setting to fix it. Gadi -Original 
Message- From: IBM Mainframe Discussion List  
On Behalf
ZjQcmQRYFpfptBannerStart
CAUTION EXTERNAL EMAIL
This message came from outside your organization.
DO NOT open attachments or click on links from unknown senders or unexpected 
emails.
ZjQcmQRYFpfptBannerEnd

Thanks,

But it looks like z/OSMF is writing to much information for normal operations.



I'm looking for some kind of setting to fix it.



Gadi



-Original Message-

From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron

Sent: יום ה 18 מאי 2023 09:42

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: z/OSMF log size



Sorry, I don't know the exact name for it, but there's some timed cut-off 
capability that can be used to archive or make cuts in some intervals.

Then, let them get actually archived into some archival product or datasets.



- KB



--- Original Message ---

On Thursday, May 18th, 2023 at 11:31 AM, Gadi Ben-Avi  wrote:





> Hi,

> The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
> million lines.

>

> Can anyone suggest how to make it a bit smaller?

>

> We are running under z/OS v2.3.

>

> Thanks

>

> Gadi

>

>

> --

> 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



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.





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

Re: z/OSMF log size

[Allan Staller]

Classification: Confidential

1) try Sthe SPIN (JCL?) parameter. Possibly w/Free=close on the DD statement.
2) check the log or debug levels in IZUPRMxx.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Thursday, May 18, 2023 1:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OSMF log size

[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.]

Hi,
The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
million lines.

Can anyone suggest how to make it a bit smaller?

We are running under z/OS v2.3.

Thanks

Gadi


--
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 the message: INFO IBM-MAIN

Re: Announcement Letters

[Radoslaw Skorupka]

W dniu 18.05.2023 o 01:00, Bob Bridges pisze:

Wait, "improve life on the planet"?  Does someone argue that email harms the
planet in some way?  That's a new one on me.


Well, it is quite old. People calculated carbon print (energy consumed) 
per each mail.
Of course approx. 2/3 of emails is spam and emailing is not the top 
energy consumer in IT, and...
...and it is really off-topic. However mail/carbon calculations are 
really many years old.
To be back to the topic: IBM actively talks about IBM z16 and so called 
sustainability. Indeed - the same number of similar loaded Linux images 
on z16 consume much less energy. Same for CPU-intensive applications and 
x86 vs POWER10.


(not my opinions, I'm just messenger here)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: VBS file read in windows - end of record issue

[Radoslaw Skorupka]

Well, can you show me a JCL job to allocate such dataset?
My experience say that any attempt to create PS dataset with LRECL > 
~32kB ends with JCL error and IEF638I
JCL Reference clearly say that for non-VSAM dataset the maximum is 
32760. For VSAM it is 32761.
"Additional Syntax" says it is possible to use LRECL=nK when n 
is up to 16,383. However it is possible only for ISO/ANSI V3 tapes.
And there is LRECL=X, which is applicable only to QSAM VS/VBS. It is not 
cheating in the meaning I provided earlier, but it is not quite simple 
dataset usage.



Note: despite of the above it is possible to allocate PS VBS file with 
LRECL=32767, but the LRECL cannot be specified in JCL. LIKE is the trick.



Regarding a little bit off-topic compressed extended format datasets: 
system reports "legal" BLKSIZE 32760 (SDB was used). What's inside - it 
is covered by media manager IMHO.



(irrelevant)
My local "cheating" definition used before: user creates 
records/segments, *including* SDW. IMHO tools like File Manager allow 
such cheating. However it is just track editing play, not dataset usage.



Regards
--
Radoslaw Skorupka
Lodz, Poland




W dniu 17.05.2023 o 21:14, Michael Oujesky pisze:
Having read and written records longer than three MB, it is not 
"cheating". Especially with RMF 74.5 records with 59 "broken" (split) 
records to reassemble into one very long record. See the SMF manual on 
RMF record reassembly area.


JCL allows LRECL=16384K.  And SMS compressed files write full tracks 
(roughly 56KB).


Michael

At 01:20 PM 5/17/2023, Radoslaw Skorupka wrote:

Content-Transfer-Encoding: 8bit

Well, not really.
There is LRECL=X, but besides we have not very strict limitation of 
LRECL. It is 32760 or 32767.
First value is limited by JCL syntax, but the second is available 
when allocation PS using LIKE= keyword.
Of course one may automagically write segments with custom-created 
SDWs, but I would call it cheating.


BTW: The purpose of VBS was not veeery long record, but records 
up to 32k, even on DASD with shorter track. Hint: the track is 
natural limit of BLKSIZE. It is no longer important since 3380 
(80's), because track size exceeded 32k.



--
Radoslaw Skorupka
Lodz, Poland




W dniu 16.05.2023 o 18:52, Michael Oujesky pisze:
Just another tidbit, but when combining the record segments, while 
the VBS architecture does not specify a maximum record length, you 
can expect the full records to be up to 16,777,215 (16384K - 1) 
bytes in length.


Realizing that the RDW is actually a SDW.

Michael

At 01:26 AM 5/16/2023, Michael Stein wrote:

On Tue, May 16, 2023 at 04:14:07AM +, Prashant Joshi wrote:
>> Did you specify binary mode on the python open call? --

> Yes. And I can read the data.

How are you reading the data.  Assuming an open like:

    myfile = open("filename", "rb")

You need to either read it all into memory:

    alldata = myfile.read()

or read specific lengths which is messier as you need to read specific
lengths, first 4 bytes for the RDW and then the length of the record
in the RDW-4 (as you already read the RDW).

The 4 byte RDW includes the length of the record in the first 2 bytes
(bigendian order) and the spanning bits in the last 2 bytes.

Either way you need to walk your way through the binary data, any code
looking for CR or NL or space isn't correct.

A description of VBS records formats:

z/OS 2.4 DFSMS Using Data Sets SC23-6855-40
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf 



pdf page 273 Variable-Length Record Formats
(near bottom of page and continues on to more pages)

> its just that I don't get proper end of reord. Hence every time I
> read record, I get random record length (multiple records/half 
records

> combined)

There aren't any "end of records" in a VBS file.  At the begining of
the file you know you are at the start of a RDW (Well, BDW/RDW but I'm
assuming the FTP removed the BDWs).

You can find the next record by going the length specified in the RDW
into the file -- that is the start of the next RDW. Continue until
you've processed all the records.

More help will likely require you to show some code and/or data so
we can see what is going on...




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

Re: z/OSMF log size

[Gadi Ben-Avi]

Thanks,
But it looks like z/OSMF is writing to much information for normal operations.

I'm looking for some kind of setting to fix it.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron
Sent: יום ה 18 מאי 2023 09:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OSMF log size

Sorry, I don't know the exact name for it, but there's some timed cut-off 
capability that can be used to archive or make cuts in some intervals.
Then, let them get actually archived into some archival product or datasets.

- KB

--- Original Message ---
On Thursday, May 18th, 2023 at 11:31 AM, Gadi Ben-Avi  wrote:


> Hi,
> The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
> million lines.
> 
> Can anyone suggest how to make it a bit smaller?
> 
> We are running under z/OS v2.3.
> 
> Thanks
> 
> Gadi
> 
> 
> --
> 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

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

Re: z/OSMF log size

[kekronbekron]

Sorry, I don't know the exact name for it, but there's some timed cut-off 
capability that can be used to archive or make cuts in some intervals.
Then, let them get actually archived into some archival product or datasets.

- KB

--- Original Message ---
On Thursday, May 18th, 2023 at 11:31 AM, Gadi Ben-Avi  wrote:


> Hi,
> The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
> million lines.
> 
> Can anyone suggest how to make it a bit smaller?
> 
> We are running under z/OS v2.3.
> 
> Thanks
> 
> Gadi
> 
> 
> --
> 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

z/OSMF log size

[Gadi Ben-Avi]

Hi,
The size of the STDOUT output in our z/OSMF started task IZUSVR1 is over 13 
million lines.

Can anyone suggest how to make it a bit smaller?

We are running under z/OS v2.3.

Thanks

Gadi


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