Re: RMF III issue

2014-12-16 Thread Shane Ginnane
On Tue, 16 Dec 2014 13:54:16 +0800,Jason Cai wrote:

> Sometime if we have some problem,we will send our RMF III vsam file to IBM 
> lab,IBM lab could explore the RMF iii VSAM file on their system. 
> Because we always backup our production RMF iii VSAM file,we also want to 
> explore this RMF  Monitor (ISPF Application) on the test system. 
> We couldn't explore the production RMF monitor on the test system,but why IBM 
> lab could do it? 

Read the RMF Users Guide.

Shane ...

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread nitz-...@gmx.net
>  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 
>  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL 
> SUBPARAMETER OF THE DCB FIELD
> Why is this considered an error?
> 
> In fact, 32761 is accepted; 32762 causes the error.  On what rationale is 
> this based?
> The same limts appear to apply to RECFM=VB.
> I haven't tried OPENing any such data set.

The explanation I came up with when I tested boundary conditions () was 
that 32767 is the maximum allowed for fixed records. And that length was 
determined by DASD geometry (in the past). A variable length record always has 
a length field preceding the actual record data. And since this is blocked, you 
also need length for the block descriptor. These two make up the 6 byte that 
you cannot specify for lrecl without exceeding geometry. I haven't tested (or 
if I did, I forgot the results) if it makes a difference when you use 
RECFM=V(S). The layout is described somewhere in SC26-7410 Using data sets.

Barbara

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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Kjell Holmborg
You may also use FileAid if you have that installed instead of FileManager. 

/Kjelle

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread R.S.

W dniu 2014-12-16 o 08:18, Paul Gilmartin pisze:

I get:

  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767

   STMT NO. MESSAGE
  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL 
SUBPARAMETER OF THE DCB FIELD

Why is this considered an error?

In fact, 32761 is accepted; 32762 causes the error.  On what rationale is this 
based?
The same limts appear to apply to RECFM=VB.
I haven't tried OPENing any such data set.

(I like to test boundary conditions.)


I don't know what the rationale is (is any at all?), but I know the 
following:
a) official documentations says you can specify 1 to 32760 for PS and 1 
to 32761 for VSAM (ES, KS, RR)
b) you can use PS RECFM=VBS,LRECL=32767, but you cannot specify the 
LRECL on DD.
c) you can also use LRECL=X for PS V(B)S , but I have never seen it in 
use. X means LRECL>32760.
d) to allocate first new PS dataset with LRECL=32676 a trick is needed. 
Later you can use LIKE.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.



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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Martin Packer
On VSAM I suspect it's 32K-7 bytes. The 7 for a CIDF (for the CI) and a 
RDF (for the one record you could stuff into a 32K CI).

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "R.S." 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   16/12/2014 11:11
Subject:Re: RECFM=VBS,LRECL=32767?
Sent by:IBM Mainframe Discussion List 



W dniu 2014-12-16 o 08:18, Paul Gilmartin pisze:
> I get:
>
>   6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767
>
>STMT NO. MESSAGE
>   6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE 
LRECL SUBPARAMETER OF THE DCB FIELD
>
> Why is this considered an error?
>
> In fact, 32761 is accepted; 32762 causes the error.  On what rationale 
is this based?
> The same limts appear to apply to RECFM=VB.
> I haven't tried OPENing any such data set.
>
> (I like to test boundary conditions.)

I don't know what the rationale is (is any at all?), but I know the 
following:
a) official documentations says you can specify 1 to 32760 for PS and 1 
to 32761 for VSAM (ES, KS, RR)
b) you can use PS RECFM=VBS,LRECL=32767, but you cannot specify the 
LRECL on DD.
c) you can also use LRECL=X for PS V(B)S , but I have never seen it in 
use. X means LRECL>32760.
d) to allocate first new PS dataset with LRECL=32676 a trick is needed. 
Later you can use LIKE.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. 
If you are not the intended addressee of this e-mail or the employee 
authorized to forward it to the addressee, be advised that any 
dissemination, copying, distribution or any other similar activity is 
legally prohibited and may be punishable. If you received this e-mail by 
mistake please advise the sender immediately by using the reply facility 
in your e-mail software and delete permanently this e-mail including any 
copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl 
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego 
Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 
526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy 
mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.


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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread R.S.

W dniu 2014-12-16 o 12:13, Martin Packer pisze:

On VSAM I suspect it's 32K-7 bytes. The 7 for a CIDF (for the CI) and a
RDF (for the one record you could stuff into a 32K CI).

Please, note the VSAM can have SPANNED records, longer than 32k. The 
limit is CA size minus CIDFs and RDFs.

So, I couldn't name it "rationale" or my English is poor. ;-)


Regards

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.



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


Re: ftp rdw

2014-12-16 Thread Jantje.
On Mon, 15 Dec 2014 07:35:44 -0600, Paul Gilmartin  wrote:

>>
>Are you using TRANSMIT or AMATERSE on MVS/380?  I had
>thought they were relatively new, probably licensed program
>products, and not available on OS/380.

I have used both on the well and duly licensed and paid-for z/OS on our company 
mainframe.

Never touched OS/380...

Cheers,

Jantje.

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


Re: ftp rdw

2014-12-16 Thread John McKown
On Mon, Dec 15, 2014 at 10:04 PM, Paul Edwards  wrote:

> >> I wish to distribute VB files (developed on MVS/380) via PC,
> >> with z/OS as a target. I don't want BDW, just the RDW format
> >> that ftp produces. I'm very happy with the RDW format that
> >> IBM's ftp produces, I just want it to be reversible.
>
> > STRU R is reversible; RDW isn't.  For your objective, the remaining
> > chore would be to synthesize STRU R on OS 380.
>
> I now have the test results from STRU R, and here is
> what it looks like:
>
> 00  C8859393 9640A388 859985FF 01C69693  Hello there..Fol
> 10  92A2FF01 FF02ks
>
> That is not even close to the RDW format that IBM
> provides. I have based PDPCLIB around IBM's RDW
> format.
>
> That STRU R format also doesn't allow data with x'ff'
> in it. The RDW format does.
>

​STRU R is_can_ transmit a x'FF'. x'FF' is to STRU R what \ is to a C
compiler. It is an "escape" byte which says to treat the _next_ ​byte
specially. In particular, a x'FF' followed by a second x'FF' represents a
single x'FF'. A x'FF' followed by a x'01' specifies "end of logical
record", followed by a x'02' specifies "end of file", and by a x'03'
specified "end of record & file". I guess that anything else (x'04'..x'FE')
after an x'FF' is a protocol error.

ref: https://www.ietf.org/rfc/rfc959.txt on page 21 (this is a single web
page, but formatted with page headers and footers for printing)



In a record structured file EOR and EOF will each be indicated by a
two-byte control code.  The first byte of the control code will be all
ones, the escape character.  The second byte will have the low order
bit on and zeros elsewhere for EOR and the second low order bit on for
EOF; that is, the byte will have value 1 for EOR and value 2 for EOF.
EOR and EOF may be indicated together on the last byte transmitted by
turning both low order bits on (i.e., the value 3).  If a byte of all
one was intended to be sent as data, it should be repeated in the
second byte of the control code.





​​


>
> I am not interested in BDWs etc. I consider that IBM's
> RDW option is an excellent choice for variable-lengthed
> binary records. It produces a V-format file that can be
> processed by a C program. The C program is expected
> to understand what an RDW is (but not BDW etc). I
> consider this to be logical and neat, and all I am after
> is for the RDW option to be reversible so that F, V and
> U files can all be transferred simply from mainframe
> to PC and back.
>
> BFN. Paul.
>
>
-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: CALL vs. CEEPCALL, any reason not to use the later?

2014-12-16 Thread Peter Relson
>The "if you wish" is because it appears IBM never 
>set any standard conventions for who is responsible 
>for preserving ARs, 

I hope no one else feels this way. It is not true.

For example, in the assembler services guide, linkage conventions section:

Unless otherwise defined by the individual interface, the calling program 
should expect, upon return, that 
The low halves (Bits 32-63) of GPRs 2 through 13 are unchanged 
The high halves (Bits 0-31) of GPRs 2 through 14 are unchanged 
ARs 2 through 13 are unchanged 
FPRs 8 through 15 are unchanged; The Floating Point Control (FPC) Register 
is unchanged with the exception of two fields: the IEEE exception flags 
and the data exception code (DXC). 

Peter Relson
z/OS Core Technology Design

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


Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-16 Thread Peter Relson
>Try to avoid making HC sending so much 
>informational/advisory/recommendational/etc. 
>stuff, that nobody pays attention anymore.

Can you be more specific? What stuff do you feel HC is 
advising/recommending that "nobody pays attention" to?
Many clean up their systems specifically so that they are in accordance 
with the recommendations so that any new "exception" is unexpected and 
therefore warrants attention.

Do you not agree with the recommendations that are in the books? Which 
ones? HC rarely advises/recommends on its own; typically it is helping you 
to get to the position recommended in the books.

Peter Relson
z/OS Core Technology Design

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Elardus Engelbrecht
Paul Gilmartin wrote:

>I get:
> 6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 
>  STMT NO. MESSAGE 
>  
> 6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL 
> SUBPARAMETER OF THE DCB FIELD
>Why is this considered an error?

I am still finding it 'Weird', but it is WAD and for backward compatibility or 
for possible max blocksize to be used. What dataset (VSAM, PS, PDS, OMVS, etc.) 
are you using?

>In fact, 32761 is accepted; 32762 causes the error.  On what rationale is this 
>based? The same limts appear to apply to RECFM=VB. I haven't tried OPENing any 
>such data set.

Ok. 32767 is x'7FFF'. I suspect it is something about record length and 
probably something about ability to store a record length in the first 4 bytes.

Granted, for SMF, I cannot use 32767 in JCL, but had to use a lower number 
(32760 - x'7FF8'), but IFASMFDP will change it to 32767 anyways.

It is one of the Big Blue mysteries... ;-D

Groete / Greetings
Elardus Engelbrecht

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


Re: ftp rdw

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 12:46 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 15 Dec 2014 22:24:28 -0600, Paul Edwards wrote:
>
> >> It produces a V-format file that can be
> >> processed by a C program.
> >
> >As an example, I want to be able to transmit an
> >SMF file (which I believe contains binary data) to
> >the PC, and then have a PC program to process
> >the SMF file. The PC program must handle the
> >RDW itself, but that's all.
> >
> I believe that is even RECFM=VBS.  Does FTP RDW
> do something reasonable with the spanning?
>

​Each segment comes in separately, just as it is on the file. FTP does not
reassemble a spanned record into a single record. So your code must
reassemble the entire record from the segments. I have C code which does
this. If you (or others) would like to look at it, it is available as a
"gist" on GitHub via the URL:
https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b
​
​Despite its being designed to run under z/OS, it will compile using gcc on
Linux. I don't do Windows programming.​ I don't contend that it is the best
code in the world. But it worked in my minor testing.



>
> >IBM's ftp rdw is an excellent file format.
> >
> >Note that the PC program that handles the SMF
> >records can also be uploaded to the mainframe
> >and it continues to work, at least if you are using
> >PDPCLIB as your C library.
> >
> And it handles the spanned records reasonably?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: ftp rdw

2014-12-16 Thread David Crayford

On 16/12/2014 9:13 PM, John McKown wrote:

On Tue, Dec 16, 2014 at 12:46 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On Mon, 15 Dec 2014 22:24:28 -0600, Paul Edwards wrote:


It produces a V-format file that can be
processed by a C program.

As an example, I want to be able to transmit an
SMF file (which I believe contains binary data) to
the PC, and then have a PC program to process
the SMF file. The PC program must handle the
RDW itself, but that's all.


I believe that is even RECFM=VBS.  Does FTP RDW
do something reasonable with the spanning?


​Each segment comes in separately, just as it is on the file. FTP does not
reassemble a spanned record into a single record. So your code must
reassemble the entire record from the segments. I have C code which does
this. If you (or others) would like to look at it, it is available as a
"gist" on GitHub via the URL:
https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b
​


I don't like the look of that unchecked malloc!


​Despite its being designed to run under z/OS, it will compile using gcc on
Linux. I don't do Windows programming.​ I don't contend that it is the best
code in the world. But it worked in my minor testing.




IBM's ftp rdw is an excellent file format.

Note that the PC program that handles the SMF
records can also be uploaded to the mainframe
and it continues to work, at least if you are using
PDPCLIB as your C library.


And it handles the spanned records reasonably?

-- 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: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-16 Thread Vernooij, CP (ITOPT1) - KLM
My answer was a general personal opinion, to keep HC warn about situations that 
really need investigation and possibly correction. It was in reaction to the 
suggestion to also make HC distribute a recommandation to remove from LNKLSTxx. 
In my opinion, the value of HC can be kept high, if it does what the name says, 
check the health of the system and report on 'unhealty' situations. I 
understand from your explanation that using LNKLSTxx is a perfectly valid 
construction, with an alternative for those who need it, but there is no need 
to change and therefor no need for HC to report about it.

Kees.


Van: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] namens Peter 
Relson [rel...@us.ibm.com]
Verzonden: dinsdag 16 december 2014 13:59
Aan: IBM-MAIN@LISTSERV.UA.EDU
Onderwerp: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

>Try to avoid making HC sending so much
>informational/advisory/recommendational/etc.
>stuff, that nobody pays attention anymore.

Can you be more specific? What stuff do you feel HC is
advising/recommending that "nobody pays attention" to?
Many clean up their systems specifically so that they are in accordance
with the recommendations so that any new "exception" is unexpected and
therefore warrants attention.

Do you not agree with the recommendations that are in the books? Which
ones? HC rarely advises/recommends on its own; typically it is helping you
to get to the position recommended in the books.

Peter Relson
z/OS Core Technology Design

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: ftp rdw

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 7:17 AM, David Crayford  wrote:

> On 16/12/2014 9:13 PM, John McKown wrote:
>
>> On Tue, Dec 16, 2014 at 12:46 AM, Paul Gilmartin <
>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>
>>  On Mon, 15 Dec 2014 22:24:28 -0600, Paul Edwards wrote:
>>>
>>>  It produces a V-format file that can be
> processed by a C program.
>
 As an example, I want to be able to transmit an
 SMF file (which I believe contains binary data) to
 the PC, and then have a PC program to process
 the SMF file. The PC program must handle the
 RDW itself, but that's all.

  I believe that is even RECFM=VBS.  Does FTP RDW
>>> do something reasonable with the spanning?
>>>
>>>  ​Each segment comes in separately, just as it is on the file. FTP does
>> not
>> reassemble a spanned record into a single record. So your code must
>> reassemble the entire record from the segments. I have C code which does
>> this. If you (or others) would like to look at it, it is available as a
>> "gist" on GitHub via the URL:
>> https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b
>> ​
>>
>
> I don't like the look of that unchecked malloc!
>
>
​That was left as an exercise for the reader? . I'll fix it, thanks.​


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: ftp rdw

2014-12-16 Thread David Crayford
Sorry to be critical but you really do need to check the return value 
from malloc() and realloc(). I would also replace the ascending goto 
with a while loop. Other than that it looks good.


On 16/12/2014 9:13 PM, John McKown wrote:

On Tue, Dec 16, 2014 at 12:46 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On Mon, 15 Dec 2014 22:24:28 -0600, Paul Edwards wrote:


It produces a V-format file that can be
processed by a C program.

As an example, I want to be able to transmit an
SMF file (which I believe contains binary data) to
the PC, and then have a PC program to process
the SMF file. The PC program must handle the
RDW itself, but that's all.


I believe that is even RECFM=VBS.  Does FTP RDW
do something reasonable with the spanning?


​Each segment comes in separately, just as it is on the file. FTP does not
reassemble a spanned record into a single record. So your code must
reassemble the entire record from the segments. I have C code which does
this. If you (or others) would like to look at it, it is available as a
"gist" on GitHub via the URL:
https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b
​
​Despite its being designed to run under z/OS, it will compile using gcc on
Linux. I don't do Windows programming.​ I don't contend that it is the best
code in the world. But it worked in my minor testing.




IBM's ftp rdw is an excellent file format.

Note that the PC program that handles the SMF
records can also be uploaded to the mainframe
and it continues to work, at least if you are using
PDPCLIB as your C library.


And it handles the spanned records reasonably?

-- 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: ftp rdw

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 7:25 AM, David Crayford  wrote:

> Sorry to be critical but you really do need to check the return value from
> malloc() and realloc(). I would also replace the ascending goto with a
> while loop. Other than that it looks good.
>
>
​Not critical, helpful! I put in a check on the malloc(). It never occurred
to me that the realloc() could fail because it is only used to shrink the
existing allocation. I guess that I thought that shrinking was always an
"in place" operation.​

​I'll fix that too. ​

-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-16 Thread van der Grijn, Bart (B)
Peter, we've run into health checks that are not compatible with what we 
believe are reasonable settings. Some we've turned off, others we didn't want 
to turn off, but had to add steps to some of our processes to deal with them 
(steps that we feel hinder rather than help).
If you're interested in details, see PMRs 52015,082,000 (XCF_CF_STR_PREFLIST) 
and 91965 (USS_CLIENT_MOUNTS ) (the 2nd one is pretty old, not sure if it is 
still in the system, plus it was before they renumbered our branch, so it's 
likely ,800,000).

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Tuesday, December 16, 2014 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

>Try to avoid making HC sending so much 
>informational/advisory/recommendational/etc. 
>stuff, that nobody pays attention anymore.

Can you be more specific? What stuff do you feel HC is 
advising/recommending that "nobody pays attention" to?
Many clean up their systems specifically so that they are in accordance 
with the recommendations so that any new "exception" is unexpected and 
therefore warrants attention.

Do you not agree with the recommendations that are in the books? Which 
ones? HC rarely advises/recommends on its own; typically it is helping you 
to get to the position recommended in the books.

Peter Relson
z/OS Core Technology Design

--
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: ftp rdw

2014-12-16 Thread David Crayford

On 16/12/2014 9:32 PM, John McKown wrote:

On Tue, Dec 16, 2014 at 7:25 AM, David Crayford  wrote:


Sorry to be critical but you really do need to check the return value from
malloc() and realloc(). I would also replace the ascending goto with a
while loop. Other than that it looks good.



​Not critical, helpful! I put in a check on the malloc(). It never occurred
to me that the realloc() could fail because it is only used to shrink the
existing allocation. I guess that I thought that shrinking was always an
"in place" operation.​

​I'll fix that too. ​



I would have the client pass in a buffer and length and not do any heap 
allocation. There should be a max length that can be specified in a 
#define MAX_LRECL constant.


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


Re: ftp rdw

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 7:45 AM, David Crayford  wrote:

> On 16/12/2014 9:32 PM, John McKown wrote:
>
>> On Tue, Dec 16, 2014 at 7:25 AM, David Crayford 
>> wrote:
>>
>>  Sorry to be critical but you really do need to check the return value
>>> from
>>> malloc() and realloc(). I would also replace the ascending goto with a
>>> while loop. Other than that it looks good.
>>>
>>>
>>>  ​Not critical, helpful! I put in a check on the malloc(). It never
>> occurred
>> to me that the realloc() could fail because it is only used to shrink the
>> existing allocation. I guess that I thought that shrinking was always an
>> "in place" operation.​
>>
>> ​I'll fix that too. ​
>>
>>
> I would have the client pass in a buffer and length and not do any heap
> allocation. There should be a max length that can be specified in a #define
> MAX_LRECL constant.
>
>
​I guess, in that case, that the prototype would look something like:

void *vbsread(int fd, void *buffer, int buffer_length);​


​Is a MAX_LRECL really needed? Is a z/OS VB record _ever_ greater than
32767 bytes? Yes, I can see how somebody could write a program which
creates a data set containing VBS segments which, combined, would exceed
that limit. But using "normal" z/OS facilities, it would be difficult. And
I'd bet that even the venerable DFSORT would cough up hair balls trying to
process it. I need to read up on LRI, I guess.​


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: RMF III issue

2014-12-16 Thread Lizette Koehler
If you look at the manuals they can help you set up a process for post review 
on a different lpar.

Have you looked at the various options on the RMF ISPF Application? 

You can include dataset names in there.

You can also use the SMF records 70-79 to run batch RMF reports.

Are you a member of Share.org?  If so, there are presentations on RMF on the 
SHARE.ORG website.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ibmmain
> Sent: Monday, December 15, 2014 10:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RMF III issue
> 
> Hi
> 
>  Sometime if we have some problem,we will send our RMF III vsam file to IBM
> lab,IBM lab could explore the RMF iii VSAM file on their system.
> 
> Because we always backup our production RMF iii VSAM file,we also want to
> explore this RMF  Monitor (ISPF Application) on the test system.
> 
> We couldn't explore the production RMF monitor on the test system,but why IBM
> lab could do it?
> 
> Thanks  a lot!
> 
> Jason Cai
> 
> 
> From: Lizette Koehler
> Date: 2014-12-16 11:38
> To: IBM-MAIN
> Subject: Re: RMF III issue
> Jason,
> I am not sure what you mean by "open a production RMF III" session.  If you 
> want
> real time, that may not be possible.
> 
> However, if you explore the RMF Monitor (ISPF Application) you can see you can
> create Batch reporting in RMF>
> 
> Check out the share presentations and RMF Manuals
> 
> You can start with
> /OS RMF
> 
> Order number  Title  PDF
> (MB)  BOOK
> (MB)
> SC33-7993-13  z/OS RMF Messages and Codes
> SC33-7992-10  z/OS RMF Performance Management Guide
> SC33-7990-19  z/OS RMF User's Guide
> SC33-7991-19  z/OS RMF Report Analysis
> SX33-9033-05  z/OS RMF Reference Summary
> SC33-7994-14  z/OS RMF Programmer's Guide
> SC33-7995-01  z/OS RMF NewsFLASH
> 
> 
> And
> Effective zSeries Performance Monitoring Using Resource Measurement Facility
> http://www.redbooks.ibm.com/abstracts/sg246645.html?Open
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of ibmmain
> > Sent: Monday, December 15, 2014 8:09 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: RMF III issue
> >
> > Hi all
> >
> >  We meet two issues about RMF III
> >
> > 1)  Could you tell us how  to open a production RMF III on the test 
> > envirnment ?
> >
> > 2) Is there any utility to create RMF III report by a batch job?
> >
> > Thanks a lot!
> >
> > Jason Cai
> >
> 

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


Re: ftp rdw

2014-12-16 Thread Kirk Wolf
Paul,

You should submit an RFE for FTP to IBM.

FWIW, Co:Z SFTP and Data Set Pipes support RDW-delimited transfers in both
directions.
See "linerule"
https://www.dovetail.com/docs/sftp/options.html#options_general

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Co:Z SFTP is free to use under our Community License


On Sun, Dec 14, 2014 at 9:08 PM, Paul Edwards  wrote:

> > If the OP hasn't access to z/OS, his interest must be only academic.
>
> I wish to distribute VB files (developed on MVS/380) via PC,
> with z/OS as a target. I don't want BDW, just the RDW format
> that ftp produces. I'm very happy with the RDW format that
> IBM's ftp produces, I just want it to be reversible.
>
> I hope someone can ask IBM about this.
>
> Thanks. Paul.
>
> --
> 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: ftp rdw

2014-12-16 Thread David Crayford

On 16/12/2014 9:58 PM, John McKown wrote:

On Tue, Dec 16, 2014 at 7:45 AM, David Crayford  wrote:


On 16/12/2014 9:32 PM, John McKown wrote:


On Tue, Dec 16, 2014 at 7:25 AM, David Crayford 
wrote:

  Sorry to be critical but you really do need to check the return value

from
malloc() and realloc(). I would also replace the ascending goto with a
while loop. Other than that it looks good.


  ​Not critical, helpful! I put in a check on the malloc(). It never

occurred
to me that the realloc() could fail because it is only used to shrink the
existing allocation. I guess that I thought that shrinking was always an
"in place" operation.​

​I'll fix that too. ​



I would have the client pass in a buffer and length and not do any heap
allocation. There should be a max length that can be specified in a #define
MAX_LRECL constant.



​I guess, in that case, that the prototype would look something like:

void *vbsread(int fd, void *buffer, int buffer_length);​


Well you need a to set the bounds for the buffer length for the client.

void *vbsread(int fd, void *buffer, size_t buffer_length);

char buffer[MAX_LRECL];

vbsread(fd,buffer,sizeof buffer)




​Is a MAX_LRECL really needed? Is a z/OS VB record _ever_ greater than
32767 bytes? Yes, I can see how somebody could write a program which
creates a data set containing VBS segments which, combined, would exceed
that limit. But using "normal" z/OS facilities, it would be difficult. And
I'd bet that even the venerable DFSORT would cough up hair balls trying to
process it. I need to read up on LRI, I guess.​




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


Re: ftp rdw

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 8:07 AM, David Crayford  wrote:
​​

> ​I guess, in that case, that the prototype would look something like:
>>
>> void *vbsread(int fd, void *buffer, int buffer_length);​
>>
>
> Well you need a to set the bounds for the buffer length for the client.
>
> void *vbsread(int fd, void *buffer, size_t buffer_length);
>
> char buffer[MAX_LRECL];
>
> vbsread(fd,buffer,sizeof buffer)
>
>
​I changed vbsrecord to look like:

#if !defined(VBS_MAX_LRECL)
#define VBS_MAX_LRECL 32767
#endif
typedef struct {
int vbslrecl;
char vbsdata[VBS_MAX_LRECL]; /*actually this is "vbslrecl" bytes of data */
} vbsrecord ;

which allows the user #include it, but set the maximum lrecl themselves to
some value. If they don't, it will default to 32767. I haven't looked at
changing vbsread() yet.​


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-16 Thread John Gilmore
This issue can be looked at in two very different ways.  A balance
must certainly be struck, but I suspect that if some few indiividual
HCs do not annoy some few users the wrong balance has in fact been
struck.

Turn off those that annoy you, but do so iff you are sure that you
have understood the (inapplicable to your shop) rationale for them.

My own experience strongly suggests that HC recommendations are too
often ignored by the ignorant, that inattention to them is much more
problematic than is time wasted on marginal ones.

John Gilmore, Ashland, MA 01721 - USA

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


Re: ftp rdw

2014-12-16 Thread Paul Gilmartin
On Tue, 16 Dec 2014 07:58:56 -0600, John McKown wrote:
>
>​Is a MAX_LRECL really needed? Is a z/OS VB record _ever_ greater than
>32767 bytes? Yes, I can see how somebody could write a program which
>creates a data set containing VBS segments which, combined, would exceed
>that limit. But using "normal" z/OS facilities, it would be difficult. And
>I'd bet that even the venerable DFSORT would cough up hair balls trying to
>process it. I need to read up on LRI, I guess.​
> 
I'll put on my Black Team suit.  Things that aren't really needed to be
handled happen.

IIRC, Rexx in z/OS 2.1 supports RECFM=VBS (and RECFM=U).  I'll
have to try.


On Tue, 16 Dec 2014 07:13:32 -0600, John McKown  wrote:
>
>> I believe that is even RECFM=VBS.  Does FTP RDW
>> do something reasonable with the spanning?
>>>
>​Each segment comes in separately, just as it is on the file. FTP does not
>reassemble a spanned record into a single record. So your code must
>reassemble the entire record from the segments. I have C code which does
>
Does STRU R preserve the spanning flags in the SDWs, needed to
reassemble the entire record?

>this. If you (or others) would like to look at it, it is available as a
>"gist" on GitHub via the URL:
> https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b
>​
>​Despite its being designed to run under z/OS, it will compile using gcc on
>Linux. I don't do Windows programming.​ I don't contend that it is the best
>code in the world. But it worked in my minor testing.
>
Big-endian Linux or little-endian Linux?  (Doesn't matter if you avoid
type-punning.)  Compile?  *And* execute properly?

-- gil

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


AW: Re: Purging output

2014-12-16 Thread Peter Hunkeler
> Looks like the CC=(4) is an invalid keyword for a filter.


According to the FM, it's not the keyword but the value which is invalid. I've 
never used this keyword but from the FM, it seems you can't select on the 
actual CC value but only by category. Categories are ABENDED, CANCELLED, CODE, 
etc., etc.


However the listing CC as part of the $PO command might bean error; the 
explanation to the keywords says "Display" or "Displays". Not meaningfull a s 
part of a purge. Also, I just tried some keywords and got errors. Using CC= on 
a $DO... works as expected.


I'll submit an RCF to get this clarified.


--
Peter Hunkeler





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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread CM Poncelet

... and also PGM=PDSM18 (possibly part of PDSMAN) if you have it.

Kjell Holmborg wrote:

You may also use FileAid if you have that installed instead of FileManager. 


/Kjelle

--
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: ftp rdw

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 8:44 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 16 Dec 2014 07:58:56 -0600, John McKown wrote:
> >
> >​Is a MAX_LRECL really needed? Is a z/OS VB record _ever_ greater than
> >32767 bytes? Yes, I can see how somebody could write a program which
> >creates a data set containing VBS segments which, combined, would exceed
> >that limit. But using "normal" z/OS facilities, it would be difficult. And
> >I'd bet that even the venerable DFSORT would cough up hair balls trying to
> >process it. I need to read up on LRI, I guess.​
> >
> I'll put on my Black Team suit.  Things that aren't really needed to be
> handled happen.
>
> IIRC, Rexx in z/OS 2.1 supports RECFM=VBS (and RECFM=U).  I'll
> have to try.
>
>
> On Tue, 16 Dec 2014 07:13:32 -0600, John McKown  wrote:
> >
> >> I believe that is even RECFM=VBS.  Does FTP RDW
> >> do something reasonable with the spanning?
> >>>
> >​Each segment comes in separately, just as it is on the file. FTP does not
> >reassemble a spanned record into a single record. So your code must
> >reassemble the entire record from the segments. I have C code which does
> >
> Does STRU R preserve the spanning flags in the SDWs, needed to
> reassemble the entire record?​


​My summary of STRU R vs. STRU F with & without SITE RDW, from downloading
some SMF data

STRU F / SITE NORDW - junk - only the "data" portion, no way to determine
where a record ends.

STRU F / SITE RDW - usable. Each VBS segment​ read separately and
correctly. The code on the PC must reassemble segmented records.

STRU R / SITE NORDW - appears to be junk - Each VBS segment read as a
separate "record", but no spanning information is available.

STRU R / SITE RDW - appears to be junk. The STRU R appears to disable the
SITE RDW because the files downloaded with STRU R files are identical
regardless of SITE RDW or NORDW.

So, for VBS files, the only useful download appears to be the STRU F / SITE
RDW. Which stresses the OPs problem of having something which can be
downloaded to a PC, then uploaded back to z/OS. FTP just doesn't appear to
be able to do this for VBS files. Very interesting. And I was totally wrong
in thinking that STRU R would work.



>
> >this. If you (or others) would like to look at it, it is available as a
> >"gist" on GitHub via the URL:
> > https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b
> >​
> >​Despite its being designed to run under z/OS, it will compile using gcc
> on
> >Linux. I don't do Windows programming.​ I don't contend that it is the
> best
> >code in the world. But it worked in my minor testing.
> >
> Big-endian Linux or little-endian Linux?  (Doesn't matter if you avoid
> type-punning.)  Compile?  *And* execute properly?
>

​Either byte order. The FTP transfers the data "as is" from z/OS. Which
means that the LLBB field is in big-endian (z) format, which is the same a
"network order". The code uses the ntohs() function to convert this from z
(network) order to host order. I've only done some very minor testing on
Linux. And "it didn't blow up". 


>
> -- gil
>
>
-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: ftp rdw

2014-12-16 Thread Paul Gilmartin
On Tue, 16 Dec 2014 09:46:30 -0600, John McKown wrote:
>
>STRU R / SITE NORDW - appears to be junk - Each VBS segment read as a
>separate "record", but no spanning information is available.
> 
That I'll consider a bug.  All the segments of a continued logical record
should be transmitted as a single record with the 0xFF01 supplied only
after the last.

But there's little point in reporting it; it will be close DOC with a statement
in the Reference that spanned records are not supported.  (Assuming
that no such restriction is already documented.)

-- gil

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread retired mainframer
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of nitz-...@gmx.net
> Sent: Tuesday, December 16, 2014 1:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RECFM=VBS,LRECL=32767?
> 
> >  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767
> >  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE
> LRECL SUBPARAMETER OF THE DCB FIELD
> > Why is this considered an error?
> >
> > In fact, 32761 is accepted; 32762 causes the error.  On what rationale
is this based?
> > The same limts appear to apply to RECFM=VB.
> > I haven't tried OPENing any such data set.
> 
> The explanation I came up with when I tested boundary conditions ()
was that
> 32767 is the maximum allowed for fixed records. And that length was
determined by
> DASD geometry (in the past). A variable length record always has a length
field preceding
> the actual record data. And since this is blocked, you also need length
for the block
> descriptor. These two make up the 6 byte that you cannot specify for lrecl
without
> exceeding geometry. I haven't tested (or if I did, I forgot the results)
if it makes a difference
> when you use RECFM=V(S). The layout is described somewhere in SC26-7410
Using data
> sets.

Isn't the RDW already included in the LRECL (VBA print files are 137 which
leaves 133 for data which includes carriage control)?  Isn't the BDW always
excluded from the LRECL since only one is present in a block which may
contain more than one record)?

Aren't the RDW and BDW both 4 bytes each?

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread R.S.

W dniu 2014-12-16 o 18:15, retired mainframer pisze:

[...]
Isn't the RDW already included in the LRECL (VBA print files are 137 which
leaves 133 for data which includes carriage control)?  Isn't the BDW always
excluded from the LRECL since only one is present in a block which may
contain more than one record)?

Aren't the RDW and BDW both 4 bytes each?


BDW and RDW are always 4-bytes each.
VBA contains additional character for carriage control
LRECL is total length of the record: the content + RDW.
Of course LRECL in JCL means maximum LRECL allowable for the records.

Block contains BDW and some (at least 1) records. Each record consist of 
RDW and record content.
The above is for RECFM=VB, not for VBS or VS, but if you replace 
"record" with "segment" it will be OK. ;-)


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote.



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


Re: COBOL IGZBRDGE

2014-12-16 Thread Frank Swarbrick
Thanks.I still have to wonder why anyone would use that instead of just 
recompiling with DYNAM.  With IGZBRDGE you still have to re-link, so why not 
recompile as well?  Ah well, water way under the bridge I guess!
Frank
 From: Bob Rutledge 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, December 15, 2014 8:51 PM
 Subject: Re: COBOL IGZBRDGE
   
Frank Swarbrick wrote:
> We got an interesting note from one of our vendors.  They are using the 
> IGZEBRG module (which I guess is invoked from the IGZBRDGE macro, though they 
> don't seem to actually use the macro itself) for dynamic calls and are going 
> to have to make "invasive changes" in order to get around the fact that this 
> is not supported in COBOL 5.
> We never used this feature in our own internal programs.  Where can I find 
> out more about how it worked and what the migration path away from it is/was? 
>  I can't seem to find much about it on the internet.  I assume that's because 
> it's really a COBOL II feature.
>>From what I can tell by looking at the macro (in CEE.SCEEMAC) and its 
>>resulting usage it looks like its used to create an object module with entry 
>>points for any routine where you want to use a static call and yet have the 
>>actual modules called/loaded dynamically.  I am curious about the history 
>>behind it.  Why would this have been used instead of just specifying the 
>>COBOL DYNAM option so that a "call literal" does a dynamic call instead of a 
>>static call?
> Not that it matters in the end; I'm just wondering about its history.  And 
> I'm wondering how long ago this vendor should have stopped using it.  :-)

Start here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IGYSH007?SEARCHREQUEST=cobol+ii&TYPE=FUZZY&RANK=RANK&SEARCHTOPIC=TOPIC&SEARCHTEXT=TEXT&SEARCHINDEX=INDEX&CASE=alcse913

It's described in the APG for MVS & CMS.

Bob



--
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: COBOL IGZBRDGE

2014-12-16 Thread Sam Siegel
relinking does not change calling program.  This has the potential to
reduce testing effort.

On Tue, Dec 16, 2014 at 9:38 AM, Frank Swarbrick <
002782105f5c-dmarc-requ...@listserv.ua.edu> wrote:
>
> Thanks.I still have to wonder why anyone would use that instead of just
> recompiling with DYNAM.  With IGZBRDGE you still have to re-link, so why
> not recompile as well?  Ah well, water way under the bridge I guess!
> Frank
>  From: Bob Rutledge 
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Monday, December 15, 2014 8:51 PM
>  Subject: Re: COBOL IGZBRDGE
>
> Frank Swarbrick wrote:
> > We got an interesting note from one of our vendors.  They are using the
> IGZEBRG module (which I guess is invoked from the IGZBRDGE macro, though
> they don't seem to actually use the macro itself) for dynamic calls and are
> going to have to make "invasive changes" in order to get around the fact
> that this is not supported in COBOL 5.
> > We never used this feature in our own internal programs.  Where can I
> find out more about how it worked and what the migration path away from it
> is/was?  I can't seem to find much about it on the internet.  I assume
> that's because it's really a COBOL II feature.
> >>From what I can tell by looking at the macro (in CEE.SCEEMAC) and its
> resulting usage it looks like its used to create an object module with
> entry points for any routine where you want to use a static call and yet
> have the actual modules called/loaded dynamically.  I am curious about the
> history behind it.  Why would this have been used instead of just
> specifying the COBOL DYNAM option so that a "call literal" does a dynamic
> call instead of a static call?
> > Not that it matters in the end; I'm just wondering about its history.
> And I'm wondering how long ago this vendor should have stopped using it.
> :-)
>
> Start here:
>
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IGYSH007?SEARCHREQUEST=cobol+ii&TYPE=FUZZY&RANK=RANK&SEARCHTOPIC=TOPIC&SEARCHTEXT=TEXT&SEARCHINDEX=INDEX&CASE=alcse913
>
> It's described in the APG for MVS & CMS.
>
> Bob
>
>
>
> --
> 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: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Paul Gilmartin
On Tue, 16 Dec 2014 09:15:21 -0800, retired mainframer wrote:
>>
>> >  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767
>> >  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE
>> LRECL SUBPARAMETER OF THE DCB FIELD
>> > Why is this considered an error?
>> >
>> > In fact, 32761 is accepted; 32762 causes the error.  On what rationale
>is this based?
>> > The same limts appear to apply to RECFM=VB.
>
>Isn't the RDW already included in the LRECL (VBA print files are 137 which
>leaves 133 for data which includes carriage control)?  Isn't the BDW always
>excluded from the LRECL since only one is present in a block which may
>contain more than one record)?
>
>Aren't the RDW and BDW both 4 bytes each?
> 
All as I understand it.  And to muddle things further:

user@HOST: rexx "say d2x( BPXWDYN( 'alloc recfm(v,b,s) lrecl(32760) msg(2)' ) 
)"   
0
user@HOST: rexx "say d2x( BPXWDYN( 'alloc recfm(v,b,s) lrecl(32761) msg(2)' ) 
)"   
IKJ56231I UTILITY DATA SET NOT ALLOCATED, SYSTEM OR INSTALLATION ERROR+
IKJ56231I TEXT UNIT X'0042' CONTAINS INVALID PARAMETER
35C0042

-- gil

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Nims,Alva John (Al)
Oh boy, did someone go off on a tangent.

Let me throw in my $0.02 on this:

#1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL=
#2. From the MVS JCL Reference:  the value of LRECL is either: "1 to 32,760 for 
non-VSAM data sets." Or " 1 to 32,761 for VSAM key-sequenced (KS), 
entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply 
to VSAM linear space, RECORG=LS, data sets.)"

So specifying 32,767  exceeds the maximum allowed, just as the error message 
states.

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Tuesday, December 16, 2014 12:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECFM=VBS,LRECL=32767?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of nitz-...@gmx.net
> Sent: Tuesday, December 16, 2014 1:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RECFM=VBS,LRECL=32767?
> 
> >  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767
> >  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE
> LRECL SUBPARAMETER OF THE DCB FIELD
> > Why is this considered an error?
> >
> > In fact, 32761 is accepted; 32762 causes the error.  On what 
> > rationale
is this based?
> > The same limts appear to apply to RECFM=VB.
> > I haven't tried OPENing any such data set.
> 
> The explanation I came up with when I tested boundary conditions 
> ()
was that
> 32767 is the maximum allowed for fixed records. And that length was
determined by
> DASD geometry (in the past). A variable length record always has a 
> length
field preceding
> the actual record data. And since this is blocked, you also need 
> length
for the block
> descriptor. These two make up the 6 byte that you cannot specify for 
> lrecl
without
> exceeding geometry. I haven't tested (or if I did, I forgot the 
> results)
if it makes a difference
> when you use RECFM=V(S). The layout is described somewhere in 
> SC26-7410
Using data
> sets.

Isn't the RDW already included in the LRECL (VBA print files are 137 which 
leaves 133 for data which includes carriage control)?  Isn't the BDW always 
excluded from the LRECL since only one is present in a block which may contain 
more than one record)?

Aren't the RDW and BDW both 4 bytes each?

--
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: Utility to replace occurrences of string in PDS?

2014-12-16 Thread David Mingee
I think the requirement for a member name $$$COIBM has been removed.  I have 
used IPOUPDTE on 3 different sites in the past few years without this 
restriction.  Many of the other utilities are great, but some cost money or may 
not be installed at some sites, so IPPOUPDTE is a great option.  It also allows 
for updating multiple pds/pdse's in one execution and provides a PARM=CHECK or 
UPDATE to allow checking your changes before doing the actual UPDATE.  The DD 
name(s) must start with @.   A JCL example:

//IPOUPDTE JOB
(24186),'CHANGE
JCL',CLASS=P,MSGCLASS=O 
//*
//*
//*  MASS CHANGE TO LIBRARY
MEMBERS  
*
//STEP
EXEC PGM=IPOUPDTE,PARM=CHECK  will simulate changes 
//*STEP EXEC
PGM=IPOUPDTE,PARM=UPDATEwill perform 
changes  
//SYSPRINT DD  
SYSOUT=*   
//@TESTDD   DSN=GRT.GIOIDXM.JCL,DISP=SHR can use more than
one LIB 
//@TEST2   DD   DSN=GRP.GIOIDXM.JCL,DISP=SHR  
//SYSINDD  
*  
  CLASS=P
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, December 15, 2014 7:29 PM
Subject: Re: Utility to replace occurrences of string in PDS?
  

Hmmm. Also "Important: For CPPUPDTE and IPOUPDTE to work, each PDS to be 
searched
MUST contain a member named $$$COIBM."

Obviously that is something I could create but that creates problems of its own.

May keep looking a little. Not sure if I have File Manager.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, December 15, 2014 4:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

Server Pac

CPPUPDTE is a program that enables you to search for a string across all the 
members of a PDS and replace that string with another string.  CPPUPDTE is 
loaded into the LOADLIB data set
(hlq.order_number.LOADLIB) during ServerPac installation.  It also has an alias 
name of IPOUPDTE because the job is actually the same job that was shipped with 
CBIPO.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John McKown
> Sent: Monday, December 15, 2014 5:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Utility to replace occurrences of string in PDS?
> 
> Is IPOUPDTE still around? I'm at home right now & can't easily look.
> On Dec 15, 2014 6:08 PM, "Charles Mills"  wrote:
> 
> > I'm looking for a reasonable way to replace all occurrences of a 
> > given string in a dataset. UNIX shell command? DFSMS utility that I 
> > have forgotten about? CBT program?
> >
> > Nothing fancy. I have a PDS with seven or so members. I want to 
> > replace all instances of $REPLACEME$ with NEWSTRING. I know which 
> > members contain the pattern so I could live with *either* something 
> > that did the whole PDS, or something where I had to specify the 
> > specific members. First choice would be something that copied the 
> > PDS, but I can make my own copy and live with a replace-in-place.
> >
> > I could write Rexx to do it so that's my bottom line -- it has to be 
> > easier than writing a Rexx program.
> >
> > Any suggestions?
> >
> > Charles

--
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: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Paul Gilmartin
On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote:

>Oh boy, did someone go off on a tangent.
>
>Let me throw in my $0.02 on this:
>
>#1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL=
>#2. From the MVS JCL Reference:  the value of LRECL is either: "1 to 32,760 
>for non-VSAM data sets." Or " 1 to 32,761 for VSAM key-sequenced (KS), 
>entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply 
>to VSAM linear space, RECORG=LS, data sets.)"
>
>So specifying 32,767  exceeds the maximum allowed, just as the error message 
>states.
> 
My question is, why should there be a limit of 32761?  I understand the signed
halfword format imposes a limit of 32767.  I see no reason for any smaller
limit.

-- gil

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Chase, John
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
> 
> [ snip ]
> My question is, why should there be a limit of 32761?  I understand the 
> signed halfword format imposes
> a limit of 32767.  I see no reason for any smaller limit.

In a VSAM Control Interval (CI), the CIDF is 4 bytes (think "BDW") but the RDF 
is three bytes (think "RDW").  So, with VSAM you get an extra byte of space.  
:-)

-jc-

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.


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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Charles Mills
When I tried IPOUPDTE on my PDS I got an error IPO006  FILE @PDS INVALID
FOR IPOUPDTE that I resolved by adding a member $$$COIBM, so I conclude that
the restriction is still there, at least on the copy on my V2R1 system.

It's a GREAT little utility except for the stupid kneecapping.

FWIW, here is the resolution of my requirement:

No FileAid, no File Manager.

CBT 040 is really complex, lightly-commented assembler code from the dark
ages (31 bit? reentrance? what's that?) and way overkill for what I want.

IPOUPDTE would be *perfect* except for the $$$COIBM restriction. Yes, I can
work around that, but the result is kind of an offensive kludge.

I wrote a little Rexx program, cannibalizing some Rexx I had lying around.

Problem solved.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Mingee
Sent: Tuesday, December 16, 2014 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

I think the requirement for a member name $$$COIBM has been removed.  I have
used IPOUPDTE on 3 different sites in the past few years without this
restriction.  Many of the other utilities are great, but some cost money or
may not be installed at some sites, so IPPOUPDTE is a great option.  It also
allows for updating multiple pds/pdse's in one execution and provides a
PARM=CHECK or UPDATE to allow checking your changes before doing the actual
UPDATE.  The DD name(s) must start with @.   A JCL example:

//IPOUPDTE JOB
(24186),'CHANGE
JCL',CLASS=P,MSGCLASS=O 
//*
//*
//*  MASS CHANGE TO LIBRARY
MEMBERS  
*
//STEP
EXEC PGM=IPOUPDTE,PARM=CHECK  will simulate changes 
//*STEP EXEC
PGM=IPOUPDTE,PARM=UPDATEwill perform 
changes  
//SYSPRINT DD  
SYSOUT=*   
//@TESTDD   DSN=GRT.GIOIDXM.JCL,DISP=SHR can use more than
one LIB 
//@TEST2   DD   DSN=GRP.GIOIDXM.JCL,DISP=SHR  
//SYSINDD  
*  
  CLASS=P

Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread John Abell
Laxman

John T. Abell
President
International Software Products
Tel:  800-295-7608  Ext: 224
International:  1-416-593-5578  Ext: 224
Fax:  800-295-7609
International:  1-416-593-5579

E-mail:  john.ab...@intnlsoftwareproducts.com
Web: www.ispinfo.com

This email may contain confidential and privileged material for the sole use of 
the intended recipient(s). Any review, use, retention, distribution or 
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient), please 
contact the sender by reply email and delete all copies of this message. 
Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive emails 
on the basis that we are not liable for any such corruption, interception, 
tampering, amendment or viruses or any consequence thereof.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 16, 2014 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RECFM=VBS,LRECL=32767?

On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote:

>Oh boy, did someone go off on a tangent.
>
>Let me throw in my $0.02 on this:
>
>#1. YES, the RDW (4 bytes) MUST BE included in the length specified in
>LRECL= #2. From the MVS JCL Reference:  the value of LRECL is either: "1 to 
>32,760 for non-VSAM data sets." Or " 1 to 32,761 for VSAM key-sequenced (KS), 
>entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply 
>to VSAM linear space, RECORG=LS, data sets.)"
>
>So specifying 32,767  exceeds the maximum allowed, just as the error message 
>states.
>
My question is, why should there be a limit of 32761?  I understand the signed 
halfword format imposes a limit of 32767.  I see no reason for any smaller 
limit.

-- gil

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


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread John McKown
On Tue, Dec 16, 2014 at 12:25 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John (Al) wrote:
>
> >Oh boy, did someone go off on a tangent.
> >
> >Let me throw in my $0.02 on this:
> >
> >#1. YES, the RDW (4 bytes) MUST BE included in the length specified in
> LRECL=
> >#2. From the MVS JCL Reference:  the value of LRECL is either: "1 to
> 32,760 for non-VSAM data sets." Or " 1 to 32,761 for VSAM key-sequenced
> (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does
> not apply to VSAM linear space, RECORG=LS, data sets.)"
> >
> >So specifying 32,767  exceeds the maximum allowed, just as the error
> message states.
> >
> My question is, why should there be a limit of 32761?  I understand the
> signed
> halfword format imposes a limit of 32767.  I see no reason for any smaller
> limit.
>
> -- gil
>
>
​I _think_ that I figured out where the 32760 came from. 32760 == 0x7FF8.
It is the largest multiple of 8 which can be kept in a signed half-word.
OS/360 used signed half-words to avoid sign extension​

​when using the LH instruction. The original CCW had a two byte size field,
so that's likely where the half-word in all the I/O control blocks came
from. And we need a multiple of 8 because that's the granularity of the
GETMAIN / FREEMAIN allocation. To go to 32767 would really be to require
32768 (due to 8 byte granularity), which is 0x8000. OOPS, there's the nasty
sign extension on the LH instruction. And, in OS/360 days, who's going to
write that large a block anyway? The only possibility would be on a tape
because disk drives in that era didn't have tracks that big. And, in any
case, who back then had that much core memory for such a big physical
block? We are constrained today by staying backwards compatible. Even
today, if I read it correctly, the Large Block Interface for physical
records >32760 bytes is _only_ for tape. And, in any case, everybody should
just convert to DB2 and not even worry about it. Right?

-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

Maranatha! <><
John McKown

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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread van der Grijn, Bart (B)
There used to be a zap for IPOUPDTE to get rid of the $$$COIBM requirement. 
Google "IPOUPDTE ZAP". Don't know if they still work. But it is likely worth 
the quick search and test if you need the functionality.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, December 16, 2014 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

When I tried IPOUPDTE on my PDS I got an error IPO006  FILE @PDS INVALID
FOR IPOUPDTE that I resolved by adding a member $$$COIBM, so I conclude that
the restriction is still there, at least on the copy on my V2R1 system.

It's a GREAT little utility except for the stupid kneecapping.

FWIW, here is the resolution of my requirement:

No FileAid, no File Manager.

CBT 040 is really complex, lightly-commented assembler code from the dark
ages (31 bit? reentrance? what's that?) and way overkill for what I want.

IPOUPDTE would be *perfect* except for the $$$COIBM restriction. Yes, I can
work around that, but the result is kind of an offensive kludge.

I wrote a little Rexx program, cannibalizing some Rexx I had lying around.

Problem solved.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Mingee
Sent: Tuesday, December 16, 2014 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

I think the requirement for a member name $$$COIBM has been removed.  I have
used IPOUPDTE on 3 different sites in the past few years without this
restriction.  Many of the other utilities are great, but some cost money or
may not be installed at some sites, so IPPOUPDTE is a great option.  It also
allows for updating multiple pds/pdse's in one execution and provides a
PARM=CHECK or UPDATE to allow checking your changes before doing the actual
UPDATE.  The DD name(s) must start with @.   A JCL example:

//IPOUPDTE JOB
(24186),'CHANGE
JCL',CLASS=P,MSGCLASS=O 
//*
//*
//*  MASS CHANGE TO LIBRARY
MEMBERS  
*
//STEP
EXEC PGM=IPOUPDTE,PARM=CHECK  will simulate changes 
//*STEP EXEC
PGM=IPOUPDTE,PARM=UPDATEwill perform 
changes  
//SYSPRINT DD  
SYSOUT=*   
//@TESTDD   DSN=GRT.GIOIDXM.JCL,DISP=SHR can use more than
one LIB 
//@TEST2   DD   DSN=GRP.GIOIDXM.JCL,DISP=SHR  
//SYSINDD  
*  
  CLASS=P

Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Charles Mills
Yeah, thanks, down at the bottom of
https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/473KcCMYWNk. 

I've got it solved. Thanks,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of van der Grijn, Bart (B)
Sent: Tuesday, December 16, 2014 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

There used to be a zap for IPOUPDTE to get rid of the $$$COIBM requirement.
Google "IPOUPDTE ZAP". Don't know if they still work. But it is likely worth
the quick search and test if you need the functionality.

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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Tony's Basement Computer
This thread brings back a memory from back in the day when they actually
paid me to be a SYSPROG.  IPOUPDTE was all we had so we added a step to load
the "sacred member", do the changes, delete the member in a following step.
Annoying, like my new Keurig coffee machine.

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of van der Grijn, Bart (B)
Sent: Tuesday, December 16, 2014 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

There used to be a zap for IPOUPDTE to get rid of the $$$COIBM requirement.
Google "IPOUPDTE ZAP". Don't know if they still work. But it is likely worth
the quick search and test if you need the functionality.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, December 16, 2014 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

When I tried IPOUPDTE on my PDS I got an error IPO006  FILE @PDS INVALID
FOR IPOUPDTE that I resolved by adding a member $$$COIBM, so I conclude that
the restriction is still there, at least on the copy on my V2R1 system.

It's a GREAT little utility except for the stupid kneecapping.

FWIW, here is the resolution of my requirement:

No FileAid, no File Manager.

CBT 040 is really complex, lightly-commented assembler code from the dark
ages (31 bit? reentrance? what's that?) and way overkill for what I want.

IPOUPDTE would be *perfect* except for the $$$COIBM restriction. Yes, I can
work around that, but the result is kind of an offensive kludge.

I wrote a little Rexx program, cannibalizing some Rexx I had lying around.

Problem solved.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Mingee
Sent: Tuesday, December 16, 2014 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

I think the requirement for a member name $$$COIBM has been removed.  I have
used IPOUPDTE on 3 different sites in the past few years without this
restriction.  Many of the other utilities are great, but some cost money or
may not be installed at some sites, so IPPOUPDTE is a great option.  It also
allows for updating multiple pds/pdse's in one execution and provides a
PARM=CHECK or UPDATE to allow checking your changes before doing the actual
UPDATE.  The DD name(s) must start with @.   A JCL example:

//IPOUPDTE JOB
(24186),'CHANGE
JCL',CLASS=P,MSGCLASS=O 
//*
//*
//*  MASS CHANGE TO LIBRARY
MEMBERS  
*
//STEP
EXEC PGM=IPOUPDTE,PARM=CHECK  will simulate changes 
//*STEP EXEC
PGM=IPOUPDTE,PARM=UPDATEwill perform 
changes  
//SYSPRINT DD  
SYSOUT=*   
//@TESTDD   DSN=GRT.GIOIDXM.JCL,DISP=SHR can use more than
one LIB 
//@TEST2   DD   DSN=GRP.GIOIDXM.JCL,DISP=SHR  
//SYSINDD  
*  
  CLASS=P

Trouble with IARV64 GETCOMMON

2014-12-16 Thread Donald Likens
I issue the following macro:
IARV64 REQUEST=GETCOMMON,
  COND=YES,  
  SEGMENTS=SBS01, <=== Value is 1.  
  MOTKNSOURCE=SYSTEM,OUTMOTKN=SBITKN,
  TYPE=PAGEABLE, 
  OWNERCOM=SYSTEM,   
  ORIGIN=SBILOC, 
  DUMP=LIKECSA,  
  RSNCODE=SBIRSN   
  
I display the address obtained.

When I look at this address in IPCS looking at the ACTIVE address space, I do 
not see my storage.

When I take a dump of my address space, I see my storage.

What am I doing wrong?

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


Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-16 Thread J O Skip Robinson
My complaints focus on those HCs that don't really make sense any more. For 
example, in 1984 it would have been a cogent warning that the Product X master 
file and its backup/alternate are located behind the same DASD control unit. If 
you lost the control unit, you'd lose both copies. In 2014 with array 
technology, there is no longer a physical control unit. You have a big box with 
hundreds of logical volumes. If you lose the whole box, you're in a world of 
hurt so egregious that the demise of a master file is just noise. Yet I get 
constant warnings about a configuration oversight for which there is no 
feasible remedy. Sure I can turn the HC off, but shouldn't common sense (and a 
bit of extra coding) turn it off for me?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Tuesday, December 16, 2014 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

This issue can be looked at in two very different ways.  A balance must 
certainly be struck, but I suspect that if some few indiividual HCs do not 
annoy some few users the wrong balance has in fact been struck.

Turn off those that annoy you, but do so iff you are sure that you have 
understood the (inapplicable to your shop) rationale for them.

My own experience strongly suggests that HC recommendations are too often 
ignored by the ignorant, that inattention to them is much more problematic than 
is time wasted on marginal ones.

John Gilmore, Ashland, MA 01721 - USA

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Robert A. Rosenberg
At 12:25 -0600 on 12/16/2014, Paul Gilmartin wrote about Re: 
RECFM=VBS,LRECL=32767?:


On Tue, 16 Dec 2014 18:06:20 +, Nims,Alva John 
(Al) wrote:



Oh boy, did someone go off on a tangent.

Let me throw in my $0.02 on this:

#1. YES, the RDW (4 bytes) MUST BE included in the length specified in LRECL=
#2. From the MVS JCL Reference:  the value of LRECL is either: "1 
to 32,760 for non-VSAM data sets." Or " 1 to 32,761 for VSAM 
key-sequenced (KS), entry-sequenced (ES), or relative record (RR) 
data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, 
data sets.)"


So specifying 32,767  exceeds the maximum allowed, just as the 
error message states.



My question is, why should there be a limit of 32761?  I understand the signed
halfword format imposes a limit of 32767.  I see no reason for any smaller


The limit should be 32763. That allows a 32767 byte VB (or VBS) 
block. With a VB, there is room in a block for the 4 byte BDW and a 
5-32763 byte V record (4 byte RDW plus 1-32759 of data). Why the 
32760 LRECL Limit I do not know since that wastes 3 bytes in a VB 
single record record block.



limit.

-- 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: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Chris Hoelscher
I am going to suggest something very silly here

Why not write an edit macro to make the change(s) to one member
And then write a rexx to execute this macro against every member??

ISREDIT MACRO 
ISREDIT (STATUS) = USER_STATE 
ISREDIT RESET SPECIAL 
ISREDIT CHANGE ALL YOUR.OLD  "YOUR.NEW"   
/*
ISREDIT USER_STATE = (STATUS) 
EXIT  






Chris hoelscher
Technology Architect | Database Infrastructure Services
Technology Solution Services

123 East Main Street |Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 476-2538 - office
(502) 714-8615 - blackberry
HumanaVitality LEAD STATUS

e access instructions, send email to lists...@listserv.ua.edu with the message: 
INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Charles Mills
Yup. Pretty much done. I actually had some Rexx around to do some of the
changes "itself" so I am not using edit any more. 

Requirement was for batch.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Chris Hoelscher
Sent: Tuesday, December 16, 2014 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

I am going to suggest something very silly here

Why not write an edit macro to make the change(s) to one member And then
write a rexx to execute this macro against every member??

ISREDIT MACRO 
ISREDIT (STATUS) = USER_STATE 
ISREDIT RESET SPECIAL 
ISREDIT CHANGE ALL YOUR.OLD  "YOUR.NEW"   
/*
ISREDIT USER_STATE = (STATUS) 
EXIT  

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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Charles Mills
Annoying indeed. I played with insert $$$COIBM and then delete it again, and
I played with leaving a $$$COIBM in there but with our copyright message
rather than IBM's. I don't think the name $$$COIBM has any particular legal
standing.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony's Basement Computer
Sent: Tuesday, December 16, 2014 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to replace occurrences of string in PDS?

This thread brings back a memory from back in the day when they actually
paid me to be a SYSPROG.  IPOUPDTE was all we had so we added a step to load
the "sacred member", do the changes, delete the member in a following step.
Annoying, like my new Keurig coffee machine.

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Paul Gilmartin
On Tue, 16 Dec 2014 16:19:20 -0500, Robert A. Rosenberg  wrote:
>
>The limit should be 32763. That allows a 32767 byte VB (or VBS)
>block. With a VB, there is room in a block for the 4 byte BDW and a
>5-32763 byte V record (4 byte RDW plus 1-32759 of data). Why the
>32760 LRECL Limit I do not know since that wastes 3 bytes in a VB
>single record record block.
> 
The limit should be 32767.  Let me explain for the numerically challenged:

Suppose I have RECFM=VBS,BLKSIZE=10929,LRECL=32767.
I can write 3 blocks, each consisting of:
o A BDW (4 bytes)
o A SDW (4 bytes)
o 10921 bytes of data (total 10929 bytes).

The first SDW should indicate that it's an initial segment; the
second that it's an interior segment, the last a final segment.
The total data are 10921 * 3; 32763 bytes.  But LRECL always
counts a 4-byte RDW, for a total of 32767.
(If the RDW is not to be counted, add another block with 4
bytes of data (a 12-byte block) .)

It was explained to me here that page alignment considerations
impel buffers a multiple of 4KiB, and that there are a few bytes
of overhead, and doubleword alignment considerations impel
32760.

-- gil

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


Re: Utility to replace occurrences of string in PDS?

2014-12-16 Thread Paul Gilmartin
On Tue, 16 Dec 2014 13:53:49 -0800, Charles Mills wrote:

>Yup. Pretty much done. I actually had some Rexx around to do some of the
>changes "itself" so I am not using edit any more.
>
>Requirement was for batch.
> 
That shouldn't be an obstacle; I believe ISPF EDIT works in batch.
(It's just complicated.)


>-Original Message-
>From:  Chris Hoelscher
>Sent: Tuesday, December 16, 2014 1:29 PM
>
>I am going to suggest something very silly here
>
>Why not write an edit macro to make the change(s) to one member And then
>write a rexx to execute this macro against every member??

-- gil

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


Re: RECFM=VBS,LRECL=32767?

2014-12-16 Thread Mike Schwab
On Tue, Dec 16, 2014 at 1:11 PM, John McKown
 wrote:
> I _think_ that I figured out where the 32760 came from. 32760 == 0x7FF8.
> It is the largest multiple of 8 which can be kept in a signed half-word.
> OS/360 used signed half-words to avoid sign extension
>
> when using the LH instruction. The original CCW had a two byte size field,
> so that's likely where the half-word in all the I/O control blocks came
> from. And we need a multiple of 8 because that's the granularity of the
> GETMAIN / FREEMAIN allocation. To go to 32767 would really be to require
> 32768 (due to 8 byte granularity), which is 0x8000. OOPS, there's the nasty
> sign extension on the LH instruction. And, in OS/360 days, who's going to
> write that large a block anyway? The only possibility would be on a tape
> because disk drives in that era didn't have tracks that big. And, in any
> case, who back then had that much core memory for such a big physical
> block? We are constrained today by staying backwards compatible. Even
> today, if I read it correctly, the Large Block Interface for physical
> records >32760 bytes is _only_ for tape. And, in any case, everybody should
> just convert to DB2 and not even worry about it. Right?
>
> --
>
> While a transcendent vocabulary is laudable, one must be eternally careful
> so that the calculated objective of communication does not become ensconced
> in obscurity.  In other words, eschew obfuscation.
>
> Maranatha! <><
> John McKown
>

You could write a block longer than a track using track overflow.
What didn't fit on the first track was continued onto the second track
or subsequent tracks.  Dropped on devices with track sizes over 32K.


-- 
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: ftp rdw

2014-12-16 Thread Paul Edwards
>> That is not even close to the RDW format that IBM
>> provides. I have based PDPCLIB around IBM's RDW
>> format.
 
> And you're not flexible about this?

That's correct. When I open a VB file in binary
mode, there's only one single choice for the
data stream to be in, so I had to pick one single
option.

> And you designed your implementation
> without doing a PoC?

I did do a proof of concept. Someone told me that
there was an RDW option on ftp and I asked for
a sample PC file, and I wrote folks.c (posted in
original message) to process it, and I was
totally happy with this format that IBM had
provided. It is perfectly logical and clean.

Of course there are lots of other things that
could have been done, e.g. a 2-byte length field
instead of a 4-byte RDW. But IBM's decision to
base it on what is actually on the mainframe
instead of e.g. a little-endian 2-byte length,
is perfectly OK with me.

>> That STRU R format also doesn't allow data with x'ff'
>> in it.

Note that it appears I was wrong about that. If data
has x'ff' in it, then it apparently appears as two
x'ff'. Regardless, this is a complicated and
non-natural data format. I may as well be reading
and parsing a TRANSMIT file.

>> The RDW format does.

> That sucks.  How about, then, my earlier suggestion of:

>BINARY
>QUOTE SITE TYPE E
>QUOTE SITE MODE B

That produces this:

00  8BC8 85939396 40A38885 99854000  ...Hello there .
10  05C69693 92A2.Folks

Yes, it is possible to parse that and process on
the PC, but once again I don't think it is as
clean as ftp rdw. The fact that IBM has only made
rdw one-way is not a reason for me to abandon
this excellent file format. It merely makes me
write a non-standard utility to reverse it.
And ask in IBMMAIN for someone to ask IBM for
an improvement. :-)

>> But I would like to be able to distribute a V file the
>> same way I can distribute an F file or a U file, ie
>> just as a simple file, no wrapper (like XMIT/TERSE).

> In a sense, FTP RDW is a wrapper.  But I grant that it is unwrapped
> by the FTP command itself, with no need to run a separate unwrapping
> command on the Z.

I don't consider RDW bytes to be a "wrapper". That
is the exact format of the data in a VB file. It
is true that VB files also have a BDW which is
stripped (stripped, not wrapped), but that is fine.
I do not expect my C program to be exposed to the
concept of "BDW". For starters, I consider BDW to
be a design fault. If FB and U data has no BDW,
and simply an innate block length, I see no reason
for VB to need a BDW.

In addition, I consider that blocksize is something
arbitrary and that all files should be able to be
reblocked at will to suit the device characteristics.
On the PC there are no block sizes, so I expect that
when I transfer a file from mainframe to PC and back
again, that the file will potentially have been
reblocked. I am perfectly happy with this. And this
also applies to the IBM ftp rdw format.

>>> It produces a V-format file that can be
>>> processed by a C program.

>> As an example, I want to be able to transmit an
>> SMF file (which I believe contains binary data) to
>> the PC, and then have a PC program to process
>> the SMF file. The PC program must handle the
>> RDW itself, but that's all.

> I believe that is even RECFM=VBS.  Does FTP RDW
> do something reasonable with the spanning?

From what other people have posted, it doesn't,
so I would like IBM to change that too. In the
meantime I will run a utility on the mainframe
to convert VBS to VB. Again, I don't think a
C program should be exposed to the complications
of VBS. It should just have to deal with V.
PDPCLIB has logic in it to convert a VBS into a
V (and vice-versa), but I'm not sure if it works
or not. If it doesn't work, that's fine, it can
be fixed.

>> IBM's ftp rdw is an excellent file format.

>> Note that the PC program that handles the SMF
>> records can also be uploaded to the mainframe
>> and it continues to work, at least if you are using
>> PDPCLIB as your C library.

> And it handles the spanned records reasonably?

I was told that it does, but I had never tested it
myself. I tried it out today and it didn't give
me what I was expecting, but I'm not sure if I'm
doing something wrong, so I have asked Gerhard
for advice.

BFN. Paul.

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


Re: ftp rdw

2014-12-16 Thread Paul Edwards
> You should submit an RFE for FTP to IBM.

Hi Kirk. I am not an IBM customer. Is this something
you could do yourself? Or will anyone else volunteer?

Thanks. Paul.

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