Re: How about a little Christmas fudge? | Computerworld Shark tank

[Joe Monk]

https://www.ibm.com/ibm/history/ibm100/us/en/icons/mainframe/

IBM themselves refer to the 1401 as a mainframe 

Joe

On Wed, Dec 26, 2018 at 10:56 PM Joel C. Ewing  wrote:

> Well, ...  the IBM 1401 was built in a substantial frame; and in the
> context cited it appears to have the only (hence surely the "main")
> computer present.  Other members of the same general family like IBM
> 1410 were certainly regarded as a mainframe.  I'm pretty sure any
> computer large enough to require one or more dedicated frames  was
> called a "mainframe" in those days.  When mini-computers first came out,
> they weren't considered mainframes because they were typically only the
> size of a single rack and could even be carried.
>
>  With a recent MS in Comp Sci, I found myself in the U.S. Army 1969-1971
> (started in Infantry but ended up as head Company Clerk at HHC of "The
> Old Guard" at Ft Myer VA).  I remember reading some memo that came down
> from above the Battalion suggesting the possibility of using a
> punched-card-based system for maintaining and producing our Company
> Roster.  That might have involved an IBM 1401, but my impression at the
> time was that the functions they were describing could easily have been
> done with just unit-record equipment.  Nothing ever came of it while I
> was there.   It would have saved us the periodic tedium of one or more
> man-hours of manually typing up a new roster in which few names changed,
> but given that our time was cheap and available, there would have been
> no way to cost-justify using a process that would save our time but slow
> down the overall process by requiring outside resources.   Clearly, at
> that time, punched card decks were one of the databases used for
> tracking military personnel.
> Joel C. Ewing
>
> On 12/26/18 2:42 PM, Seymour J Metz wrote:
> > What is he smoking? Since when was the 1401 a mainframe?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Mark Regan 
> > Sent: Wednesday, December 26, 2018 8:28 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: How about a little Christmas fudge? | Computerworld Shark tank
> >
> >
> https://secure-web.cisco.com/1iMlW_GZ2Scqioa5F4rqymcywO0OTBLBFOtYPuQZZF6F73Kv0x_B9nU3SOTiheXf32DsESHEBSvbzXuJ78Z2XaRKtXr7A2GITbjxnEDGjBqcDiOzF9WOIQCYJIH89nABmY7xso9DckpD3Q10YPvrxhvPVeFvR6IYMhBl0Po4k4-03fXnkJSammKYm3lrjMJyX4f-lcp9YlEt59dyzYTF_at6wT-i9VPdyfHx5DVlOyFFEzAQxZe-ifUcS7uOAE70lUB6w6ZfwDLRp9vhqQVEaCVSjXFSY0F4a2YhM92FII0XRqIAu4y7yW4Iop4TXQVM-iMQuqleDME3jgueepL3jXWQ797SaO4hRpNph47Gl9FOTKIqwIXeAe2DNqPGTQMlRexhctM6zHXZYT2EbywHPaw/https%3A%2F%2Fwww.computerworld.com%2Farticle%2F3330396%2Fapplication-development%2Fsituation-normal-all-fudged-up.html
> >
> > ...
> >
>
> --
> Joel C. Ewing
>
> --
> 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: BLSUXTOD

[Joe Monk]

So if you read the POO, you see:


   - Communication between systems is facilitated by establishing a
   standard time origin that is the calendar date and time to which a clock
   value of zero corresponds. January 1, 1900, 0 a.m. Coordinated Universal
   Time (UTC) is recommended as this origin, and it is said to begin the
   standard epoch for the clock.



   - The time-of-day (TOD) clock provides a high- resolution measure of
   real time suitable for the indication of date and time of day. The cycle of
   the clock is approximately 143 years.



   - The TOD clock is a 104-bit register.


So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104
bit clock will roll over, and bit 0 will return to zero.

Joe

On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> In: MVS Interactive Problem Control System (IPCS) Customization
> Version 2 Release 3  SA23-1383-30
>
> I read:
> TOD Clock Service
> The time-of-day (TOD) clock service provides a caller, including your
> exit routine,
> with a TOD clock image. In the clock image, bit 0 is set on to allow
> the service to
> handle values from May 11,1971, at 11:56:53.685248 to January 25,
> 2114, at
> 11:50:41.055743.
>
> ???
> But in PoOps I see
> ...
> If the programming support uses the standard epoch, bit 0 of the clock
> remains one
> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC)
> May 11, 1971.)
>
> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, in
> September, 2042.
> Is there an error in the IPCS doc?
>
> -- 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: BLSUXTOD

[Joe Monk]

"By my arithmetic,  January 1, 1900 + 143 years = January 1, 2043".

Ummm ... Did you forget the year 1900? Theres only 142 years left after you
subtract the Year 1900.

"How are those bits numbered?  0 to 103?  What's the value of bit 0?  What's
the value of bit 103?"

Yes, 0 to 103. Bit 51 is incremented every 1 microsecond. Carries are
propagated out of bit 0.

Joe



On Fri, Dec 28, 2018 at 8:32 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 28 Dec 2018 18:18:51 -0600, Joe Monk wrote:
>
> >So if you read the POO, you see:
> >
> >   - Communication between systems is facilitated by establishing a
> >   standard time origin that is the calendar date and time to which a
> clock
> >   value of zero corresponds. January 1, 1900, 0 a.m. Coordinated
> Universal
> >   Time (UTC) is recommended as this origin, and it is said to begin the
> >   standard epoch for the clock.
> >
> >   - The time-of-day (TOD) clock provides a high- resolution measure of
> >   real time suitable for the indication of date and time of day. The
> cycle of
> >   the clock is approximately 143 years.
> >
> >   - The TOD clock is a 104-bit register.
> >
> How are those bits numbered?  0 to 103?  What's the value of bit 0?  What's
> the value of bit 103?
>
> >So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104
> >bit clock will roll over, and bit 0 will return to zero.
> >
> By my arithmetic,  January 1, 1900 + 143 years = January 1, 2043.
>
> Doesn't forcing bit 0 to 1 as described below restrict the cycle of the
> clock
> to 71 years rather than the 143 years from 1971 to 2114 stated below?
>
> >On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin wrote:
> >
> >> In: MVS Interactive Problem Control System (IPCS) Customization
> >> Version 2 Release 3  SA23-1383-30
> >>
> >> I read:
> >> TOD Clock Service
> >> The time-of-day (TOD) clock service provides a caller, including
> your exit routine,
> >> with a TOD clock image. In the clock image, bit 0 is set on to
> allow the service to
> >> handle values from May 11,1971, at 11:56:53.685248 to January 25,
> 2114, at
> >> 11:50:41.055743.
> >>
> >> ???
> >> But in PoOps I see
> >> ...
> >> If the programming support uses the standard epoch, bit 0 of the
> clock
> >> remains one
> >> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248
> (UTC)
> >> May 11, 1971.)
> >>
> >> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1,
> in
> >> September, 2042.
> >> Is there an error in the IPCS doc?
>
> -- 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: z/OS 1.12 question

[Joe Monk]

z/OS 1.12 is not supported on a z14. So, his only choice is to upgrade z/OS
if he wants to run a z14.

Joe

On Mon, Jan 7, 2019 at 7:26 AM R.S.  wrote:

> IMHO the COD has nothing to do here.
> Jerry wrote about mahcine change (upgrade) , not OS upgrade.
>
> Jerry,
> Your system is out of service. That means you won't be able to get *for
> free* any PTFs released after EOS date. That means your system may not
> recognize z14 correctly. It does NOT mean it won't work at all, but
> there's a risk.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2019-01-07 o 14:01, Richards, Robert B. pisze:
> >
> https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=gpateam&supplier=897&letternum=ENUS218-458
> >
> > IBM Customized Offerings Driver V3.1, a prebuilt, stand-alone driving
> system to meet IBM z/OS installation requirements, has been updated.
> >
> > The IBM(r) Customized Offerings Driver is a prebuilt, stand-alone
> driving system that can be used to install z/OS(r) ServerPac, z/OS
> SystemPac (in dump-by-dataset format, where available), and z/OS
> Custom-Built Product Delivery Offering (CBPDO) packages when you do not
> have a driving system that meets the minimum requirements for IBM z/OS
> installation. The Customized Offerings Driver is updated and is now a
> subset of a z/OS V2.2 system with Job Entry Subsystem 2 (JES2) that can run
> on any IBM Z(r) processor that is supported by z/OS V2.2, or later.
> >
> > The Customized Offerings Driver requires three 3390-9 or larger DASD
> volumes, a non-Systems Network Architecture (SNA) terminal or Hardware
> Management Console (HMC) 3270 emulator for a z/OS console, and an SNA
> terminal for a Time Sharing Option Extended (TSO/E) session. The Customized
> Offerings Driver is delivered on DVD media.
> >
> > For up-to-date information about the Customized Offerings Driver,
> including supported media, DASD volume sizes, product levels included, z/OS
> hardware and software prerequisites, and driving system requirements, see
> the current z/OS PSP bucket (Upgrade ZOSV2R3, Subset ZOSGEN) and z/OS
> Planning for Installation (GA32-0890) at the z/OS Internet Library.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Edgington, Jerry
> > Sent: Monday, January 07, 2019 7:57 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: z/OS 1.12 question
> >
> > As anyone upgraded a z/OS 1.12 from zBC10 to z14, directly?  If so, what
> issues or gothas were there? Anything to look at for? If not, any ideas of
> how to get z/OS and hardware upgrade to current.
> >
> > Thanks,
> > Jerry Edgington
> >
> > --
> > 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
> > .
> >
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2018 r. wynosi 169.248.488 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169,248,488 as at 1 January 2018.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@lists

Re: z/OS 1.12 question

[Joe Monk]

I dont see why he couldnt install z/OS 1.13 on the old box, then move that
to the new box and upgrade...

Joe

On Mon, Jan 7, 2019 at 1:37 PM Ed Jaffe  wrote:

> On 1/7/2019 5:47 AM, Edgington, Jerry wrote:
> > Our current situation is, we have zBC10 running z/OS v1.12.  We want to
> upgrade everything to current, including z/OS and hardware.  I understand
> we can't get support for either z/OS or zBC12, but I am looking for options
> and if anyone has successfully done this type of upgrade. If so, what steps
> were taken?
> >
> > - Can we get maintenance for z/OS v1.12, understanding we might have to
> pay IBM something for it?
> > - Will z/OS v1.12 work on z14, I understand the answer is maybe.  But,
> has anyone done it?  If so and willing to share, we would like to know
> > - If not, we are looking at the possibility of move z/OS v1.12 to zBC12,
> upgrade to z/OS v2.3, then z14.  Again, we probably would need maintenance
> on z/OS v1.12
>
> Must it be a push/pull install of the hardware? Or can you install the
> new z14 side-by-side with the z10 connected to the same DASD?
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS 1.12 question

[Joe Monk]

Probably not if you dont already have a support contract. BUT - You could
LPAR your current machine, install z/os like 2.1 or so , upgrade then move
and upgrade again.

Joe

On Mon, Jan 7, 2019 at 1:57 PM Edgington, Jerry <
jerry.edging...@westernsouthernlife.com> wrote:

> Is z/OS v1.13 still orderable from IBM?  That might be a path, if we can
> get the code base with all the necessary features.  Thanks.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Monk
> Sent: Monday, January 07, 2019 2:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 1.12 question
>
> I dont see why he couldnt install z/OS 1.13 on the old box, then move that
> to the new box and upgrade...
>
> Joe
>
> On Mon, Jan 7, 2019 at 1:37 PM Ed Jaffe 
> wrote:
>
> > On 1/7/2019 5:47 AM, Edgington, Jerry wrote:
> > > Our current situation is, we have zBC10 running z/OS v1.12.  We want
> > > to
> > upgrade everything to current, including z/OS and hardware.  I
> > understand we can't get support for either z/OS or zBC12, but I am
> > looking for options and if anyone has successfully done this type of
> > upgrade. If so, what steps were taken?
> > >
> > > - Can we get maintenance for z/OS v1.12, understanding we might have
> > > to
> > pay IBM something for it?
> > > - Will z/OS v1.12 work on z14, I understand the answer is maybe.
> > > But,
> > has anyone done it?  If so and willing to share, we would like to know
> > > - If not, we are looking at the possibility of move z/OS v1.12 to
> > > zBC12,
> > upgrade to z/OS v2.3, then z14.  Again, we probably would need
> > maintenance on z/OS v1.12
> >
> > Must it be a push/pull install of the hardware? Or can you install the
> > new z14 side-by-side with the z10 connected to the same DASD?
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > https://www.phoenixsoftware.com/
> >
> >
> >
> > --
> > -- This e-mail message, including any attachments, appended
> > messages and the information contained therein, is for the sole use of
> > the intended recipient(s). If you are not an intended recipient or
> > have otherwise received this email message in error, any use,
> > dissemination, distribution, review, storage or copying of this e-mail
> > message and the information contained therein is strictly prohibited.
> > If you are not an intended recipient, please contact the sender by
> > reply e-mail and destroy all copies of this email message and do not
> > otherwise utilize or retain this email message or any or all of the
> > information contained therein. Although this email message and any
> > attachments or appended messages are believed to be free of any virus
> > or other defect that might affect any computer system into which it is
> > received and opened, it is the responsibility of the recipient to
> > ensure that it is virus free and no responsibility is accepted by the
> > sender for any loss or damage arising in any way from its opening or use.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> 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: BALR and BAL in AMODE=24

[Joe Monk]

In the 370 days, thats how we used to establish addressability! A BALR to a
register with a zero in the link position merely loads the PSW instruction
address into a register, like this:

BALR 15,0
USING *,15

Joe

On Tue, Jan 22, 2019 at 6:44 AM John Gateley 
wrote:

> Hello.
>
> The link information in the 24-bit addressing mode consists of the
> instruction-length code (ILC), the condition code (CC), the program-mask
> bits, and the rightmost 24 bits of the updated instruction address.
>
> I have never given much thought to the high byte when using this
> instruction and switched to BASR and BAS years ago.
>
> Just for personal interest, does anyone recall a program using the
> contents of the link register other than as a return address?
>
> Thanks for any replies.
> John
>
> --
> 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: CICS IR I/O wait time (inter-region (MRO) I/O wait)

[Joe Monk]

Do you have CICS Performance Analyzer? If so, a cross system work report
will answer this question.

Joe

On Mon, Jan 28, 2019 at 2:48 AM Mehrshad Manshadi <
0056e0e17177-dmarc-requ...@listserv.ua.edu> wrote:

> Hi,
> The IRIOWTT(Interregion I/O wait time) time is very high(14 min).
> Would you please help me to know the cause and which parameter i should
> control to prevent this issue?
>
>
> --
> 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: ICKDSF QUESTION

[Joe Monk]

The Syntax for ICKDSF is:

FLASHCPY WITHDRAW UNIT(CCUU) TARGETVOL(LSS,CCA,CCUU)

Example:

FLASHCPY WITHDRAW UNIT(5C06) -
TARGETVOL(X'01', X'07',5C87)

Joe






On Fri, Feb 1, 2019 at 8:26 AM esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

>  I noticed that the jcl was misaligned.  I don't know why. I will try to
> fix the problem.
>  /* //STEP1EXEC
> PGM=ICKDSF,REGION=4M   //SYSPRINT DD   SYSOUT=*
>  //SYSINDD * FLASHCPY WITHDRAW SDEVN(816B)
> TDEVN(6B5F) /*
> Job output :
>  FLASHCPY WITHDRAW SDEVN( 816B) TDEVN(6B5F)
>   ICK30211I KEYWORD 'SDEVN' IS IMPROPER
>  ICK30202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS 12
>   ICK2I
> ICKDSF PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 12
>
> On Friday, February 1, 2019, 7:11:55 a.m. EST, esmie moo <
> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
>
>
> --
> 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: Friday history query

[Joe Monk]

Curtis,

Any chance we could get some more info? Who was the signer? Is there any
address/location info on the letter?

Thanks!

Joe

On Fri, Feb 8, 2019 at 6:55 PM Pew, Curtis G 
wrote:

> Since it’s Friday, I’ll go ahead and ask about this.
>
> My father, who passed away last spring, worked for IBM from about 1959 to
> 1978. My mother was going through some things this week and found a letter
> of commendation he received for work with something called the “GEM
> Operating System Group” in early 1966.
>
> Googling variations on “GEM Operating System Group” only turns up things
> much more recent, so I was wondering if someone on this list might have
> heard of it and be able to point me to more information.
>
> Thanks.
>
>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
>
>
>
>
>
>
> --
> 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: Abend 052-512

[Joe Monk]

Problem 1: Youre not setting R13 to the 18 word save area required by the
macro...
Input register information
The AXSET macro is sensitive to the SYSSTATE macro with the OSREL=ZOSV1R6
parameter

   - If the caller has issued the SYSSTATE macro with the OSREL=ZOSV1R6
   parameter (Version 1 Release 6 of z/OS® or later) before issuing the AXSET
   macro, the caller does not have to place any information into any general
   purpose register (GPR) unless using it in register notation for a
   particular parameter, or using it as a base register.
   - Otherwise, the caller must ensure that the following general purpose
   register contains the specified information:*Register**Contents*13The
   address of an 18-word save area

Output register information

After the caller issues the macro, the macro might use some registers as
work registers or might change the contents of some registers. When the
macro returns control to the caller, the contents of these registers are
not the same as they were before the macro was issued. Therefore, if the
caller depends on these registers containing the same value before and
after issuing the macro, the caller must save these registers before
issuing the macro and restore them after the system returns control.
When control returns to the caller, the general purpose registers (GPRs)
contain: *Register**Contents*0Bits 0-15 contain zeros; bits 16-31 contain
the replaced Authority Index (AX)1Used as a work register by the macro2-13
Unchanged14Used as a work register by the macro15Return code
Abend 052-512 is that the linkage register is already in use. R2 points to
the incorrect LX. So, you need to check your call to the macro ...

In this case, R2 is pointing to zero. Chances are it is because youre not
supplying the save area. Otherwise, the abend is telling you that R0 is not
valid...

Joe



On Sun, Feb 10, 2019 at 8:36 AM esst...@juno.com  wrote:

>  I can't provide the entire program due to some contractual agreements.
> So here is what I can show.There is only one AXSET and one LXRES macro in
> this module.ANd yes the Dump has AXSET using R0, I did subsequently change
> it to use R1.
> *---*
> *   Switch To Supervisor State
> *---*
>  MODESET MODE=SUP
> *---*
> *   Set the Address Space AX to a value of 1
> *---*
>  MVC   XMSFUNC,=CL8'AXSET   '
>  LAR1,1Request AX Value of 1
>  AXSET AX=(R1)
>  STR15,RETURNCODE  Save Return Code From XMS Call
>  BRAS  R14,COMPLETION_CODE_CHECK
>  *---*
>  *   Reserve a Extended System LX
>  *---*
>   MVC   XMSFUNC,=CL8'LXRES   '
>   MVC   XMSZLIST,LXRES00Reentrant LXRES Parameter List
>   LHI   R0,1Request 1 LX
>   STR0,LXCOUNT  Request 1 LX
>   LXRES ELXLIST=ELXL,SYSTEM=YES,REUSABLE=YES,LXSIZE=23,**
> MF=(E,XMSZLIST)
>   STR15,RETURNCODE  Save Return Code From XMS Call
>   BRAS  R14,COMPLETION_CODE_CHECK
>  *---*
>  *   Create an Entry Table that defines the PC Service Routines
>  *---*
>   MVC   XMSFUNC,=CL8'ETCRE   '
>   L R0,ETDESC@  Entry Description Table Address
> .
> .
> Here Are the Registers at Abend
> .
>SYSTEM COMPLETION CODE=052  REASON CODE=0512
>
> TIME=08.59.14  SEQ=04271  CPU=  ASID=001C
>
> PSW AT TIME OF ERROR  070C   8AD08E9A  ILC 2  INTC 0D
>
>   NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
>
>   NAME=UNKNOWN
>
>   DATA AT PSW  0AD08E94 - C02818F8  0A0DA788  18FB
>
>   AR/GR 0: 006FDD40/_0AD099C0   1: /_84052000
>
> 2: /_   3: /_FF03
>
> 4: /_00FDC400   5: /_
>
> 6: /_00FF4500   7: /_00FB9100
>
> 8: /_0512   9: /_0BE0
>
> A: /_00FBBD00   B: /_00FB9100
>
> C: /_0AD099C0   D: /_7FF97378
>
> E: 0103/_8AD08E8A   F: 0102/0002_0512
>
> END OF SYMPTOM DUMP
> .
> .
> .
> .
> From the bottom of the Trace -  I found the last SVCE
> then I located the previous PC instruction
> .
> .
>  0009 006F8188  I/O  00258 _0AD14996  00C04007 738DF028
> 0C00  00
>

Re: Abend 052-512

[Joe Monk]

Peter,

AXSET specifically says it is subject to 052...

ABEND codes

   - 052
   - 053


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa100/iea3a1_AXSET_Set_authorization_index.htm

Joe

On Sun, Feb 10, 2019 at 8:12 AM Peter Relson  wrote:

> You would not get 052-512 on AXSET.
>
> It is issued only on ETCON.
>
> 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: Abend 052-512

[Joe Monk]

One other thing ... The AX used in the AXSET macro must have been
previously AXRES'd prior to being used in the AXSET macro

"The caller can use the value returned by the system as an AX through the
AXSET macro, or as an extended authorization index (EAX) through the ETDEF,
ETCRE, and ETCON macros. The AX value associated with a program determines
whether that program is permitted to issue the PT instruction with another
address space as the target, and/or set another address space as its
secondary address space through the SSAR instruction. The EAX value
determines whether a program running with the EAX can access data in
another address space through a private access list entry"

Joe

On Sun, Feb 10, 2019 at 8:36 AM esst...@juno.com  wrote:

>  I can't provide the entire program due to some contractual agreements.
> So here is what I can show.There is only one AXSET and one LXRES macro in
> this module.ANd yes the Dump has AXSET using R0, I did subsequently change
> it to use R1.
> *---*
> *   Switch To Supervisor State
> *---*
>  MODESET MODE=SUP
> *---*
> *   Set the Address Space AX to a value of 1
> *---*
>  MVC   XMSFUNC,=CL8'AXSET   '
>  LAR1,1Request AX Value of 1
>  AXSET AX=(R1)
>  STR15,RETURNCODE  Save Return Code From XMS Call
>  BRAS  R14,COMPLETION_CODE_CHECK
>  *---*
>  *   Reserve a Extended System LX
>  *---*
>   MVC   XMSFUNC,=CL8'LXRES   '
>   MVC   XMSZLIST,LXRES00Reentrant LXRES Parameter List
>   LHI   R0,1Request 1 LX
>   STR0,LXCOUNT  Request 1 LX
>   LXRES ELXLIST=ELXL,SYSTEM=YES,REUSABLE=YES,LXSIZE=23,**
> MF=(E,XMSZLIST)
>   STR15,RETURNCODE  Save Return Code From XMS Call
>   BRAS  R14,COMPLETION_CODE_CHECK
>  *---*
>  *   Create an Entry Table that defines the PC Service Routines
>  *---*
>   MVC   XMSFUNC,=CL8'ETCRE   '
>   L R0,ETDESC@  Entry Description Table Address
> .
> .
> Here Are the Registers at Abend
> .
>SYSTEM COMPLETION CODE=052  REASON CODE=0512
>
> TIME=08.59.14  SEQ=04271  CPU=  ASID=001C
>
> PSW AT TIME OF ERROR  070C   8AD08E9A  ILC 2  INTC 0D
>
>   NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
>
>   NAME=UNKNOWN
>
>   DATA AT PSW  0AD08E94 - C02818F8  0A0DA788  18FB
>
>   AR/GR 0: 006FDD40/_0AD099C0   1: /_84052000
>
> 2: /_   3: /_FF03
>
> 4: /_00FDC400   5: /_
>
> 6: /_00FF4500   7: /_00FB9100
>
> 8: /_0512   9: /_0BE0
>
> A: /_00FBBD00   B: /_00FB9100
>
> C: /_0AD099C0   D: /_7FF97378
>
> E: 0103/_8AD08E8A   F: 0102/0002_0512
>
> END OF SYMPTOM DUMP
> .
> .
> .
> .
> From the bottom of the Trace -  I found the last SVCE
> then I located the previous PC instruction
> .
> .
>  0009 006F8188  I/O  00258 _0AD14996  00C04007 738DF028
> 0C00  00
>07045000 8000   00F2AFC8
> 0042  00
>  001C 022BBD00  SRB_01084868  001C 0266EF00
> 0266EF2C
>0704 8000  006FDD40 80
>
>  001C 022BBD00  SSRV78  80C4ADA8  0050E503 1000
> 7F538000
>   001C
>
>  001C 022BBD00  SSRV 2  80FEE77C  006F8168 7F00
> 
>   
>
>  001C 006FF1C0  DSP_0AD04F3E   00011000
> C17D  00
>0784 8000
>
>  001C 006FF1C0  PC ...   8  0AD04992  4
>
>  001C 006FF1C0  DSP_0AD07650   0001
> 0AD01440  00
>0704 8000
>
>  001C 006FF1C0  SSRV78  8AD076BE  FF02 0888
> 7FF97378
>   0002
>
>  001C 006FF1C0  SSRV78  8AD08E72  FF03 0888
> 7FF97378
>   0002
>   001C 006FF1C0 *S

Re: MQ7 on a Z14

[Joe Monk]

Isnt MQ7 restricted to z/os 1.x? The z14 only runs z/os 2.x and above ...
so you'd have to goto MQ8 or MQ9...

Joe

On Fri, Feb 15, 2019 at 10:28 AM Meehan, Cheryl  wrote:

> Hello-
>
> We are about to embark on an upgrade from a BC12 to a Z14.
>
> Does anyone know of any issues with MQ7 running on a Z14 ?
>
> Regards,
>
> Cheryl Meehan
> Sr. Systems Engineer
> (603)354-7557
> cmee...@cswg.com
>
>
> --
> 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: Anyone ever seen/hear about a set of programs called SUPERCOP/SUPCOP1/SUPCOP2/SUPCOP3

[Joe Monk]

Maybe its this?

http://bench.cr.yp.to/supercop.html

Joe

On Sat, Feb 23, 2019 at 9:17 PM Feller, Paul 
wrote:

> Has anyone ever seen/hear about a set of programs called
> SUPERCOP/SUPCOP1/SUPCOP2/SUPCOP3.  We ran into an issue with these programs
> related to EAV volumes.  It seems we acquired these programs as part of a
> merger many years ago.  No one seems to have any idea where the source
> could be.  From what we can tell these may have been some freeware
> programs, but can't say for 100%.  We searched the CBT website and did some
> Google searches but could not find anything to help us.
>
> I would be interested in hearing from anyone that happens to know about
> these programs and has source.
>
> As a side note with the use of the ASMDASM program and some detective work
> we determined what was causing the issue and was able to ZAP the program
> SUPCOP1 to fix the issue.  It would be nice to have source for any future
> issues.
>
> Thanks..
>
> Paul Feller
> AGT Mainframe Technical Support
>
>
>
>
> --
> 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: calling a webservice using HTTPS from batch (and CICS)

[Joe Monk]

Bernd,

There is a CICS sockets interface for the C language. Ive written code in
it.

Joe

On Sun, Mar 10, 2019 at 11:55 AM Bernd Oppolzer 
wrote:

> Hello all,
>
> some months ago, I wrote a program which allows to call webservices
> (HTTP POST or HTTP GET)
> from batch programs, written in C or PL/1. The program (subroutine) is
> written in C
> and uses the standard TCP/IP socket interface, available in the
> classical z/OS environment.
> I am doing all the conversion work myself, and I build the necessary
> HTTP headers, and
> analyze them on return. This works without problems.
>
> When running under CICS, I provide the same interface to the callers,
> but I use the
> EXEC CICS WEB CONVERSE calls instead (because CICS does not allow me to do
> standard socket calls, when under CICS control).
>
> Now the problem is: I am limited to HTTP at the moment, but customer's
> politics
> requires me to do HTTPS in the middle and long term.
>
> I have no idea what I need to do to provide HTTPS communication in the
> batch and
> in the CICS case; what are my options and what is the easiest migration
> path?
>
> Thank you all,
> kind regards
>
> Bernd
>
> --
> 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: How to obtain DSN's on a cartridge on SL laber format

[Joe Monk]

UNIT = 3490, LABEL = (, BLP, EXPDT = 98000),

theres your answer right there. BLP = bypass label processing.

Youre getting these messages:

IEC502E R 0580, S03815, SL, TAPEMAP, STEP0010
IEC501A M 0580, TAPAWS, NL ,, TAPEMAP, STEP0010, AMSOURCE.AWS

because you are not authorized to use BLP. So, you need to check and be
sure that you can use BLP. Since youre not authorized for BLP, the system
is changing it to NL.

Otherwise, I'd suggest you use DITTO.

Joe


On Wed, Mar 13, 2019 at 7:22 AM Hilario Garcia  wrote:

> I am trying to use the TAPEMAP utility downloaded from the web
> .cbttape.org and
> I want to use it on some cartridges that have several files in "standard
> label" (SL) format
> but I do not know the DSN of them.
>
> I would like to be able to obtain a TAPEMAP report with the content of the
> files in the cartridge.
>
> I am using the following jcl:
>
> // STEP0010 EXEC PGM = TAPEMAP
> // STEPLIBDD DSN = CBTTAPE.LINKLIB, DISP = SHR
> // SYSPRINT DD SYSOUT = *
> // AMSDUMP DD SYSOUT = *
> // SYSUT1DD DSN = AMSOURCE.AWS, DISP = (OLD, PASS),
> //UNIT = 3490, LABEL = (, BLP, EXPDT = 98000),
> //   VOL=(, RETAIN,,SER=TAPAWS)
>
> I receive the following messages:
>
> IEF233A M 0580, TAPAWS ,, TAPEMAP, STEP0010, AMSOURCE.AWS
> IEC502E R 0580, S03815, SL, TAPEMAP, STEP0010
> IEC501A M 0580, TAPAWS, NL ,, TAPEMAP, STEP0010, AMSOURCE.AWS
>
> How should I modify the jcl to solve the problem and get the list of all
> the DSNs?
> in the cartridges.
>
> Thank you very much in advance.
>
> regards
>
> Hilario
>
> --
> 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: AMODE 32

[Joe Monk]

"PSW bit 30 can be used to signify that an
application is running AM32."

Whats the ROI to the customer for IBM spending the $$$ to research and
modify all of the micro/macro/OS code to allow bit 30 to be anything other
than 0?

You have to realize that the prices are going to increase to cover those
costs from IBMs point of view... Its not a one man job to allow that to
happen.

Joe

On Wed, Apr 3, 2019 at 7:18 PM Paul Edwards  wrote:

> I was thinking that z/Arch and z/OS could
> be updated to support AMODE 32.
>
> If a load module is marked AMODE ANY,
> RMODE ANY it could signify that it is
> 32-bit clean. That combination is
> currently not really used, and the linker
> can be updated to accept this combination.
>
> PSW bit 30 can be used to signify that an
> application is running AM32.
>
> The BSM instruction can use bit x'4000 '
> to get/set AM32. This introduces a 1 GiB
> restriction where the module should not
> be loaded above if it needs to switch
> AMODEs to call READ etc. But that's another
> restriction that could be lifted in z/OS.
> z/OS can instead switch to AM31 itself,
> with the READ code being located below 1 GiB.
>
> BFN. 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: AMODE 32

[Joe Monk]

" I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications."

The market disagrees with you, as shown by 64-bit z/arch sales.

Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> wrote:
>
> >What problem would this solve?
>
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
>
> >This would be of zero use for existing applications,
>
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
>
> BFN. 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: AMODE 32

[Joe Monk]

" I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications."

"According to the analyst deck
 circulated
with the latest set of quarterly financials, the IBM Z mainframe business,
listed under its ‘systems segment’ has doubled year-on-year, pulling in a
tidy US$2.2 billion ($2.96 billion)

Overall revenue rose nearly 4 percent to US$20 billion ($26.9 billion),
beating analysts’ average estimate of $19.85 billion ($26.7 billion),
according to Thomson Reuters I/B/E/S."

https://www.itnews.com.au/news/mainframe-sales-double-in-latest-ibm-profit-498679

Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> wrote:
>
> >What problem would this solve?
>
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
>
> >This would be of zero use for existing applications,
>
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
>
> BFN. 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: AMODE 32

[Joe Monk]

" As far as I am aware, if you do a:

CALL xxx,VL

to set the high bit to signify end of parameter
list, then if the target is operating in AM64, it
will fail with a S0C4."

Nope. You will get this error:

12,*** IHB280 VL INVALID WITH 8_BYTE_ENTRY_PLIST

Joe

On Thu, Apr 4, 2019 at 11:18 AM Paul Edwards  wrote:

> I'm sorry I don't understand your technical point.
> Could you rephrase?
>
> As far as I am aware, if you do a:
>
> CALL xxx,VL
>
> to set the high bit to signify end of parameter
> list, then if the target is operating in AM64, it
> will fail with a S0C4.
>
> BFN. Paul.
>
>
>
> On Thu, 4 Apr 2019 15:12:24 +, Gene Hudders  wrote:
>
> >Again I am sorry but at this point I believe you cannot issue a CALL for
> a program in 64 bits. I do nothing when switching back and forth with my
> CALLs.
> >
> >In a message dated 4/4/2019 11:09:16 AM Venezuela Standard Time,
> mutazi...@gmail.com writes:
> >
> >On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders 
> wrote:
> >> I'm sorry, but I don't have to make any changes> to my 31 bit programs
> using CALLs and using> 64-bit addressing. We have lots of programs> doing
> both AM31 and AM64 with the only change> is the instructions to change the
> addressing mode.
> >If you are changing addressing mode to31-bit, so that you can cope with
> thex'80' bit in a CALL, then you would needto do the same thing with an
> AM32program.
> >> Do you realize how many user programs that> have CALLs embedded in the
> code that would> require eliminating the HO X'80' bit?
> >A problem that exists when trying toconvert to pure AM64 too.
> >BFN. 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
>
> --
> 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: AMODE 32

[Joe Monk]

"I'm trying to understand why some sites
are running multiple CICS regions because
2 GiB is not enough. Yet they haven't
gone to AM64..."

Who is going to pay for programmer time to convert applications to 64-bit?
The cost of running mulitple 2GB regions is less than the cost to convert
the applications, debug and test them.

Joe

On Fri, Apr 5, 2019 at 12:55 PM Paul Edwards  wrote:

> Hi Mike.
>
> I'm trying to understand why some sites
> are running multiple CICS regions because
> 2 GiB is not enough. Yet they haven't
> gone to AM64. I want to know if they
> would be interested in going to AM32
> instead, if it were available. Can you
> elaborate? If AM32 was more practical
> for them, they would be able to halve
> the number of CICS regions they have.
>
> BTW, Rob Prins recently updated his
> 47,000-line RPF assembler program to
> make it AM32-clean, and it required
> very little effort. He was using "VL" in
> a variety of places, but the things he
> was calling were not actually variable
> parameter functions, so he just needed
> to delete the VL. No rewrite was
> necessary, as would be required if
> moving to AM64.
>
> Thanks. Paul.
>
>
>
>
> On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab 
> wrote:
>
> >If you are wanting to run in AM64 and use 32 bit constants, that is
> >certainly possible.  You will then be limited to incrementing
> >registers by 4GiB or less.  Just establishing addressability will need
> >to set all 64 bits.
> >
> >On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
> >>
> >> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer <
> martin_pac...@uk.ibm.com> wrote:
> >>
> >> >They will be (running 64-bit). However, apart from Db2*, much of their
> >> >virtual storage components can't tolerate being above the bar.
> >>
> >> Which virtual storage components can't tolerate
> >> being above the bar, and why is that and what
> >> would need to change?
> >>
> >> Thanks. Paul.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >--
> >Mike A Schwab, Springfield IL USA
> >Where do Forest Rangers go to get away from it all?
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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: AMODE 32

[Joe Monk]

At minimum, a recompile/reassemble. Takes machine time and programmer time.

Amode 32 doesn't exist so I'm not worried about that.

Joe

On Fri, Apr 5, 2019, 4:03 PM Paul Edwards  wrote:

> On Fri, 5 Apr 2019 15:55:42 -0400, Joe Monk  wrote:
>
> >> I'm trying to understand why some sites
> >> are running multiple CICS regions because
> >> 2 GiB is not enough. Yet they haven't
> >> gone to AM64..."
> >
> > Who is going to pay for programmer time to convert applications to
> 64-bit?
> > The cost of running mulitple 2GB regions is less than the cost to convert
> > the applications, debug and test them.
>
> Ok, thanks for that. So what programming
> effort would be required to convert them
> to AM32? What language are these programs
> likely to be written in?
>
> 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: z114 and z/OS 2.3

[Joe Monk]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zb100/osproc.htm

"z/OS V2R3 is not supported on the following servers:

   - IBM zEnterprise 196 (z196)
   - IBM zEnterprise 114 (z114)
   - IBM System z10® Enterprise Class (z10™ EC)
   - IBM System z10 Business Class (z10 BC)
   - IBM System z9® Enterprise Class (z9 EC)
   - IBM System z9 Business Class (z9 BC)
   - IBM eServer™ zSeries 990 (z990)
   - IBM eServer zSeries 890 (z890)
   - IBM eServer zSeries 900 (z900)
   - IBM eServer zSeries 800 (z800)."

They may be doing it, but not in a supported way.

Joe

On Sat, Apr 6, 2019 at 8:21 AM Jim Stefanik 
wrote:

> That is very odd. The same VM guest starts up fine on an EC12 and newer,
> but anything older than that fails.  z/VM and z/OS are both at the latest
> release level with all current maintenance.
>
>
> Now I'm curious what the secret sauce is to make that work.
>
>
>
> ---
>
> Jim Stefanik
> Dallas Vintage Computing Center
> 
> From: Brian Westerman 
> Sent: Saturday, 6 April 2019 01:49
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z114 and z/OS 2.3
>
> I wonder how I will explain that to the 4 sites that we have running 2.3
> under z/VM.  Maybe your version of z/VM doesn't support it, but 4 separate
> sites is fairly conclusive:)
>
> actually only 3 of them are z114's the other one is a bc10.
>
> Brian
>
> --
> 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: z114 and z/OS 2.3

[Joe Monk]

The minimum ARCH for z/os 2.3 is ARCH=10 (zEC12/zBC12, z13/z13s, z14)

z114 is not in ARCH=10, so thats why everyone is confused...

Joe


On Sun, Apr 7, 2019 at 1:55 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Well,
>
> Tell me what you want dumped and I'll get it to you.  All of the sites are
> merely waiting for their new hardware to be delivered and since all of them
> were already running z/VM I installed from their z/OS 1.13 client machine
> (one was z/OS 1.10) and they all came up fine on the first try.  I don't
> think anyone did anything "special" but I'm not a z/VM guy so my job begins
> and ends with the z/OS parts.
>
> None of them will be production until the new hardware gets here, but it
> does allow me to continue their migration without waiting for the new box
> to be delivered and set up.
>
> Brian
>
> --
> 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: LU2 type sample logmode

[Joe Monk]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.istrdr0/deflogt.htm#deflogt

Usually D4A32782 or SNX32702 is pretty good...

Joe

On Sun, Apr 21, 2019 at 1:46 AM Jake Anderson 
wrote:

> Hi
>
> Are there a IBM supplied LU2 type logmode for tso logon ?
>
> I am looking for a sample definition to build a TSO LU2 type definition.
>
> Any pointers are much appreciated
>
> Jake
>
> --
> 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: LU2 type sample logmode

[Joe Monk]

He says he's getting prog723 so he can't do negotiated bind.

Joe

On Mon, Apr 22, 2019, 11:32 AM Seymour J Metz  wrote:

> There are many. What screen geometries do you want to support?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jake Anderson 
> Sent: Sunday, April 21, 2019 2:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LU2 type sample logmode
>
> Hi
>
> Are there a IBM supplied LU2 type logmode for tso logon ?
>
> I am looking for a sample definition to build a TSO LU2 type definition.
>
> Any pointers are much appreciated
>
> Jake
>
> --
> 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: LU2 type sample logmode

[Joe Monk]

SNX32704 is for a model 4.

SNX32702 is for a model 2.

Joe

On Tue, Apr 23, 2019 at 4:21 AM Peter  wrote:

> Mike
>
> Thank you so much
>
> The scenario is we are trying to access a TSO from a Netmaster.
>
> So we receive this sense code in netmaster log
>
> Also some IBM PCOMM users do complaint about x'723 but when I check the LOG
> I see 08570003.
>
> So the question is whether the LU2 type SNX32704 is not correct or the TSO
> LU at the target LPAR is not ACTIV ?
>
>
>
> On Tue, 23 Apr, 2019, 12:11 PM Wawiorko, Mike : Infrastructure Services, <
> 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:
>
> > You can look up return code and feedback2 in the SNA messages and codes
> > manual (or maybe SNA programming).
> >
> > However, NetView RCFB 10 00 is quicker and gives this:
> >
> > CNMR1000 RTCD FDBK2   Page 1
> > of 2
> >  X'10'(16)0
> >
> > Logical unit not available, application program status not
> > available, queued BIND not available, or incorrect dial
> > parameters
> > This code is set for one of the following reasons:
> > o   You are attempting to establish a session with a
> > logical unit that is not active.
> > o   You are attempting to pass a logical unit to a primary
> > logical unit that is not active (or is in the process
> > of being deactivated).
> > o   You are attempting to issue an OPNSEC macroinstruction
> > and there is no queued BIND request to respond to.
> > o   You are attempting to determine the status of an
> > application program that is in another domain, the
> > status is not available, and your application program
> > has to proceed without it.
> > o   You issued a SIMLOGON macroinstruction that specifies
> > dial parameters for a nonswitched PU.
> >
> > CNMR10X0 RTCD FDBK2   Page 2
> > of 2
> >  X'10'(16)0
> >
> > o   The dial parameters specified in the SIMLOGON
> > macroinstruction do not match the original dial
> > parameters.
> > The RPL system-sense (SSENSEI), the system-sense modifier
> > (SSENSMI), and the user-sense (USENSEI) can contain a more
> > detailed explanation of the failure.
> >
> > Mike Wawiorko
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Peter
> > Sent: 23 April 2019 05:24
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: LU2 type sample logmode
> >
> >
> > This message originated from outside our organisation and is from web
> > based email - dbajava...@gmail.com
> >
> > This time when I do with SNX32704
> >
> > I get
> >
> >  the request fails with return code 10 , Fbk2=00, sense=8570003.
> >
> > I know 8570003 comes up for CONCT status of LU. but what does it mean by
> > FBK2=00 and return code 10 ?
> >
> >
> >
> >
> _
> >
> > This message is for information purposes only, it is not a
> recommendation,
> > advice, offer or solicitation to buy or sell a product or service nor an
> > official confirmation of any transaction. It is directed at persons who
> are
> > professionals and is not intended for retail customer use. Intended for
> > recipient only. This message is subject to the terms at:
> > www.barclays.com/emaildisclaimer.
> >
> > For important disclosures, please see:
> > www.barclays.com/salesandtradingdisclaimer regarding market commentary
> > from Barclays Sales and/or Trading, who are active market participants;
> and
> > in respect of Barclays Research, including disclosures relating to
> specific
> > issuers, please see http://publicresearch.barclays.com.
> >
> >
> >
> __
> > If you are incorporated or operating in Australia, please see
> > https://www.home.barclays/disclosures/importantapacdisclosures.html for
> > important disclosure.
> >
> >
> __
> >
> >
> __
> > How we use personal information  see our privacy notice
> >
> https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html
> >
> >
> 

Re: Ancient DASD connectivity

[Joe Monk]

The 3375 (CKD brother of the 3370 FBA) was attached thru a 3880 storage
control. There were A,B, and D units. The D units were the tails and the A
units were the heads. The D units provided a second path but couldnt be
attached to the same 3880 as the A unit of the string, nor could that 3880
be attached to the same channel as the 3880 of the A unit.

Joe

On Fri, May 17, 2019 at 3:56 PM Seymour J Metz  wrote:

> 3350 models C2 and C2F were tail of string units. As I recall, for 3375
> the C boxes included a control unit so it could attach directly to the
> channel.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Martin Packer 
> Sent: Friday, May 17, 2019 10:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ancient DASD connectivity
>
> And then there were double-ended strings of disks. 3350s? Just before my
> time, really.
>
> Martin Packer
>
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
>
> https://secure-web.cisco.com/1zkSbtFDHOQs-i0S-NWG9whv4u3IVZLV4iwAsKJoL2wW0OBmxiXP49rPpM1hT28C5b05szJKbesmdCwEEpD05FwEH50B6ARq7H4b8Zh6IJr0tPsuzoBPiFXQPDfQxYaPQYvyOvy4G4ln6n4_9ms5P4hMeiNmq_UYxcH9QVEOrWeEbnycJFVTjqY_VuZ2F1xvASndlQXGyymvVCnHH2aIspYvzxF-0v8HOHELGUtxn0k3au6EUwcA6JbLaxD8trjCjyKkhMbn2UTBk5SPRnwKUsrJkFPfKX_m0eFWLqK4Dpf_7hxz6bRU96J927VJx72fgLXSwle86AKD9TflIwL0F5YWlHRJ4iU607AikyfCE2ITitcGvm3snmAwlVhIt26GhilCuUJS5OFV9C9IrAF0iI3FXKM55EISaE0TLMl0ogj_jVq_hpJg6Cv8d12MymWJX/https%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Fmydeveloperworks%2Fblogs%2FMartinPacker
>
> Podcast Series (With Marna Walle):
> https://secure-web.cisco.com/17KFRTNtw8jfbbM3KsapTPl1kUL2e-A2T3RRirEQef-5zKhaDfIaoQ_kHlL0yVxsqdBBDxqf9CXdbupf2MnBsASYjnviXkJ9jRWLAC5v943HBI13uSh2iuQmpypV1xgZcxrt5ebRbKLdQZkY_BNXmjANax89CByWOJP7STOCVY7uwa6DHHuPGSLwwPa2dMb94riZ72R-fmAnpuWeGC01zG7qlp9uerNzhLgGHKIeQIEUPzm6gaNIXoTcPo4iLXm9wnlXFL-7ZJ91d7Bzjl7dJYj5fgHRjrSc0CaBv4OfZJ4BTd8akyp4TwyEpa8bUwDbqMIhtipc7LGiitUrTVmSzhK3vt2ZgiEt_nyHFFW42RBrSul6uEtbZKEdjmChauSiicHsmtpqltjfyEkP71GopsRXX0jJqxdXhZLnhnW6ekDnCO3tf05rhz_nSlVpPGA7Y/https%3A%2F%2Fdeveloper.ibm.com%2Ftv%2Fmpt%2F
>   or
>
>
> https://secure-web.cisco.com/1pQriJXHvVuThP0MiibJcjZPe99XVSGA8WIXKQWnnbEK60K2jHF9_I_b5NcG8qrUysHmYu4IaCDP9G2UOzIqYQUb7dBLJ02sIhkPnPIakC2kn4HehGcYblVT2oM6DfmZviasdke8CJiDf1YWoOcHZdDS5foOvVkuR7k9zEwD_fb-Kegv_pXrdLjF6BSSzoI98D4xr8xCUw-zjIFjew3TUxeZhkFlrIJerjVQaoNdWOo7CzKEkrgRzh-UuK_7_76_HY7Kh2aBn63ONaxP2Nt-2CNwKf_QPi2y4-IySqKvp7KyrcYDPu33ivqtcnHxuFp9UvxEzbKILV-2b_IqVhq08fqsDdvYBQyxZrP-XHsx7-pqmtWJTJQk71WA5nugG5ZtJBbmjkiHHd-MgjaS82K7xVnfY3FNi0mZsGjMIX4b909pJHeTJnu0HMU-OIEpwGDJl/https%3A%2F%2Fitunes.apple.com%2Fgb%2Fpodcast%2Fmainframe-performance-topics%2Fid1127943573%3Fmt%3D2
>
>
> Youtube channel:
> https://secure-web.cisco.com/1-SK3lE2EgsiE4OF0AoD5ULNOh2Fz_tyO-k4W60ndX3c6VFQjlBkkxbpfn4MpvEIaSlm5GI7vZ29LRnhBlFYkgmQZO3tJHPC_ax49nYsCpfw4knMzI6s3_KCx0M55RlORonHtJgl90mttVWoblAfIIcjxNgvG9zl_r5O-vFZ73ds0yJ_XeqA34PPXjQbXNJ986sBIAvd5Tu-ZHyECEkw5L-8VyXjn5F0ljxt-rTGa_YA8ADXp-IGOCUkt0h9WBwC_JMfeB8RR405hRrLUFCmTRwue45LSMEWOmeiq-i7SXrbWKB9qBm7Q1UgKR--N95bOOSR8B9M69Bxve_3-Obvmyv6Qbw2lWQcjZ8BjYSPgB8Repe1OxME27iHLTrV2p7m362cHxqxVYB17Wztqi5trWP1PPerMGXT_hNG8e0CN9jE/https%3A%2F%2Fwww.youtube.com%2Fchannel%2FUCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Seymour J Metz 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   17/05/2019 15:18
> Subject:Re: Ancient DASD connectivity
> Sent by:IBM Mainframe Discussion List 
>
>
>
> T A unit attached to a CU; it was the CU that attached directly to the
> channel. There is some overloaded nomenclature here; the control function
> of an A unit is entirely different from a control unit.
>
>
> --
> Shmuel (Seymour J.) Metz
>
> https://secure-web.cisco.com/192B_8vChSMEyndnDPZG4RNlm17VN3PY80ixM5PthJQg8MVIiqCvk9ByLRPOEMdWbZdqGwhf4ppFbu3Lu1yy9-DSjADiZM3jzcZ4UZOo_drGdzNjGpAjEJpZ9JLRrGARR_uXICqAlkz1Yov-GLPH8yR57rGEmecK6kz3PmnVnXrn0FuQO0BktLd5oYo0NkdzPMGQ59teedMN8CJ6sG-WVK9CHUcHTGJYS1ZdAHJLA85oxsmKA0m3obsoSufzR1CArcEmQoyq4F3aFPIZa7aC-ukShghPM2JEiKAM8d1iMop2PkRl3lvlhA_d71aBCSPuNh1-ViaUQhBT22zIYIys3lNRGcep-3yXPDvn2z4L58b2Vhtv-5f8hqyWhdIUM6xJ0CdX8qEVYPY-fxg4SGfkS3831zr_4754rutnDDNCVyeM/https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__mason.gmu.edu_-7Esmetz3%26d%3DDwIFAw%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3DBsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ%26m%3DsbtcjKhJzgcjkqtihVmO6CFwHrRj5q-KUW7yT03NU7Q%26s%3DUjmNKh0zJMgKPveYfD_9y2AfqLn86GvSJJsO6tUpx0Y%26e%3D
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Alan Altmark 
> Sent: Friday, May 17, 2019 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ancient DASD connectivity
>
> On Thu, 16 May 2019 15:26:45 +, Seymour J Metz  wrote:
> >Well, for some devices the CU and device were in the same box, e.g.,
> 2501.
>
> Yes.  

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Joe Monk]

If youre trying to run under TSO, did you compile with the INTERRUPT option?

Joe

On Sun, May 19, 2019 at 11:37 PM Mike Stramba  wrote:

> I'm trying to compile and run the PL/I ON ATTENTION interrupt example
> from the PLI prog guide ver 4 r4 (pg 542   / GI11-9145-03)
>
> The code contains an ON ATTENTION handler with a simple message and prompt
> :
>  and the main line is a simple endless loop.
>
> The goal was just to write an extremely primitive counter-tester,
> which the user can interrupt after X seconds to see what
> counting-performance had been achieved.
>
> When I run the program and then press my 3270 emulator attention key,
> the program just ends instead of the attention handler gaining
> control.
>
> The console log shows a SLIP TRAP X33E and X13E were matched.
>
> MVS system codes SA38-0665-30 says for 33E :
>  "During processing of a DETACH macro that specified a STAE=YES
> operand, the system found that the specified subtask had not completed
> processing"
>
> code 13E is :
>  "The task that created a subtask issued a DETACH macro for that
> subtask, specifying STAE=NO before the subtask ended.
>
> I ASSume the "subtask" is my test program ??
>
> And the "task" is  TSO ??
>
> Or maybe not :/
>
> How do I just get the ON ATTENTION handler to work ?
>
> Mike
>
> --
> 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

[Joe Monk]

I dont see why you cant just call IDCAMS in batch (regardless of the
language used) and get the file size from the catalog?

Joe

On Thu, May 14, 2020 at 1:16 PM Seymour J Metz  wrote:

> That wasn't what he wrote, but I agree that it could have been phrased
> better. Still, the question is relevant; if we (TINW) knew why the OP was
> asking and what was behind his question, we would be better positioned to
> address the underlying problem.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Thursday, May 14, 2020 1:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?"
> Well gee, I would guess because the application that needs to know is
> already written -- and it's written in COBOL.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Thursday, May 14, 2020 10:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> It is very common for someone with a problem to assume that it has to be
> fixed in a certain way, and to ask about that way rather than the actual
> problem. Asking for clarification never hurts, and often helps.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of
> Charles Mills [charl...@mcn.org]
> Sent: Thursday, May 14, 2020 1:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> Of course it does not matter to COBOL!
>
> But it might matter to one or more applications that might just happen to
> be
> written in COBOL!
>
> No disrespect @Gil but this kind of answer drives me crazy. One thinks
> about
> a problem. It is a big and complex problem with multiple unknowns and
> tradeoffs. There are many ways one might at least partially solve it. One
> thinks at length about all the tradeoffs. One finally drills down on one
> particular approach ... but wait! There is one detail necessary for the
> solution to work that one does not know.
>
> So one posts on IBMMAIN "how can a COBOL program running as a started task
> but not APF-authorized determine how many widgets are in a bushel?"
>
> And someone immediately replies "why would you want to do that?"
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, May 14, 2020 9:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there any z/OS API to get byte file size for non-VSAM,
> non-zFS, non-database files?
>
> On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote:
>
> >Thanks Lizette, I had forgotten about LISTDSI.  The context here was a
> need
> for an API callable from a batch COBOL program, but that could be done too,
> if somewhat clumsily due to the requirement for LISTDSI to be executed in a
> TSO environment.
> >
> >I sent my co-worker on a search at cbttape.org for something he could
> use.
> >
> Why?  Where does this matter to COBOL?
>
> The VTOC-based approaches give at least an upper bound, which might
> suffice for capacity calculations.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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: Schema will not load

[Joe Monk]

Could it be permissions? RACF? The userid that youre using in production
doesnt have permissions to load some element in the XML schema?

Joe



On Sat, May 16, 2020 at 3:59 PM Roberto Halais 
wrote:

> Listers:
> I am already at the end of searches and reading.
> We have a batch job that connects to an external site using XML.
> It works well in our test environment but we are getting an error when we
> execute in production.
> I have googled but haven't had any luck.
> Any idea would be welcomed.
> Thank you.
> When we try to execute we get the following:
> == NEW PAGE 
>  OSR file: /APPL/LCR/DOEP_eFile.osr
>  Number of schemas: 1
>  Schema file: /APPL/LCR/FinCEN_DOEP_eFile.xsd
>
>  0100
>  Ý--- Calling gxluInitOSRG ---¨
>  Ý--- Calling gxluLoadSchema ---¨ #1
>  FATAL - gxluLoadSchema Failure: Reason Code 7067
>  Ý--- Calling gxluControlOSRG ---¨
> 0  == Diagnostic Area: Begin ==
>  OIMA Address: 21e36f80
>  Last Return Code: 10
>  Last Reason Code: 7067
>  StringID Return Code: 0
>  StringID Reason Code: 0
>  Java Exception Condition Code: 0
>  Number of Error Messages: 0
>  Custom Message:
>  Java Exception Messages:
> :::@ycol: /APPL/LCR/FinCEN_DOEP_eFile.xsd
> d ==
> Ý--- Calling gxluTermOSRG ---¨
> = NEW PAGE 
> Options Report for Enclave main 05/15/20 8:33:15 PM
> Language Environment V02 R02.00
>
> --
> 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: Friday Follies/Why won't this work?/TSO Rant #387

[Joe Monk]

Check your message handling ...

Joe

On Fri, May 22, 2020 at 11:00 AM Seymour J Metz  wrote:

> 
>  I called my congressman and he said quote
>  I'd like to help you son, but you're too young to vote.
> 
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Friday, May 22, 2020 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Friday Follies/Why won't this work?/TSO Rant #387
>
> What is wrong with this Rexx? (I spent about two hours debugging before I
> solved it.) The problem is right here on this page: the answer is NOT
> something in RACF or JES2. It's not something missing: it's a sin of
> commission, not a sin of omission. The below will never work. That is, the
> output will always be RC = 4 , Msgs = MYMSGS.0 , Msg.1 = MYMSGS.1. Why?
>
> /* Rexx to test command/response */
> MyCart = "MyCart01"
> "CONSPROF SOLDISP(NO) SOLNUM(400)"
> "CONSOLE ACTIVATE"
> Address Console
> "CART" MyCart
> "$DQ"
> RC = GETMSG('MYMSGS.','SOL',MyCart,,1)
> Say "RC =" RC ", Msgs =" MYMSGS.0 ", Msg.1 =" MYMSGS.1
> "CONSOLE DEACTIVATE"
>
> 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: Move volcat to non sms volume

[Joe Monk]

By using the VOLUMES keyword on the IMPORT, and specifying a NON-SMS
managed volume...

https://www.ibm.com/support/pages/how-move-volcat-new-volume

Joe

On Sun, May 24, 2020 at 2:30 AM Gadi Ben-Avi  wrote:

> Hi,
> Our volcat (SYS1.VOLCAT.VGENERAL) was allocated on an SMS managed volume.
> We would like to move it to a Non SMS managed volume.
>
> The way I found was to export it and then import.
> How do I tell IMPORT to allocate it on a non SMS managed volume, and not
> on the storage class it was exported from?
>
> Thanks
>
> Gadi
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: GDG relative number updates

[Joe Monk]

GDG relative numbers are not resolved until allocation.

Joe

On Sat, May 30, 2020 at 3:41 AM Ron Hawkins 
wrote:

> I always thought JES2 resolved relative GDG numbers during job initiation.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Joseph Reichman
> Sent: Wednesday, 27 May 2020 11:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] GDG relative number updates
>
> Hi
>
> I have have my sdump file DSN as a GDG I save the dsn name in the variable
> portion of the SDWA I am wondering when the system updates the relative
> number is it after a close and when you open the dataset again  the number
> has been updated
>
> Thanks
>
> --
> 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: Punched cards and character set

[Joe Monk]

http://www.bitsavers.org/pdf/ibm/370/referenceCard/GX20-1850-7_System_370_Reference_Summary_Feb89.pdf

Pages 34-37 show the punch sequences for every EBCDIC character.

Joe

On Tue, Jun 2, 2020 at 10:48 AM Seymour J Metz  wrote:

> That's what the multipunch icon is for.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
> Sent: Tuesday, June 2, 2020 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Punched cards and character set
>
> On Tue, 2 Jun 2020 08:39:47 -0700, Charles Mills wrote:
>
> >> thousands of punched cards with no real way to read them anymore
> >
> >In this day and age it should be pretty trivial to write software that
> would
> >encode a scanned image of a punched card.
> >
>
> https://secure-web.cisco.com/1nnNBEm7A_m0wqtAaLgflbbQkYcjHIggP4CG9-aGJ60iv5LGiLA3b-sgOj4Z5RrXqVoy9bO2GtA9gEMmiJEEw3pCD1XRrPeZQWJJCqaIyNbpg5ZWh8c6x0VeF0TZoxma_Otu7hIdTuq2ofjE708_dgI3S5MCKLcwE_xc7JJfzy8W5CbJtY1SkhkeYSprsqyo2yfbl5OHjUZJbTG2s7GXMFmD7YKxonbikH40zRCkbg_74GAPYOxAYOpwH8ZbsC3mCXT053D09iRwt8LrVy3YY5F2tKCLQ_NGXKUVBEpyITOgO3r2GL4CQhdxQNpIcd1pG8IKub1rEkNzpO2rEF2nrS-ZymxsdobgXvKJTRZ60DFakV-PzKE83Yo7EGjV4tJ_qLCTueYpoubnb8fjN2PfOc2QiDo5PI0UrPLcFhI0zKbq565EBcHShRAWIET5XHxxp/https%3A%2F%2Fwww.masswerk.at%2Fcardreader%2F
>
> ... and you can generate those with:
> https://secure-web.cisco.com/18RdBO7ZKkAs5OiZMvPOj6vYNZ1vPzRv8-SvdzewuLLELpAKP_GeJnSYFbmSwvh2MVE53Rxi2uGYungYYyMlcCaXY3qglnQDjJXofyqjrQn93NUOrWOKhPXFfFDrFFnEjxSbUpj6zbch_4Xq6OPk3cZ0O3ccHUhM6k7wTXzXsZ46f0FqlhmUOnbz9MC6TlsLWiuDSVgJsSHEx6Pw1OkcIfDOGvfOqH2fSx9NTpZOSd-YGOFd-qklQ8znc-6UbGYd5uCaewG9Q5boaZcyXcC_Le94ZTpQ5mb-9Nswve4M-IPz3mjja9x29OM6VtgajzfsgOfin9Yh1gptx3OhF-0Q7BYYX_sT1uSBUCnoV6l-R1JAiAjEyiaAER2Xp-RLhw59c-XIaoMMZ6cHqQaeXro-zjqoyiyA9gaY-jMPVEoB4msJBvL2B092rkIMM4PKcR5H2/https%3A%2F%2Fwww.masswerk.at%2Fkeypunch%2F
>
> (But it doesn't do UTF-8.)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: What is GRXBIMG

[Joe Monk]

Its some REXX DD that has to be allocated before you can run in TSO.

Joe

On Thu, Jun 4, 2020 at 7:25 AM Seymour J Metz  wrote:

> Idle speculation: it's the file name of s bit map meant to go into the
> manual and the text was supposed to say SYSPROC.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Charles Mills [charl...@mcn.org]
> Sent: Wednesday, June 3, 2020 6:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is GRXBIMG
>
> A more interesting question might be "what happens if I do allocate it?"
> and at least for a simple test with ALLOC FI(GRXBIMG) DA(*) the answer
> seems to be "nothing special."
>
> What might this be a relic of? GRX does not seem to be a component prefix.
> I could be wrong.
>
> Here's my theory: a developer whose initials were GR added some sort of
> debug output: GRXBIMG = George Rothwell's Extended Byte Image or something
> like that. It somehow made it into the product documentation. Astounding
> that it has hidden there in plain sight for over twenty years.
>
> I do not see the reference in the 1991 MVS/REXX Reference:
>
> http://secure-web.cisco.com/1msRUVNTCVPM6al9HyShyRDCsU6ONoAtBXbZbF7GJI59Gj89EEVWxcw_sygtcmoro-Imjk1U0ivgPs56TezTZL7Ba2WK1xNb6Yt-8QhSSHtfKcjpi4120Lk2HeTC2GP_IBVSjpDZ2aER63S8t_e86YAeMWGEkxm-0kO-Skka5_F7n-9WQmSxHedXSSqNjPMCsTlIWQCC56yaSIKzebhds42QUBcHC9zlx-UMb5yTFa2oIWvz0WrXbUGm2BF2bLLjlEhdCanddWLM-oXiVALYstYbU2hWeGN7BMRxMcJFPaMNmBxidchg_eoJCTNNqeCY_q74Di2uFtY4YQx2Y89PNJ8tAou1-jxWUZ1teZbByjfqzH8hUIH2VQUbpBvenpMTw1T4CneetfQe7qvCqp5o2OSE52nYpPrr4XGXLb1VNGnwTSrzLKz3fW4A6bNBpdw-r/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F370%2FTSO_Extensions%2FSC28-1883-4_TSO_Extensions_Version_2_Procedures_Langage_MVS_REXX_Reference_Aug1991.pdf
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, June 3, 2020 9:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is GRXBIMG
>
> On Wed, 3 Jun 2020 07:00:19 -0700, Charles Mills wrote:
>
> >I must have time on my hands. I just dragged out the OS/390 V2R8 CDs from
> 1999, and the sentence is there verbatim.
> >
> >It's the only hit on GRXBIMG on CD #1.
> >
> >-Original Message-
> >From: Steve Smith
> >Sent: Wednesday, June 3, 2020 6:37 AM
> >
> >It's still there in V2R4... and I am appalled that I've been running REXX
> >incorrectly for decades now.
> >
> I submitted a (slightly snarky) RCF on this:
>
> Hello, MHVRCFs,
>
> In:
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikja300/tsorun.htm
> • /OS 2.2.0
> • z/OS TSO/E
> • z/OS TSO/E REXX Reference
> • Using REXX in different address spaces
>
> I read: "... you must have ddname GRXBIMG allocated."
>
> I'm curious.  Does:
>//GRXBIMG DD DUMMY
> suffice, or must it be a PDS(E)?
>
> What error is reported if the programmer fails to
> allocate GRXBIMG?
>
> Is this covered in M&C?
>
> Thanks,
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: What is GRXBIMG

[Joe Monk]

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikja300/tsorun.htm

"You can invoke a REXX exec in the TSO/E address space in several ways. To
invoke an exec in TSO/E foreground, use the TSO/E EXEC command processor to
either implicitly or explicitly invoke the exec and you must have ddname
GRXBIMG allocated."

Joe

On Thu, Jun 4, 2020 at 7:54 AM Seymour J Metz  wrote:

> What does that mean and why do you say so? It's not a DD that you need to
> use REXX in TSO, because IKJEFT01 works fine without it. It's not SYSPROC
> or SYSECEC, which would make sense. And it has a prefix not associated with
> REXX or any other z/OS component.
>
> If it were indeed a DD statement that the authors believed to be necessary
> to run REXX in TSO, wouldn't they have explained what to code on it or at
> least used it in sample JCL?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joe Monk [joemon...@gmail.com]
> Sent: Thursday, June 4, 2020 8:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is GRXBIMG
>
> Its some REXX DD that has to be allocated before you can run in TSO.
>
> Joe
>
> On Thu, Jun 4, 2020 at 7:25 AM Seymour J Metz  wrote:
>
> > Idle speculation: it's the file name of s bit map meant to go into the
> > manual and the text was supposed to say SYSPROC.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Charles Mills [charl...@mcn.org]
> > Sent: Wednesday, June 3, 2020 6:36 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is GRXBIMG
> >
> > A more interesting question might be "what happens if I do allocate it?"
> > and at least for a simple test with ALLOC FI(GRXBIMG) DA(*) the answer
> > seems to be "nothing special."
> >
> > What might this be a relic of? GRX does not seem to be a component
> prefix.
> > I could be wrong.
> >
> > Here's my theory: a developer whose initials were GR added some sort of
> > debug output: GRXBIMG = George Rothwell's Extended Byte Image or
> something
> > like that. It somehow made it into the product documentation. Astounding
> > that it has hidden there in plain sight for over twenty years.
> >
> > I do not see the reference in the 1991 MVS/REXX Reference:
> >
> >
> http://secure-web.cisco.com/1msRUVNTCVPM6al9HyShyRDCsU6ONoAtBXbZbF7GJI59Gj89EEVWxcw_sygtcmoro-Imjk1U0ivgPs56TezTZL7Ba2WK1xNb6Yt-8QhSSHtfKcjpi4120Lk2HeTC2GP_IBVSjpDZ2aER63S8t_e86YAeMWGEkxm-0kO-Skka5_F7n-9WQmSxHedXSSqNjPMCsTlIWQCC56yaSIKzebhds42QUBcHC9zlx-UMb5yTFa2oIWvz0WrXbUGm2BF2bLLjlEhdCanddWLM-oXiVALYstYbU2hWeGN7BMRxMcJFPaMNmBxidchg_eoJCTNNqeCY_q74Di2uFtY4YQx2Y89PNJ8tAou1-jxWUZ1teZbByjfqzH8hUIH2VQUbpBvenpMTw1T4CneetfQe7qvCqp5o2OSE52nYpPrr4XGXLb1VNGnwTSrzLKz3fW4A6bNBpdw-r/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F370%2FTSO_Extensions%2FSC28-1883-4_TSO_Extensions_Version_2_Procedures_Langage_MVS_REXX_Reference_Aug1991.pdf
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Paul Gilmartin
> > Sent: Wednesday, June 3, 2020 9:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is GRXBIMG
> >
> > On Wed, 3 Jun 2020 07:00:19 -0700, Charles Mills wrote:
> >
> > >I must have time on my hands. I just dragged out the OS/390 V2R8 CDs
> from
> > 1999, and the sentence is there verbatim.
> > >
> > >It's the only hit on GRXBIMG on CD #1.
> > >
> > >-Original Message-
> > >From: Steve Smith
> > >Sent: Wednesday, June 3, 2020 6:37 AM
> > >
> > >It's still there in V2R4... and I am appalled that I've been running
> REXX
> > >incorrectly for decades now.
> > >
> > I submitted a (slightly snarky) RCF on this:
> >
> > Hello, MHVRCFs,
> >
> > In:
> >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikja300/tsorun.htm
> > • /OS 2.2.0
> > • z/OS TSO/E
> > • z/OS TSO/E REXX Reference
> > • Using REXX in different address spaces
> >
> > I read: "... you must have ddname GRXBIMG allocated."
> >
> > I'm curious.  Does:
> >//GRXBIMG DD DUMMY
> > suffice, or must it be a PDS(E)?
> >
> > What error is reported if t

Re: COBOL Question

[Joe Monk]

I think what you mean is this:

PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
END-PERFORM

  1050-LOOP.
IF FIRST-NAME NOT = "ROBERT"
GO TO 1059-EXIT
END-IF
IF TYPE NOT = 195
GO TO 1059-EXIT
END-IF
IF NOT SO-ON
GO TO 1059-EXIT
END-IF
IF NOT SO-FORTH
GO TO 1059-EXIT
END-IF
PERFORM 1050-SUCH-AND-SUCH END-PERFORM

  1059-EXIT.
  EXIT.

In structured programming, it is perfectly acceptable to use GO TO within a
paragraph. It is NOT acceptable to use GO TO outside of a paragraph.

Joe

On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:

> I realize this is a bit of a change in subject (and it's not as if we need
> yet another one), but I avoid this construction.  My phobia is based on an
> extreme example:  In their zeal never to use GOTOs, I've frequently seen
> programmers write paragraphs like this:
>
>   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X < 1000
>   IF FIRST-NAME NOT = "ROBERT"
> IF TYPE = 195
>   IF SO-ON
> IF SO-FORTH
>   EXECUTE 1050-SUCH-AND-SUCH
>   END-IF
> END-IF
>   END-IF
> END-IF
>   END-IF
>
> Gives me a headache to try to evaluate that.  Much better, in my opinion,
> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
>
>   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
>
>   1050-LOOP.
> IF X > 999 GOTO 1059-LOOP.
> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
> IF TYPE <> 195 GOTO 1059-LOOP.
> IF NOT SO-ON GOTO 1059-LOOP.
> IF NOT SO-FORTH GOTO 1059-LOOP.
> EXECUTE 1050-SUCH-AND-SUCH
>   1059-LOOP.
>
> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the
> syntax, I probably got part of it wrong nonetheless, and I'll bet there are
> easier ways to do it nowadays.  In REXX, for example, they have the ITERATE
> statement:
>
>   do jc=1 to 99
> if x>99 then iterate
> if firstname='ROBERT' then iterate
> if type<>195 then iterate
> if \soon then iterate
> if \soforth then iterate
> call suchandsuch
> end
>
> However you do it, I vastly prefer skip-to-next-item over nested Ifs.  But
> I confess that one single nested IF is not going to give me a headache; I
> just react when I see one.  Not your fault :).
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* In an emergency, a drawstring from a parka hood can be used to strangle
> a snoring tent mate.  -"Camping Tips" */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: Friday, June 5, 2020 16:17
>
> Using OP
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>  AND SMOD (IND1) = 'B' OR 'R'
>
> I would do
>  IF TVOLL (IND1) NOT = HIGH-VALUE
>   IF SMOD (IND1) = 'B' OR 'R'
>   Do the stuff
>
> --
> 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 Question

[Joe Monk]

Granted its been awhile since ive done application code, but if you
dont end-if they become a nested condition, which I dont think was the
original intent.

Joe

On Sat, Jun 6, 2020 at 1:40 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote:
>
> >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote:
> >
> >>Oh, you need an END-IF even for a single-statement IF?  I forgot; I've
> been thinking in REXX too long.  In that case you're close; I guess I
> really meant
> >
> But in Rexx similarly, END is required even for a single-statement DO.
> Good for Rexx.  I like strong closure.
>
> >In your example the END-IF is not needed.  However beginning with VS
> >COBOL IIV4 (1985 standard) it became better practice to eliminate all
> >but the last period in a paragraph and terminate all conditional with
> >end statements such as END-IF.  With Enterprise COBOL 5.2 and later
> >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO
> >TOs replaced with EXIT PARAGRAPH.  This allow simpler code generation
> >for the PERFORM and the PERFORMed paragraph be moved inline to in
> >effect replace the PERFORM statement.  Also look up inline PERFORMs.
> >In general, because of code optimization starting with VS COBOL II
> >release 4 (1985 standard) GO TO became a bad idea.
> >
> Always a bad idea, or just usually?
>
> -- 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: COBOL Question

[Joe Monk]

In this case, because we are PERFORMing THRU, then GO TO exit, merely
causes an iterate.

Joe

On Mon, Jun 8, 2020 at 7:36 PM Frank Swarbrick 
wrote:

> GO TO to an "exit" procedure (that is, a procedure that terminates
> unconditionally terminates the program) is, in my mind, acceptable as
> well.  In fact, if you try to "perform" a "terminal" exit procedure the
> compiler will give you a warning that your "calling" procedure will never
> reach its exit.
>
> ________
> From: IBM Mainframe Discussion List  on behalf
> of Joe Monk 
> Sent: Saturday, June 6, 2020 2:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: COBOL Question
>
> I think what you mean is this:
>
> PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99
> END-PERFORM
>
>   1050-LOOP.
> IF FIRST-NAME NOT = "ROBERT"
> GO TO 1059-EXIT
> END-IF
> IF TYPE NOT = 195
> GO TO 1059-EXIT
> END-IF
> IF NOT SO-ON
> GO TO 1059-EXIT
> END-IF
> IF NOT SO-FORTH
> GO TO 1059-EXIT
> END-IF
> PERFORM 1050-SUCH-AND-SUCH END-PERFORM
>
>   1059-EXIT.
>   EXIT.
>
> In structured programming, it is perfectly acceptable to use GO TO within a
> paragraph. It is NOT acceptable to use GO TO outside of a paragraph.
>
> Joe
>
> On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges  wrote:
>
> > I realize this is a bit of a change in subject (and it's not as if we
> need
> > yet another one), but I avoid this construction.  My phobia is based on
> an
> > extreme example:  In their zeal never to use GOTOs, I've frequently seen
> > programmers write paragraphs like this:
> >
> >   PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99
> >
> >   1050-LOOP.
> > IF X < 1000
> >   IF FIRST-NAME NOT = "ROBERT"
> > IF TYPE = 195
> >   IF SO-ON
> > IF SO-FORTH
> >   EXECUTE 1050-SUCH-AND-SUCH
> >   END-IF
> > END-IF
> >   END-IF
> > END-IF
> >   END-IF
> >
> > Gives me a headache to try to evaluate that.  Much better, in my opinion,
> > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this:
> >
> >   PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99
> >
> >   1050-LOOP.
> > IF X > 999 GOTO 1059-LOOP.
> > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP.
> > IF TYPE <> 195 GOTO 1059-LOOP.
> > IF NOT SO-ON GOTO 1059-LOOP.
> > IF NOT SO-FORTH GOTO 1059-LOOP.
> > EXECUTE 1050-SUCH-AND-SUCH
> >   1059-LOOP.
> >
> > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up
> the
> > syntax, I probably got part of it wrong nonetheless, and I'll bet there
> are
> > easier ways to do it nowadays.  In REXX, for example, they have the
> ITERATE
> > statement:
> >
> >   do jc=1 to 99
> > if x>99 then iterate
> > if firstname='ROBERT' then iterate
> > if type<>195 then iterate
> > if \soon then iterate
> > if \soforth then iterate
> > call suchandsuch
> > end
> >
> > However you do it, I vastly prefer skip-to-next-item over nested Ifs.
> But
> > I confess that one single nested IF is not going to give me a headache; I
> > just react when I see one.  Not your fault :).
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* In an emergency, a drawstring from a parka hood can be used to
> strangle
> > a snoring tent mate.  -"Camping Tips" */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Gibney, Dave
> > Sent: Friday, June 5, 2020 16:17
> >
> > Using OP
> >  IF TVOLL (IND1) NOT = HIGH-VALUE
> >  AND SMOD (IND1) = 'B' OR 'R'
> >
> > I would do
> >  IF TVOLL (IND1) NOT = HIGH-VALUE
> >   IF SMOD (IND1) = 'B' OR 'R'
> >   Do the stuff
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: "Everyone wants to retire mainframes"

[Joe Monk]

What do you think about paved roads? Theyre something else, huh? Nice and
smooth...

Joe

On Tue, Jun 9, 2020 at 9:41 AM Seymour J Metz  wrote:

> How long has your company been using electricity? Time to modernize.
>
> Yes, I know that you've replaced the wiring three times and have solar
> power on your roof, but it's still the same obsolete electricity.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of R.S. [r.skoru...@bremultibank.com.pl]
> Sent: Tuesday, June 9, 2020 10:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: "Everyone wants to retire mainframes"
>
> W dniu 09.06.2020 o 14:24, Peter Bishop pisze:
> > Interesting re 2):
> >
> > "The survey found that organizations are running an average of four
> > mainframes with an average age of 17 years. Sixty-four percent are
> > running mainframes between 10 and 20 years old, with 28% running
> > machines that are 20 to 30 years old. "
> >
> > So 2/7 are running machines over 20+ years old?  And 2/3 over 10
> > years?  What does that even mean?  Smells fishy to me.  What is the
> > sample size?  Is it biased somehow?
> >
> > Cheers,
> > Peter
>
> It can be understood as how long the company is using mainframe, not how
> old is the currently used CPC.
> Of course mainframe is old, obsolete, expensive... blah, blah, blah...
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> http://secure-web.cisco.com/1fweH3hW6JwpfA1BxzPSBmm-WkVTANCmc6rFRK7QRpvY86fnb3PXJgmZVxpaHo9aiOfxJH54mINVlA9th-bP8Eu-laZ_a1NfFSO_gQNmLx3xNiJhx9n_qoxpD1cCNZfNO920Tqxbqq-4GS3C30F_l0jx3yKLKN9g0EssIwtsjSRoKWa_9lYIpQdxkTwP8oCCgd2JPGa4Z-r4D89-_QriOKTzIeRPNAujA4UjybaKA771z-ad9BBlkDqr8N_V-_8qE2mpt-JFaxraHSX5CQ4yUSUPQ4OVQQb2BRSA6bOo_-YtEsMvtRUkLV193ZGgf47dV7t4J2rRT9vBN3m3eHEZr6mRN6p5V7QF3nftQ4hSZ0vhpHcCxxtYES-pvoDd452wqkIv5kVI0C5YmB5DJzW_n0GGhtIIis6yzHcSCFtCxD3GjjlEpe8Rys5sn1d5KFh_-/http%3A%2F%2Fwww.mBank.pl,
> e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział
> Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,
> http://secure-web.cisco.com/1fweH3hW6JwpfA1BxzPSBmm-WkVTANCmc6rFRK7QRpvY86fnb3PXJgmZVxpaHo9aiOfxJH54mINVlA9th-bP8Eu-laZ_a1NfFSO_gQNmLx3xNiJhx9n_qoxpD1cCNZfNO920Tqxbqq-4GS3C30F_l0jx3yKLKN9g0EssIwtsjSRoKWa_9lYIpQdxkTwP8oCCgd2JPGa4Z-r4D89-_QriOKTzIeRPNAujA4UjybaKA771z-ad9BBlkDqr8N_V-_8qE2mpt-JFaxraHSX5CQ4yUSUPQ4OVQQb2BRSA6bOo_-YtEsMvtRUkLV193ZGgf47dV7t4J2rRT9vBN3m3eHEZr6mRN6p5V7QF3nftQ4hSZ0vhpHcCxxtYES-pvoDd452wqkIv5kVI0C5YmB5DJzW_n0GGhtIIis6yzHcSCFtCxD3GjjlEpe8Rys5sn1d5KFh_-/http%3A%2F%2Fwww.mBank.pl,
> e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw,
> 12th Commercial Division of the National Court Register, KRS 025237,
> NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
> 169.401.468 as at 1 January 2020.
>
> --
> 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: COBOL Question

[Joe Monk]

"Easytrieve plus"

You mean sleazytrieve plus? :)

There was also DYL280 and QUIKJOB.

Joe

On Tue, Jun 9, 2020 at 12:55 PM Mike Schwab  wrote:

> 4GL - I've used Telon which takes a screen layout and database layout
> and generates the cobol code and editing rules.  ADR-Datacom had Ideal
> which was similar, later CA.  Easytrieve plus I really liked,
> especially the report generation part.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS 2.4 and SDSF question

[Joe Monk]

There is an APAR for 0C4 in JES2 when TYPRUN=COPY...

https://www.ibm.com/support/pages/apar/OA57427

Joe

On Tue, Jun 16, 2020 at 1:32 PM Pommier, Rex 
wrote:

> Hello list,
>
> I have a "does it work" question.  We don't run SDSF, instead have a
> competing product.  As part of our testing of 2.4, one of my coworkers
> submitted a job with TYPRUN=COPY on the job card and found it doesn't
> work.  Under 2.2, we get the entire input stream before the JES2 job
> statistics.  Under 2.4, all we get is the JOB card then the statistics
> report.  The spool display product says all the lines are there, but they
> won't show.  When we contacted our vendor about this, they said SDSF
> displays the same thing, working under earlier releases, but under 2.4,
> only the JOB card is printed/displayed.  Can somebody who is running 2.4
> and SDSF (or a third party SDSF competitor) confirm this for me?
>
> Our vendor has a case open with IBM but I'd like to know if others are
> seeing this situation.  I'm not second guessing the vendor, just curious if
> others have run into the situation.
>
> TIA,
>
> Rex
>
> Example:
>
> Job run under both 2.2 and 2.4.
>
> //RRPBR14 JOB (040423,495),RRP,CLASS=T,MSGCLASS=X,MSGLEVEL=(1,1),
> // NOTIFY=&SYSUID,TYPRUN=COPY
> //S1  EXEC  PGM=IEFBR14
> //D1   DD  DISP=OLD,DSN=SFG.$AVRS.V52.KSDS
>
> Spool display under both 2.2 and 2.4 says the output is 14 lines long.
>
> 2.2 spool display (all 14 lines displayed including entire JCL stream):
>
> //RRPBR14 JOB (040423,495),RRP,CLASS=T,MSGCLASS=X,MSGLEVEL=(1,1),
>  JOB03289
> // NOTIFY=&SYSUID,TYPRUN=COPY
>
> //S1  EXEC  PGM=IEFBR14
>
> //D1   DD  DISP=OLD,DSN=SFG.$AVRS.V52.KSDS
>
> -- JES2 JOB STATISTICS --
>
> 4 CARDS READ
>
>11 SYSOUT PRINT RECORDS
>
> 0 SYSOUT PUNCH RECORDS
>
> 0 SYSOUT SPOOL KBYTES
>
>  0.00 MINUTES EXECUTION TIME
>
> J E S 2  J O B  L O G  --  S Y S T E M  Z O S 2  --  N
> O D E  Z 1 4 J E S 2
>
> 13.28.58 JOB03289  TUESDAY,   16 JUN 2020 
>
> 13.28.58 JOB03289  IRR010I  USERID RRP  IS ASSIGNED TO THIS JOB.
>
>
> 2.4 spool display (only 12 lines displayed) :
>
> //RRPBR14 JOB (040423,495),RRP,CLASS=T,MSGCLASS=X,MSGLEVEL=(1,1),
>  JOB05572
> // NOTIFY=&SYSUID,TYPRUN=COPY
>
> -- JES2 JOB STATISTICS --
>
> 4 CARDS READ
>
>11 SYSOUT PRINT RECORDS
>
> 0 SYSOUT PUNCH RECORDS
>
> 0 SYSOUT SPOOL KBYTES
>
>  0.00 MINUTES EXECUTION TIME
>
>  J E S 2  J O B  L O G  --  S Y S T E M  Z O S 2
> --  N O D E  N 1
>
> 13.29.19 JOB05572  TUESDAY,   16 JUN 2020 
>
> 13.29.19 JOB05572  IRR010I  USERID RRP  IS ASSIGNED TO THIS JOB.
>
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
>
> --
> 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: CA-ACCUCHEK

[Joe Monk]

CA-ACCUCHEK was a file comparison utility similar to comparex.

Joe

On Wed, Jun 17, 2020 at 2:06 PM Pommier, Rex 
wrote:

> Hello list,
>
> Based on the subject line of my post, does anybody know anything about
> something called CA-ACCUCHEK?  I have a developer asking about it and I
> know nothing about it.  I checked CA's (OK, Broadcom's) web site and got no
> hits.  Duck Duck Go wasn't any help either, pointing me to some diabetes
> care products.
>
> Is this something CA discontinued?  Does it still exist, either stand
> alone or absorbed into another product?
>
> TIA,
>
> Rex
>
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
>
> --
> 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: 3 phase power question for the gray hair group. :-)

[Joe Monk]

Well its pretty simple. Each phase has a 0 degree point for the rise and
fall of the sine wave. You wire each phase to its corresponding 60 degree
out connection on the relay coil. So, if the phases dont line up, you
dont get a strong enough magnetic field to close the relay.

Joe

On Mon, Jun 22, 2020 at 3:05 PM Grant Taylor <
023065957af1-dmarc-requ...@listserv.ua.edu> wrote:

> On 6/22/20 1:09 PM, William Donzelli wrote:
> > Also, if I could post an image to this list, I would show what a
> > standard IBM phase rotation sensor looks like. I have a box of them.
> >
> > They are basically just relays with three windings on the core,
> > and unless the phases are hooked up properly, they will not throw -
> > all the magnetic fields have to line up.
>
> I would be interested in seeing a picture, and more so, a schematic
> (block) diagram of how they were wired.
>
> I can conceptually understand how it should be possible to build
> something that would respond with the proper phasing.  I just can't
> grasp it well enough to white board it.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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: New Mainframe Community

[Joe Monk]

In my humble opinion

joe

On Fri, Jun 26, 2020 at 1:44 PM McCabe, Ron 
wrote:

> I know this is off topic but what does IMHO stand for?
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Henri Kuiper
> Sent: Friday, June 26, 2020 11:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: New Mainframe Community
>
> CAUTION: This email is from an external address. Please be careful of
> links and attachments.
>
>
> I was referring to the generic average. Not to anything anyone wrote here.
>
> I already regret replying.
>
> /EOT
>
>
> > On 26 Jun 2020, at 19:30, Seymour J Metz  wrote:
> >
> > Not all change is progress, nor does an ad hominem argument bolster
> your case. Neither does constructing straw dummies. "New is bad.  Different
> is bad." is a free construct of your imagination, unrelated to anything
> that anybody here wrote.
> >
> > Are their objections valid? I don't know, but misrepresenting them won't
> convince anybody that they're wrong.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> > mu.edu%2F~smetz3&data=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> > 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> > %7C0%7C637287923585463930&sdata=SjLcLbjqGR3mfHqipZQ1m9cCXLbjpal983
> > ru177s4ow%3D&reserved=0
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > behalf of Henri Kuiper [henrikui...@zdevops.com]
> > Sent: Friday, June 26, 2020 12:57 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: New Mainframe Community
> >
> > Wow. What a lot of pushback.
> >
> > This is (IMHO) precisely what’s wrong with the (generic average)
> mainframe community. New is bad.  Different is bad.
> >
> > Dudes (m/f) : it’s not the 80s anymore.
> >
> > That being said : here’s a little “why” for the existence of the thing
> > :
> > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecu
> > re-web.cisco.com%2F1XvN1_V6ok1sJNlFaq7Z343XlW_wRn1pLUP1SgDYhckTcNv1FTR
> > NKBGu8BhJjyQFtzWCCdxOEkvQnVbzjpkqyIRWBMVMKO5NSI-_UQmV1T4GP85WyNx0I4tfX
> > KY1GyyBAr7-13umt61eWdwZnJ4bmDSMkvpmk0_byLSjeOa645E40X2BFl2gbfYLVB5tGPd
> > 17bav80BvBMpmwbZflaSxkwRKCxNL5XcRfUQPMhpXZWZmUKY1zXMYL7_BESm8M2UUp15ds
> > c7B9m8yYh98BuxkEmTbrJsw_AtpWxwk9--8dv2iecdL4nxNDhXzCt6cDHOu1q85TVJ2MqE
> > pSo446EYbJAKC4r5vEuKvLDlI1DJ2XnTNZopVXqx9eofDzOzd8aDo1iWe_YjyhkhxGMZSC
> > 3vWLVdzgWUvbc1ciqLqZXVnjecO_3YH03XnqCv8Bk5um6Tm4%2Fhttps%253A%252F%252
> > Fzdevops.tumblr.com%252Fpost%252F620908065704853504%252Fmainframe-comm
> > unity-mattermost&data=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> > 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> > %7C0%7C637287923585463930&sdata=feh79oxBKnJUOLcX0pYmtHJwYoOABeIety
> > 9EMMxcYUM%3D&reserved=0
> >
> > That being said I’d say “traditional”  peeps like some of the reactions
> I read here should probably not even try to see what it is.
> >
> > There’s no punch cards. No bus&tek. But an easy, modern, new (young)
> blood friendly environment where about 100 peeps are having some fun
> discussing mainframe things.
> >
> > No hard feelings.
> >
> > And a happy weekend !
> >
> >
> >
> > Sent from my wireless iPhone
> >
> >> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
> >>
> >> Hi Carmen,
> >>
> >> "there's no such thing as a dumb question" comes to mind.  No need for
> any corner for you.  I also learned a bit of history and now know why that
> site Kolosu mentioned looks like so much rubbish now...
> >>
> >> cheers,
> >> Peter
> >>
>  On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
> >>> Kolusu, reached out to me personally and I replied to the wrong
> message and my response went to this forum, so I need more coffee.
> >>> thanks for the kind words and now that my response is 'out there' I
> have to apologize to Mark for naming names. As a novice it's sometimes
> frustrating when the company you support does not pay for Q&A support from
> IBM and has been so terrible to loose all their MF staff.
> >>> I've been lucky to be able to move on and learn more about design and
> build and supporting my environment.
> >>> back to my corner
> >>>
> >>>
> >>>
> >>>
> >>> - Original Message -
> >>>
> >>> From: "Lionel B Dyck" 
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Sent: Tuesday, June 16, 2020 7:24:06 AM
> >>> Subject: Re: New Mainframe Community
> >>>
> >>> Carmen - never put yourself down. While you may not be 'as smart' as
> some, I'm sure you are 'smarter' than some as well. We each bring to the
> table (forum/life) our own skills and capabilities which complement rather
> than replace those of others.
> >>>
> >>> Flames should be reserved for fires and stars, not for shaming others.
> >>>
> >>> Lionel B. Dyck <
> >>> Website:
> >>> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs

Re: Use of BPXWUNIX and CP - a weekend quandary.

[Joe Monk]

What happens if you omit -v?

Joe

On Sat, Jun 27, 2020 at 10:13 AM Lionel B Dyck  wrote:

> I'm running a rexx script under the OMVS shell and have an anomaly that I
> need help with.
>
>
>
> I'm copying a OMVS directory that contains a lot of files into a PDS where
> each file results in a PDS member.
>
>
>
> The command is similar to:  cp -A -U -v /u/me/pdsdir/* "//'hlq.my.pds'"
>
>
>
> When there are fewer than 20-30 files the cp runs just fine.
>
>
>
> When there are more (I don't know what that number is yet but in excess of
> 30 but less than 100) the shell input status changes from RUNNING to INPUT
> and will not proceed until I hit ENTER.  I've waited and ENTER is a must.
>
>
>
> I've 2 bpxwunix environment variables set:
>
> env.1 = '_BPX_SHAREAS=YES'
>
> env.2 = '_BPX_SPAWN_SCRIPT=YES'
>
> env.0 = 2
>
>
>
> Note that this does NOT occur when I SSH into the z/OS system and run the
> rexx script from that interface.
>
>
>
> Thanks for any tips/hints/suggestions.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
>
>
>
> --
> 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: Use of BPXWUNIX and CP - a weekend quandary.

[Joe Monk]

So I came across this interesting snippet...

"You can also use cp to copy files to and from MVS™ data sets. If you
specify more than one file to be copied, the target (last path name on
command line) must be either a directory or a partitioned data set. *If the
target is an MVS partitioned data set, the source cannot be a UNIX
directory."*

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxa500/cp.htm

So isnt your source a UNIX directory?  /u/me/pdsdir/*

Joe

On Sat, Jun 27, 2020 at 11:03 AM Lionel B Dyck  wrote:

> Removing -v did not affect the results - still back to INPUT ☹
>
> Thanks - great idea
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what
> you are, reputation merely what others think you are." - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Joe Monk
> Sent: Saturday, June 27, 2020 10:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Use of BPXWUNIX and CP - a weekend quandary.
>
> What happens if you omit -v?
>
> Joe
>
> On Sat, Jun 27, 2020 at 10:13 AM Lionel B Dyck  wrote:
>
> > I'm running a rexx script under the OMVS shell and have an anomaly
> > that I need help with.
> >
> >
> >
> > I'm copying a OMVS directory that contains a lot of files into a PDS
> > where each file results in a PDS member.
> >
> >
> >
> > The command is similar to:  cp -A -U -v /u/me/pdsdir/* "//'hlq.my.pds'"
> >
> >
> >
> > When there are fewer than 20-30 files the cp runs just fine.
> >
> >
> >
> > When there are more (I don't know what that number is yet but in
> > excess of
> > 30 but less than 100) the shell input status changes from RUNNING to
> > INPUT and will not proceed until I hit ENTER.  I've waited and ENTER is
> a must.
> >
> >
> >
> > I've 2 bpxwunix environment variables set:
> >
> > env.1 = '_BPX_SHAREAS=YES'
> >
> > env.2 = '_BPX_SPAWN_SCRIPT=YES'
> >
> > env.0 = 2
> >
> >
> >
> > Note that this does NOT occur when I SSH into the z/OS system and run
> > the rexx script from that interface.
> >
> >
> >
> > Thanks for any tips/hints/suggestions.
> >
> >
> >
> >
> >
> > Lionel B. Dyck <
> > Website:  <https://www.lbdsoftware.com> https://www.lbdsoftware.com
> >
> > "Worry more about your character than your reputation.  Character is
> > what you are, reputation merely what others think you are." - John
> > Wooden
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

[Joe Monk]

Call from the IBM Lawyers in  3... 2... 1...

Joe

On Tue, Jun 30, 2020 at 5:35 AM Jasi Grewal  wrote:

> Hi,
>
> I am sorry I am just learning Hercules Systems and trying to migrate one
> of my z/OS DASD Systems from Mainframe to Hercules Environment.
> I have z/VM running on Hercules but when I tries to IPL z/OS it seems that
> there is a corruption and that is most probably cause of wrong process.
>
> I believe that there must be some method to migrate the z/OS DASD from
> Mainframe to Hercules.
> I used z/VM DDR+Terse to migrate zOS Dasd but I don't think that is the
> correct process.
> Is there a Documentation in how to migrate z/OS Systems to Hercules? That
> would be appreciated.
>
> Any guidance would be appreciated.
> Thank you in advance,
> Regards,
>
> Jasi Grewal.
>
> --
> 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: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

[Joe Monk]

what model DASD?

Joe

On Tue, Jun 30, 2020 at 9:00 AM Jasi Grewal  wrote:

> Thank You Mike for response and am an IBM Retiree and continues to work
> with IBMers.
> I am requesting IBMers to verify the Licensing and the message we are
> getting is that it cannot find PLPA dataset and yet the same IPL v2r3
> volser was able to IPL v2r3 System successfully under the IBM Mainframe
> host system.
>
> Thanks again,
> Jasi.
>
> --
> 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: Migrate z/OS DASD volumes from Mainframe to Hercules Environment

[Joe Monk]

"And what?"

How about ... and IBM builds in things to the next release of z/os that
make it completely impossible for it to run on Hercules? Or z/VM? or z/VSE?

Joe

On Wed, Jul 1, 2020 at 6:33 AM R.S.  wrote:

> And what?
> I can subscribe to IBM-MAIN using John Doe and some anonymous email.
> Will they track the IP from Joh Doe sent the message?
>
> IBM is aware of illegal users of Hercules + some current OS. They also
> know a lot of Hercules users are IBMers.
>
>
> No, it is nothing pro and against Hercules, piracy, and law. It is just
> an observation.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 30.06.2020 o 15:32, Joe Monk pisze:
> > Call from the IBM Lawyers in  3... 2... 1...
> >
> > Joe
> >
> > On Tue, Jun 30, 2020 at 5:35 AM Jasi Grewal  wrote:
> >
> >> Hi,
> >>
> >> I am sorry I am just learning Hercules Systems and trying to migrate one
> >> of my z/OS DASD Systems from Mainframe to Hercules Environment.
> >> I have z/VM running on Hercules but when I tries to IPL z/OS it seems
> that
> >> there is a corruption and that is most probably cause of wrong process.
> >>
> >> I believe that there must be some method to migrate the z/OS DASD from
> >> Mainframe to Hercules.
> >> I used z/VM DDR+Terse to migrate zOS Dasd but I don't think that is the
> >> correct process.
> >> Is there a Documentation in how to migrate z/OS Systems to Hercules?
> That
> >> would be appreciated.
> >>
> >> Any guidance would be appreciated.
> >> Thank you in advance,
> >> Regards,
> >>
> >> Jasi Grewal.
> >>
> >> --
> >> 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
> > .
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS use of "legacy" programming languages

[Joe Monk]

Honestly, this whole discussion is kind of pointless, no?

z/os  IBM/390 IBM/370 IBM/360 all share ... instruction set. While the
newer models all have newer instructions, object code assembled on a 360 is
just as valid today as it was in 1960.

Joe

On Thu, Jul 2, 2020 at 4:13 AM R.S.  wrote:

> W dniu 01.07.2020 o 20:57, Frank Swarbrick pisze:
> > Thanks Tim.
> >
> > I can't imagine being comfortable writing new code, at least, for a
> compiler that has not been updated in 35 years, but maybe that's just me.
> 🙂
> >
> > Now that we know what languages are still supported, I am still curious
> if anyone out there is actually still using them, and if so, why.
>
> 1. I'm pretty sure there are users of those compilers, this is the only
> reason to keep them under support.
> 2. I guess the users do not create new applications from scratch rather
> they maintain and update existing applications. Is it safe to use so old
> compiler? It is safe to use *supported* compiler. Age has no big meaning
> here, what would you say for 7 years old, but unsupported compiler?
>
> BTW: As a mainframe bigot I sometimes am forced to explain why so old
> things are still in use. Yes, z14 or z15 is veery old. As old as
> z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear
> answers, but one of my favorite is the wheel. Wheel is quite old idea,
> but still in common use. They say M$ introduced a car without wheels or
> the the wheels are enhanced - square...
> Last, but not least: some 20 years old COBOL code is not obsoleted by
> changes in the OS/compiler/whatever, but code on Windows *had* to be
> rewritten several times during this period. Dot net? It was so modern
> just few years ago and now is obsolete. Note: that means programming
> effort just to upgrade system, without any application (business logic)
> changes.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: When did .net become obsolete? was Re: z/OS use of "legacy" programming languages

[Joe Monk]

.NET 3.5 includes all earlier versions.

Current .NET is 4.8.x which include 4.6.2 and 4.7.2.

Joe

On Thu, Jul 2, 2020 at 9:39 AM Clark Morris  wrote:

> [Default] On 2 Jul 2020 02:13:34 -0700, in bit.listserv.ibm-main
> r.skoru...@bremultibank.com.pl (R.S.) wrote:
>
> >> snip
> >
> >BTW: As a mainframe bigot I sometimes am forced to explain why so old
> >things are still in use. Yes, z14 or z15 is veery old. As old as
> >z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear
> >answers, but one of my favorite is the wheel. Wheel is quite old idea,
> >but still in common use. They say M$ introduced a car without wheels or
> >the the wheels are enhanced - square...
> >Last, but not least: some 20 years old COBOL code is not obsoleted by
> >changes in the OS/compiler/whatever, but code on Windows *had* to be
> >rewritten several times during this period. Dot net? It was so modern
> >just few years ago and now is obsolete. Note: that means programming
> >effort just to upgrade system, without any application (business logic)
> >changes.
>
> When did dot net become obsolete?  Versions earlier than 3 are no
> longer supported but when I did a search for dot net both the
> Microsoft pointers and the wiki article seemed to show it is very much
> alive and is now open source.  The original implantation was well
> before 2010 and was starting to be open sourced before then.
>
> Clark Morris
>
> Clark Morris
>
> --
> 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: Assembler question

[Joe Monk]

So in REPORT07, you have: 0CL274. This will not reserve any storage,
because the multiplier is zero. (7FE).

In the next variable, you have XL2. This is hex, length 2. Notice the
location counter is at exactly the same place at REPORT07. (7FE).

In the next variable you have XL2 again. This is hex, length 2. Notice the
location counter has now increased by 2 (800).

In the next variable, you have a Fullword. A fullword cannot start on a
halfword boundary (802), so the assembler bumps the location counter to the
next fullword (804).

Same thing for your next two variables.

Joe

On Sat, Jul 4, 2020 at 2:48 PM Nguyen Dt  wrote:

> Dear lister,
> I am learning assembler on my own, i have something strange that i can't
> explain , please help me to understand
>
> Here is a section of my code :
>
> 608 DBLWORD  DS  DDBLE WORD
>
> 609 PATTERN6 DC  X'402020202120'
> 610 *
>
> 611 REPORTO7 DS  0CL274
>
> 612 OW0007DB DS  XL2
>
> 613 OW0007OB DS  XL2
>
> 614 OW0007AC DS  F
>
> 615 OW0007NP DS  H
>
> 616 OW0007PT DS  F
>
> 617 OW0007PF DS  CL256
>
> 618 *
>
>
>
> And here is the listing at compilation
>
> 0007FE  611 REPORTO7 DS  0CL274
>
> 0007FE  612 OW0007DB DS  XL2
>
> 000800  613 OW0007OB DS  XL2
>
> 000804  614 OW0007AC DS  F
>
> 000808  615 OW0007NP DS  H
>
> 00080C  616 OW0007PT DS  F
>
>
>
> I don't undestand why OW0007OB is 2 bytes  , but on the left it is
> considered as 4 bytes long , the same for QW0007NP
> I read something with alignment obut it seems to concern constants , and
> this is not constant ?
>
>
> Thank you for clarification
>
>
> --
> 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: Assembler question

[Joe Monk]

Cobol has alignment too. You just dont see it.

All storage is aligned.

Joe

On Sun, Jul 5, 2020 at 10:24 AM Nguyen Dt  wrote:

> Thank you all for your inputs,
>
> I am over the problem now.
> In fact what i tried to do is to Move some fields to my output fields and
> then write it as a report. (It is a Db2 performance report, the input are
> from the trace buffers with the macros given by Db2 libraries)
>
> So my program is roughly like this
> READ Buffer on QW... variables
>
> MVC OW...,QW...
>
>
> OW... are the output fields i defined it exactly as in the DSECT got from
> the macros.
> As it is an output field, the position is important  (and it is why i
> detected a problem in the positions of my fields)
> Its is OK now with OW... variables defined as characters CLx
>
> (PS: When i use NOALIGN , the program abends at execution ...)
>
> As i learn assembler "on the flight" , there is some important things that
> i don' t understand , such as the alignment  This is something we don't
> care in cobol , rexx  Can you tell me why assembler has the alignment
> in words that are easy to understand and visualize in my little head ?
>
> Thank you again.
> Duc
>
> --
> 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: Assembler question

[Joe Monk]

"Subordinate items are not aligned"

yeah, no.

If an 01 is aligned, then the subordinate 05 under the 01 is also aligned.
It has to be this way because of REDEFINES. I cant REDEFINE an unaligned
item into an aligned item.

77 are aligned because they are standalone, i.e. no grouping.

Joe

On Sun, Jul 5, 2020 at 12:07 PM Binyamin Dissen 
wrote:

> On Sun, 5 Jul 2020 11:31:55 -0500 Joe Monk  wrote:
>
> :>Cobol has alignment too. You just dont see it.
>
> :>All storage is aligned.
>
> The opposite is true.
>
> Group (01/77) are aligned.
>
> Subordinate items are not aligned unless the SYNC clause is specified.
>
> :>On Sun, Jul 5, 2020 at 10:24 AM Nguyen Dt  wrote:
> :>
> :>> Thank you all for your inputs,
> :>>
> :>> I am over the problem now.
> :>> In fact what i tried to do is to Move some fields to my output fields
> and
> :>> then write it as a report. (It is a Db2 performance report, the input
> are
> :>> from the trace buffers with the macros given by Db2 libraries)
> :>>
> :>> So my program is roughly like this
> :>> READ Buffer on QW... variables
> :>>
> :>> MVC OW...,QW...
> :>>
> :>>
> :>> OW... are the output fields i defined it exactly as in the DSECT got
> from
> :>> the macros.
> :>> As it is an output field, the position is important  (and it is why i
> :>> detected a problem in the positions of my fields)
> :>> Its is OK now with OW... variables defined as characters CLx
> :>>
> :>> (PS: When i use NOALIGN , the program abends at execution ...)
> :>>
> :>> As i learn assembler "on the flight" , there is some important things
> that
> :>> i don' t understand , such as the alignment  This is something we
> don't
> :>> care in cobol , rexx  Can you tell me why assembler has the
> alignment
> :>> in words that are easy to understand and visualize in my little head ?
> :>>
> :>> Thank you again.
> :>> Duc
> :>>
> :>> --
> :>> 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
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> 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: Assembler question

[Joe Monk]

01 BLA-RECORD.
05 BLA-RECORD PIC X(4).
05 BLA-RECOR2 REDEFINES BLA-RECORD PIC X(3).

The 01 is aligned.
The 05 is aligned.
The second 05 is not aligned.

Joe


On Sun, Jul 5, 2020 at 6:27 PM Binyamin Dissen 
wrote:

> 01   BLA-RECORD.
>05   BLA-1  PIC X(3).
>05   BLA-2  PIC S9(8) COMP.
>
> Do you truly wish to assert that BLA-2 is aligned?
>
> On Sun, 5 Jul 2020 17:45:37 -0500 Joe Monk  wrote:
>
> :>"Subordinate items are not aligned"
> :>
> :>yeah, no.
> :>
> :>If an 01 is aligned, then the subordinate 05 under the 01 is also
> aligned.
> :>It has to be this way because of REDEFINES. I cant REDEFINE an unaligned
> :>item into an aligned item.
> :>
> :>77 are aligned because they are standalone, i.e. no grouping.
> :>
> :>Joe
> :>
> :>On Sun, Jul 5, 2020 at 12:07 PM Binyamin Dissen <
> bdis...@dissensoftware.com>
> :>wrote:
> :>
> :>> On Sun, 5 Jul 2020 11:31:55 -0500 Joe Monk 
> wrote:
> :>>
> :>> :>Cobol has alignment too. You just dont see it.
> :>>
> :>> :>All storage is aligned.
> :>>
> :>> The opposite is true.
> :>>
> :>> Group (01/77) are aligned.
> :>>
> :>> Subordinate items are not aligned unless the SYNC clause is specified.
> :>>
> :>> :>On Sun, Jul 5, 2020 at 10:24 AM Nguyen Dt  wrote:
> :>> :>
> :>> :>> Thank you all for your inputs,
> :>> :>>
> :>> :>> I am over the problem now.
> :>> :>> In fact what i tried to do is to Move some fields to my output
> fields
> :>> and
> :>> :>> then write it as a report. (It is a Db2 performance report, the
> input
> :>> are
> :>> :>> from the trace buffers with the macros given by Db2 libraries)
> :>> :>>
> :>> :>> So my program is roughly like this
> :>> :>> READ Buffer on QW... variables
> :>> :>>
> :>> :>> MVC OW...,QW...
> :>> :>>
> :>> :>>
> :>> :>> OW... are the output fields i defined it exactly as in the DSECT
> got
> :>> from
> :>> :>> the macros.
> :>> :>> As it is an output field, the position is important  (and it is
> why i
> :>> :>> detected a problem in the positions of my fields)
> :>> :>> Its is OK now with OW... variables defined as characters CLx
> :>> :>>
> :>> :>> (PS: When i use NOALIGN , the program abends at execution ...)
> :>> :>>
> :>> :>> As i learn assembler "on the flight" , there is some important
> things
> :>> that
> :>> :>> i don' t understand , such as the alignment  This is something
> we
> :>> don't
> :>> :>> care in cobol , rexx  Can you tell me why assembler has the
> :>> alignment
> :>> :>> in words that are easy to understand and visualize in my little
> head ?
> :>> :>>
> :>> :>> Thank you again.
> :>> :>> Duc
> :>> :>>
> :>> :>>
> --
> :>> :>> 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
> :>>
> :>> --
> :>> Binyamin Dissen 
> :>> http://www.dissensoftware.com
> :>>
> :>> Director, Dissen Software, Bar & Grill - Israel
> :>>
> :>>
> :>> Should you use the mailblocks package and expect a response from me,
> :>> you should preauthorize the dissensoftware.com domain.
> :>>
> :>> I very rarely bother responding to challenge/response systems,
> :>> especially those from irresponsible companies.
> :>>
> :>> --
> :>> 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
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> 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: SuperWylbur Users

[Joe Monk]

Me too.

Joe

On Tue, Jul 7, 2020 at 6:56 AM John S. Giltner, Jr. 
wrote:

> I've reached out to SSI and asked about this.
>
> --
> 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: Storage & tape question

[Joe Monk]

Most ORGs are abandoning RAID-5 in favor of better like RAID-6. Any DASD
array should be engineered with two hot spares and call home service to the
vendor for drive replacement.

Joe

On Tue, Jul 7, 2020 at 8:58 AM John McKown 
wrote:

> On Tue, Jul 7, 2020 at 8:19 AM Jackson, Rob 
> wrote:
>
> > Fun little note on RAID:  it is fallible.  The last Sunday of October
> 2016
> > I got a call bright and early because our VTS (TS7740) had shut down.
> > Turns out we had a "cache" HDD failure at around 4 AM, and then a second
> > one failed at around 7 AM, before the first one had been rebuilt on a
> > spare.  RAID-5 could not accommodate it.  Because of IBM politics, we had
> > no tape until Monday at 16:00.  I am ashamed to say that I sort of took
> > tape for granted.  It was astonishing how much of our processing depended
> > on it.
> >
>
> We had a similar problem occurs, long ago, with an actual SAN dasd array
> (for Windows, not MVS). Weekend backup to physical tape aborted on a
> Sunday. The Windows admin said "No problem, it's a RAID-5 array, I can fix
> it Monday morning." A few hours later, a disk in the array failed. No
> problem, right? Unfortunately, while the CE was on his way in to replace
> it, a second disk failed. The array was destroyed. Management said to
> repair it and reload from the Sunday backup and we'd be good. When the
> admin admitted that the backup failed and he didn't go in, he was
> immediately terminated. Now, what are the chances that 2 drives in an array
> will fail within hours? I don't know, but one thing many don't think about
> with a "new array" is that all the drives are likely the same age and will
> start to fail (if they are) about the same time.
>
> IMO, given my paranoia, I firmly believe that the disks in an array should
> be replaced on a scheduled basis. I also believe in dual tape copies of
> important tapes. And also, that tapes in "long term" retention (we have
> tapes which have been at Iron Mountain for over 10 years!) should be
> brought in and the data copied to a new (not reused) tape annually. Of
> course, the bean counters will have an apoplectic fit and scream about how
> much it costs to do this. They only understand cost, not value. I consider
> them the bane of existence. Likely auditors, they take on too much
> authority. Or as I have heard: Fire is a good servant but a terrible
> master.
>
>
>
> >
> > R.S. is spot on:  make backups.  Because of the trauma from this one
> > event, we now have a three-way VTS grid, synchronous-mirrored SANs, and
> two
> > mainframes on the floor.
> >
> > First Horizon Bank
> > Mainframe Technical Support
> >
> >
> --
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
> John McKown
>
> --
> 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: Storage & tape question

[Joe Monk]

In Houston, Texas, a hurricane is VERY likely.

Joe

On Tue, Jul 7, 2020 at 10:27 AM Seymour J Metz  wrote:

> A terrorist attack is unlikely.
>
> An earthquake is unlikely.
>
> A tornado is unlikely.
>
> A flood is unlikely.
>
> ...
>
> The more unlikely risks there are, the greater the odds that one of them
> will happen. If you don't have off site backups then your data are at risk,
> and when the balloon goes up it won't matter how unlikely the particular
> failure mode was.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of R.S. [r.skoru...@bremultibank.com.pl]
> Sent: Tuesday, July 7, 2020 10:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Storage & tape question
>
> W dniu 07.07.2020 o 16:52, Edward Finnell pisze:
> > 1200lbs Semtex make you realize what backups are for and where is your
> cold site?
> >
> > In a message dated 7/7/2020 9:37:20 AM Central Standard Time,
> rwjack...@firsthorizon.com writes:
> > R.S. is spot on:  make backups.  Because of the trauma from this one
> event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two
> mainframes on the floor.
>
> I had serious discussion with some VIPs about it, approx 20 years ago
> (WTC attack).
> I had to explain we are starting DR centre with remote copy to protect
> against many disasters, BUT...
> Dedicated terrorist attack is unlikely, but when considered you cannot
> exclude coordinated attack on two (three) datacenters at the time.
> If you want to be safe you have to protect your datacenter well enough.
> And of course there is bigger bomb for bigger shelter.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl,
> e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział
> Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,
> http://secure-web.cisco.com/1Wm9ZWDyya0bsDg8xZpdEA1zrloL04C_f_SpaX18Prd-2lipCiSvJWBdtAhUW8cM8fIeclWH0309ebDpCdtdbHQH2om9Np4SfoULz0Ba0NfE9OBelXmo3U45TJzvloifiXAcF6E-VQgCAqAiWnYZpkV0VPdNAtTTLl4r4xrqcjTePQsZc5eIsOPaNpCFO3EWNV5WRGa4X8UxsZa8y1uswhFvhouc6Jgyt64rjWFGOBM_PputVQw97ObSs66b4EaLD-zjqbUI6KP5CEaENkhIVi0FZdWFiQ9smCJB66CqwONRMR1F5r9q_jg2LuQQI9BgR9n8hxZKkhsCWi2CqOvSZ-wodnUoBcj_dKGgMzIGX6ZNLsFuY8S5CUHLdeNv1YVnx2fU89Tpt648AQbRslmqY_EOoguvTwZ_LHa29yl3vvff87wDxtxt92Bl1LtMg8xhF/http%3A%2F%2Fwww.mBank.pl,
> e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw,
> 12th Commercial Division of the National Court Register, KRS 025237,
> NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
> 169.401.468 as at 1 January 2020.
>
> --
> 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 acc

Re: SuperWylbur Users

[Joe Monk]

Theres a big problem with the stanford distribution that makes it unusable.

Basically, when they did the ASCII<>EBCDIC translation, some characters got
mistranslated. So, it will not assemble.

Joe

On Wed, Jul 8, 2020 at 2:35 AM Timothy Sipples  wrote:

> There's precedent. Stanford graciously offers WYLBUR's source code for
> download:
>
> https://web.stanford.edu/dept/its/support/wylorv/
>
> Of course SuperWylbur is not WYLBUR:
>
> https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR#SuperWylbur%E2%84%A2
>
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.com
>
> --
> 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: Storage & tape question

[Joe Monk]

First off, STOP

Second off, disaster recovery is a question of risk mitigation for a
business. The business (NOT I.T.) must make the decision as to what
level of risk mitigation they are willing to pay for. You can preach at
them til their blue in the face, and it wont matter until something happens
like a ransomware attack and they go down for a week or so.

Joe

On Wed, Jul 8, 2020 at 7:21 AM R.S.  wrote:

> No, you answered off topic. You initiate quarrels. Not only here.
> You have a of time for trolling. And you always want to say "no, you're
> wrong".
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> W dniu 08.07.2020 o 14:17, Seymour J Metz pisze:
> > No thanks, I'll leave that sort of thing to you; you're much better at
> it than I am.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of R.S. [r.skoru...@bremultibank.com.pl]
> > Sent: Wednesday, July 8, 2020 7:58 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Storage & tape question
> >
> > Feel free to answer off-topic, criticize unsaid sentences and be
> > self-concvinced you are right while rest of the world is wrong. Have a
> fun.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> > W dniu 08.07.2020 o 13:53, Seymour J Metz pisze:
> >> Whoosh! You're completely missing the point. It's a matter of basic
> probability theory. Given N independent adverse scenarios with
> probabilities Pn, the probability that none of them will happen is
> (1-P1)(1-P2)...(1-PN).
> >>
> >> But it's not my dog. Feel free to run without backups, as long as you
> don't ask for sympathy when the balloon goes up.
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> http://mason.gmu.edu/~smetz3
> >>
> >> 
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of R.S. [r.skoru...@bremultibank.com.pl]
> >> Sent: Wednesday, July 8, 2020 5:32 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Storage & tape question
> >>
> >> It has no value.
> >> Terrorist attack is unlikely, but two terrorist attacks at the time are
> >> more unlikely. Thousand terrorist attacks at the tima are even more
> >> unlikely.
> >> A bomb attack is unlikely. Large (atomic?) bomb attack is more unlikely.
> >> When you have two datacenters and tapes in shelter off-site ...it is
> >> still just unlikely to have coordinated attack on all the locations at
> >> the time, and it is just unlikely to have shelters strong enough.
> >> More data locations? Fine, more bombs.
> >> And it is quite likely some malevolent people would know the adresses of
> >> the locations.
> >>
> >> If you think you can protect your data against unlikely events
> >> (disaster, etc.)...
> >> Or rather: if you think you know how to do it, despite of the costs -
> >> you're simply WRONG.
> >> There is always some level of protection. The level is not infinite and
> >> *cannot* be inifite. It can be high. Maybe "high enough" or "reasonably
> >> high".
> >>
> >>
> >> Side note: there are scenarios when achieving higher level of protection
> >> is pointless. Let's assume ticket system for metro transportation
> >> (buses) and ...war. Or ticket system for buses in Biloxi.
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >>
> >> W dniu 07.07.2020 o 17:27, Seymour J Metz pisze:
> >>> A terrorist attack is unlikely.
> >>>
> >>> An earthquake is unlikely.
> >>>
> >>> A tornado is unlikely.
> >>>
> >>> A flood is unlikely.
> >>>
> >>> ...
> >>>
> >>> The more unlikely risks there are, the greater the odds that one of
> them will happen. If you don't have off site backups then your data are at
> risk, and when the balloon goes up it won't matter how unlikely the
> particular failure mode was.
> >>>
> >>>
> >>> --
> >>> Shmuel (Seymour J.) Metz
> >>> http://mason.gmu.edu/~smetz3
> >>>
> >>> 
> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of R.S. [r.skoru...@bremultibank.com.pl]
> >>> Sent: Tuesday, July 7, 2020 10:59 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Storage & tape question
> >>>
> >>> W dniu 07.07.2020 o 16:52, Edward Finnell pisze:
>  1200lbs Semtex make you realize what backups are for and where is
> your cold site?
> 
>  In a message dated 7/7/2020 9:37:20 AM Central Standard Time,
> rwjack...@firsthorizon.com writes:
>  R.S. is spot on:  make backups.  Because of the trauma from this one
> event, we now have a three-way VTS grid, synchronous-mirrored SANs, and two
> mainframes on the floor.
> >>> I had serious discussion with some VIPs about it, approx 20 years ago
> >>> (WTC attack).
> >>> I had to explain we are starting DR centre with remote copy to protect
> >>> against many disasters, BUT...
> >>> Dedicated terrorist attack is 

Re: Storage & tape question

[Joe Monk]

I do a backup to spinning storage, then a copy of that backup to Azure for
long term.

Joe

On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz  wrote:

> I've always gone with dual* backups, with one copy off site. Remote
> mirroring is a good option where policy permits, and even if retensioning
> is no longer relevant, rereading backups periodically will give you a heads
> up if one copy goes south. I would consider even correctable errors to be
> red flags.
>
> Any medium you use will have failure modes.
>
> Multiple PiT recovery is good for "whoops!" moments and possibly for
> audits.
>
> Large or small, each shop must do it's own risk assessments in the context
> of its own obligations and priorities.
>
> * Depending on the value of the data, you might want more than 2.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Bill Ogden [og...@us.ibm.com]
> Sent: Wednesday, July 8, 2020 9:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Storage & tape question
>
> Probably many others will chime in on this. I have lost RAID 5 arrays with
> two disk failures within an hour of each other. RAID is nice, but one must
> allow for failures.
>
> Long ago I was involved with reading archived tapes and transferring the
> data to CDs. The programs involved were home-written and the project ended
> up going nowhere. However, we discovered that tapes  kept too long started
> having errors. (At that point, for the CD copy, we just logged the error
> and accepted the corrupt data; what else could we do?) How long is "too
> long"?? It was variable, but measured in a few years. The advice then was
> to minimally read the tapes every year or so to "retension" them. Don't
> know if this would apply to more modern tape media.  (We also discovered
> that locally "burned" CDs are not expected last forever.)
>
> IMHO, the key point for tape backups are (1) off-site storage, (2)
> multiple PiT recovery, (3) logical error recovery. All this can be done
> with disk-only environments involving remote copy and lots of disk space,
> but all that becomes expensive for smaller shops.
>
> Bill Ogden
>
>
> --
> 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: SuperWylbur Users

[Joe Monk]

Here is some info from a while back ...

There is definitely interest, but the UCLA version, instead of being
offloaded on the mainframe in AWS or Transmit format, was converted to
ASCII, losing some needed characters, and was then compressed as a tar
file. The result won't unpack under Windows; unpacked files have
unacceptable directory and member names. At this point I'm not aware of
anyone who has successfully assembled any component. If you search the
internet for Wylbur, you'll find a discussion group, with membership
partly overlapping this and the IBM-MAIN groups, according to which some
people are fairly close to a zOS version. I just got my files unpacked a
few weeks ago, and will be using a REXX/Regina program to convert them
to something I can actually process under MVS 3.8j.

And please, don't try to upload the tar/tgz file - it's useless in its
current form.

https://hercules-390.yahoogroups.narkive.com/ygahqIHc/wylbur-orvyl-milten-and-friends

Joe

On Wed, Jul 8, 2020 at 1:15 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 8 Jul 2020 09:18:01 -0700, Charles Mills  wrote:
>
> >I would *think* -- perhaps I am being naïve -- that one could come up
> with an automated fix for that that would do a 90% job, and then fix the
> last 10% manually.
> >
> >How many lines of source is it (approximately) and in a few words what
> was the mistranslation error? The usual stuff with braces, brackets and
> such?
> >
> >-Original Message-
> >Fromf Joe Monk
> >Sent: Wednesday, July 8, 2020 4:13 AM
> >
> >Theres a big problem with the stanford distribution that makes it
> unusable.
> >
> >Basically, when they did the ASCII<>EBCDIC translation, some characters
> got
> >mistranslated. So, it will not assemble.
> >
> "they"?
>
> What CCSIDs did they presume?  What should it have been?
> Iconv is your friend.  Translate back with CCSIDs to undo what they did,
> then re-translate with the correct pair.
>
> -- 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: SuperWylbur Users

[Joe Monk]

Yep. And its useless.

Joe

On Wed, Jul 8, 2020 at 1:39 PM David Spiegel 
wrote:

> Hi Joe,
> I GUNZIPd and UNTARd WYLBUR via CYGWIN on Windows 10 Pro.
>
> Regards,
> David
>
> On 2020-07-08 14:25, Joe Monk wrote:
> > Here is some info from a while back ...
> >
> > There is definitely interest, but the UCLA version, instead of being
> > offloaded on the mainframe in AWS or Transmit format, was converted to
> > ASCII, losing some needed characters, and was then compressed as a tar
> > file. The result won't unpack under Windows; unpacked files have
> > unacceptable directory and member names. At this point I'm not aware of
> > anyone who has successfully assembled any component. If you search the
> > internet for Wylbur, you'll find a discussion group, with membership
> > partly overlapping this and the IBM-MAIN groups, according to which some
> > people are fairly close to a zOS version. I just got my files unpacked a
> > few weeks ago, and will be using a REXX/Regina program to convert them
> > to something I can actually process under MVS 3.8j.
> >
> > And please, don't try to upload the tar/tgz file - it's useless in its
> > current form.
> >
> >
> https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhercules-390.yahoogroups.narkive.com%2FygahqIHc%2Fwylbur-orvyl-milten-and-friends&data=02%7C01%7C%7C18bdfcd062254ca256d008d8236c669e%7C84df9e7fe9f640afb435%7C1%7C0%7C637298295792505848&sdata=ybsKDKHqNbzz9n5xhKEcwGIFCKNu3RrbuiC1hbvaPB8%3D&reserved=0
> >
> > Joe
> >
> > On Wed, Jul 8, 2020 at 1:15 PM Paul Gilmartin <
> > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> On Wed, 8 Jul 2020 09:18:01 -0700, Charles Mills  wrote:
> >>
> >>> I would *think* -- perhaps I am being naïve -- that one could come up
> >> with an automated fix for that that would do a 90% job, and then fix the
> >> last 10% manually.
> >>> How many lines of source is it (approximately) and in a few words what
> >> was the mistranslation error? The usual stuff with braces, brackets and
> >> such?
> >>> -Original Message-
> >>> Fromf Joe Monk
> >>> Sent: Wednesday, July 8, 2020 4:13 AM
> >>>
> >>> Theres a big problem with the stanford distribution that makes it
> >> unusable.
> >>> Basically, when they did the ASCII<>EBCDIC translation, some characters
> >> got
> >>> mistranslated. So, it will not assemble.
> >>>
> >> "they"?
> >>
> >> What CCSIDs did they presume?  What should it have been?
> >> Iconv is your friend.  Translate back with CCSIDs to undo what they did,
> >> then re-translate with the correct pair.
> >>
> >> -- gil
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > .
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: SuperWylbur Users

[Joe Monk]

"instead of being offloaded on the mainframe in AWS or Transmit format, was
converted to ASCII, losing some needed characters, and was then compressed
as a tar file. "

So if you understand the implications of that, then you understand why its
useless.

Joe

On Wed, Jul 8, 2020 at 3:37 PM David Spiegel 
wrote:

> Hi Joe,
> Why is it useless?
>
> Thanks and regards,
> David
>
> On 2020-07-08 16:25, Joe Monk wrote:
> > Yep. And its useless.
> >
> > Joe
> >
> > On Wed, Jul 8, 2020 at 1:39 PM David Spiegel 
> > wrote:
> >
> >> Hi Joe,
> >> I GUNZIPd and UNTARd WYLBUR via CYGWIN on Windows 10 Pro.
> >>
> >> Regards,
> >> David
> >>
> >> On 2020-07-08 14:25, Joe Monk wrote:
> >>> Here is some info from a while back ...
> >>>
> >>> There is definitely interest, but the UCLA version, instead of being
> >>> offloaded on the mainframe in AWS or Transmit format, was converted to
> >>> ASCII, losing some needed characters, and was then compressed as a tar
> >>> file. The result won't unpack under Windows; unpacked files have
> >>> unacceptable directory and member names. At this point I'm not aware of
> >>> anyone who has successfully assembled any component. If you search the
> >>> internet for Wylbur, you'll find a discussion group, with membership
> >>> partly overlapping this and the IBM-MAIN groups, according to which
> some
> >>> people are fairly close to a zOS version. I just got my files unpacked
> a
> >>> few weeks ago, and will be using a REXX/Regina program to convert them
> >>> to something I can actually process under MVS 3.8j.
> >>>
> >>> And please, don't try to upload the tar/tgz file - it's useless in its
> >>> current form.
> >>>
> >>>
> >>
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhercules-390.yahoogroups.narkive.com%2FygahqIHc%2Fwylbur-orvyl-milten-and-friends&data=02%7C01%7C%7C6ce4721ad7de46a4d74908d8237d19a1%7C84df9e7fe9f640afb435%7C1%7C0%7C637298367511061503&sdata=hHlHH8doCTvQPoZqlyKvbvHprP8eEnck5JuoWoh3SJk%3D&reserved=0
> >>> Joe
> >>>
> >>> On Wed, Jul 8, 2020 at 1:15 PM Paul Gilmartin <
> >>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
> >>>> On Wed, 8 Jul 2020 09:18:01 -0700, Charles Mills  wrote:
> >>>>
> >>>>> I would *think* -- perhaps I am being naïve -- that one could come up
> >>>> with an automated fix for that that would do a 90% job, and then fix
> the
> >>>> last 10% manually.
> >>>>> How many lines of source is it (approximately) and in a few words
> what
> >>>> was the mistranslation error? The usual stuff with braces, brackets
> and
> >>>> such?
> >>>>> -Original Message-
> >>>>> Fromf Joe Monk
> >>>>> Sent: Wednesday, July 8, 2020 4:13 AM
> >>>>>
> >>>>> Theres a big problem with the stanford distribution that makes it
> >>>> unusable.
> >>>>> Basically, when they did the ASCII<>EBCDIC translation, some
> characters
> >>>> got
> >>>>> mistranslated. So, it will not assemble.
> >>>>>
> >>>> "they"?
> >>>>
> >>>> What CCSIDs did they presume?  What should it have been?
> >>>> Iconv is your friend.  Translate back with CCSIDs to undo what they
> did,
> >>>> then re-translate with the correct pair.
> >>>>
> >>>> -- gil
> >>>>
> >>>> --
> >>>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>>> send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> >>>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>> .
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > --
> > 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: SuperWylbur Users

[Joe Monk]

"NOTE: All files are written as plain TEXT files in ASCII
with Unix-style line endings (x'0a'). Although creator
is set to ttxt (TextEdit), the files should be readable by
any text editor (vi, xedit, BBEdit, etc.). Note that all
data went through EBCDIC to ASCII conversions, so imbedded
special characters like x'FF' might be X'07' instead."

So, your first problem is fixing the UNIX style line endings. PCs want CRLF
(0x0a0d) for line endings.

Then, you have to try and restore the ASCII back to EBCDIC. And as you can
see, there was no code page applied. Moreover, on a mainframe ASCII is only
7 bits.  Good luck with that.

https://web.stanford.edu/dept/its/support/wylorv/WYLORV.readme.html

joe

On Wed, Jul 8, 2020 at 6:05 PM Charles Mills  wrote:

> I don't.
>
> What not translate from *that code page* back to EBCDIC?
>
> Perhaps flawed but not useless. Or at least I for one do not understand.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Monk
> Sent: Wednesday, July 8, 2020 3:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SuperWylbur Users
>
> "instead of being offloaded on the mainframe in AWS or Transmit format, was
> converted to ASCII, losing some needed characters, and was then compressed
> as a tar file. "
>
> So if you understand the implications of that, then you understand why its
> useless.
>
> Joe
>
> On Wed, Jul 8, 2020 at 3:37 PM David Spiegel 
> wrote:
>
> > Hi Joe,
> > Why is it useless?
> >
> > Thanks and regards,
> > David
> >
> > On 2020-07-08 16:25, Joe Monk wrote:
> > > Yep. And its useless.
> > >
> > > Joe
> > >
> > > On Wed, Jul 8, 2020 at 1:39 PM David Spiegel 
> > > wrote:
> > >
> > >> Hi Joe,
> > >> I GUNZIPd and UNTARd WYLBUR via CYGWIN on Windows 10 Pro.
> > >>
> > >> Regards,
> > >> David
> > >>
> > >> On 2020-07-08 14:25, Joe Monk wrote:
> > >>> Here is some info from a while back ...
> > >>>
> > >>> There is definitely interest, but the UCLA version, instead of being
> > >>> offloaded on the mainframe in AWS or Transmit format, was converted
> to
> > >>> ASCII, losing some needed characters, and was then compressed as a
> tar
> > >>> file. The result won't unpack under Windows; unpacked files have
> > >>> unacceptable directory and member names. At this point I'm not aware
> of
> > >>> anyone who has successfully assembled any component. If you search
> the
> > >>> internet for Wylbur, you'll find a discussion group, with membership
> > >>> partly overlapping this and the IBM-MAIN groups, according to which
> > some
> > >>> people are fairly close to a zOS version. I just got my files
> unpacked
> > a
> > >>> few weeks ago, and will be using a REXX/Regina program to convert
> them
> > >>> to something I can actually process under MVS 3.8j.
> > >>>
> > >>> And please, don't try to upload the tar/tgz file - it's useless in
> its
> > >>> current form.
> > >>>
> > >>>
> > >>
> >
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhercules-390.yahoogroups.narkive.com%2FygahqIHc%2Fwylbur-orvyl-milten-and-friends&data=02%7C01%7C%7C6ce4721ad7de46a4d74908d8237d19a1%7C84df9e7fe9f640afb435%7C1%7C0%7C637298367511061503&sdata=hHlHH8doCTvQPoZqlyKvbvHprP8eEnck5JuoWoh3SJk%3D&reserved=0
> > >>> Joe
> > >>>
> > >>> On Wed, Jul 8, 2020 at 1:15 PM Paul Gilmartin <
> > >>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> > >>>
> > >>>> On Wed, 8 Jul 2020 09:18:01 -0700, Charles Mills  wrote:
> > >>>>
> > >>>>> I would *think* -- perhaps I am being naïve -- that one could come
> up
> > >>>> with an automated fix for that that would do a 90% job, and then fix
> > the
> > >>>> last 10% manually.
> > >>>>> How many lines of source is it (approximately) and in a few words
> > what
> > >>>> was the mistranslation error? The usual stuff with braces, brackets
> > and
> > >>>> such?
> > >>>>> -Original Message-
> > >>>>> Fromf Joe Monk
> > >>>>> Sent: Wednesday, July 8, 2020 4:13 AM

Re: SuperWylbur Users

[Joe Monk]

Peter,

This has been tried many times. Gerhard Postpischil was an expert. He was
unable to do it before he passed away, despite trying multiple times.

Basically, the google group dedicated to WYLBUR gave up on the effort in
2005.

Joe

On Wed, Jul 8, 2020 at 6:21 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Joe,
>
> I think many of us are familiar with the issues involved in translating
> some CCSID's of EBCDIC to ASCII, famously the square brackets and certain
> other "special" characters.
>
> Do you yourself know (or can you point to any public discussion that
> lists) the specific character translations that were done wrongly?  As I
> said in an earlier reply, I did see in some of the tar file members that
> they contain what appear to be legitimate square brackets, so perhaps it is
> some other (hopefully small) set of characters?
>
> ISTM that if one knows specifically what was mistranslated it may be
> possible to reconstruct what was lost.  Not easily perhaps, but it would
> seem at least possible to programmatically perform a reconstruction, or
> most of it, and then use IEBIBALL for the rest in the context of the
> malformed code.
>
> It isn't beyond belief that the CCSID of the original source was the 037
> variant of IBM EBCDIC, but that is only a guess based on the age of the
> code.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Joe Monk
> Sent: Wednesday, July 8, 2020 6:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SuperWylbur Users
>
> "instead of being offloaded on the mainframe in AWS or Transmit format,
> was converted to ASCII, losing some needed characters, and was then
> compressed as a tar file. "
>
> So if you understand the implications of that, then you understand why its
> useless.
>
> Joe
>
> On Wed, Jul 8, 2020 at 3:37 PM David Spiegel 
> wrote:
>
> > Hi Joe,
> > Why is it useless?
> >
> > Thanks and regards,
> > David
> >
> > On 2020-07-08 16:25, Joe Monk wrote:
> > > Yep. And its useless.
> > >
> > > Joe
> > >
> > > On Wed, Jul 8, 2020 at 1:39 PM David Spiegel
> > > 
> > > wrote:
> > >
> > >> Hi Joe,
> > >> I GUNZIPd and UNTARd WYLBUR via CYGWIN on Windows 10 Pro.
> > >>
> > >> Regards,
> > >> David
> > >>
> > >> On 2020-07-08 14:25, Joe Monk wrote:
> > >>> Here is some info from a while back ...
> > >>>
> > >>> There is definitely interest, but the UCLA version, instead of
> > >>> being offloaded on the mainframe in AWS or Transmit format, was
> > >>> converted to ASCII, losing some needed characters, and was then
> > >>> compressed as a tar file. The result won't unpack under Windows;
> > >>> unpacked files have unacceptable directory and member names. At
> > >>> this point I'm not aware of anyone who has successfully assembled
> > >>> any component. If you search the internet for Wylbur, you'll find
> > >>> a discussion group, with membership partly overlapping this and
> > >>> the IBM-MAIN groups, according to which
> > some
> > >>> people are fairly close to a zOS version. I just got my files
> > >>> unpacked
> > a
> > >>> few weeks ago, and will be using a REXX/Regina program to convert
> > >>> them to something I can actually process under MVS 3.8j.
> > >>>
> > >>> And please, don't try to upload the tar/tgz file - it's useless in
> > >>> its current form.
> > >>>
> > >>>
> > >>
> > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fherc
> > ules-390.yahoogroups.narkive.com%2FygahqIHc%2Fwylbur-orvyl-milten-and-
> > friends&data=02%7C01%7C%7C6ce4721ad7de46a4d74908d8237d19a1%7C84df9
> > e7fe9f640afb435%7C1%7C0%7C637298367511061503&sdata=hHl
> > HH8doCTvQPoZqlyKvbvHprP8eEnck5JuoWoh3SJk%3D&reserved=0
> > >>> Joe
> > >>>
> > >>> On Wed, Jul 8, 2020 at 1:15 PM Paul Gilmartin <
> > >>> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> > >>>
> > >>>> On Wed, 8 Jul 2020 09:18:01 -0700, Charles Mills  wrote:
> > >>>>
> > >>>>> I would *think* -- perhaps I am being naïve -- that one could
> > >>>>> come up
> > >>>> with an automated fix for that th

Re: SuperWylbur Users

[Joe Monk]

"I certainly had no intention to demean Gerhard, with whom I corresponded
on other email lists.  A gentleman and an expert in multiple disciplines
who freely shared his expertise.  If he failed after intensive effort, I
wouldn’t presume to be his better."

Yes Gerhard was special. He and I had private email conversations about
this very subject, which is why I am just trying to help yall not beat your
head against the wall :)

Joe

On Wed, Jul 8, 2020 at 7:43 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Note also that the assembly listing you mentioned has a step that
> post-processes the ASM SYSPRINT output:
>
> 15 //EDITEXEC PGM=ASMEDIT,TIME=2,REGION=4000K,
>// PARM='STMT'
> 16 //STEPLIB  DD  DSN=WYL.GG.SYS.LINKLIB,DISP=SHR
> 17 //ASMOUT   DD  DSN=&PRINT,DISP=(OLD,DELETE)
> 18 //SYSPRINT DD  SYSOUT=A
>
> That seems to be a common last step in the assemblies I reviewed.
>
> I did not see any ASMEDIT routine anywhere in that package, but if that is
> all it does it would probably not be hard to duplicate the function.  I'll
> bet those "box draw" characters are specific to whatever laser or networked
> printer setup they had at the time.
>
> The unfortunate choice to suppress macro output in the assembly listings
> would undoubtedly make it harder to fully duplicate and verify new
> assemblies, and certainly any object-code-only files that may have been
> supplied in the various directories would almost certainly have been
> irretrievably trashed.  If operation of the product depends on any OCO
> subroutines in the package, then that certainly would be *the* serious
> block to implementation, with any chance of recovery not very probable.
>
> I certainly had no intention to demean Gerhard, with whom I corresponded
> on other email lists.  A gentleman and an expert in multiple disciplines
> who freely shared his expertise.  If he failed after intensive effort, I
> wouldn’t presume to be his better.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Tony Harminc
> Sent: Wednesday, July 8, 2020 7:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SuperWylbur Users
>
> On Wed, 8 Jul 2020 at 14:38, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
> >
> > Do you know of a specific program or macro in the package that exhibits
> this failure?  Or have a link to any public discussion of the issue that
> describes the mis-translations?
> >
> > I DL'd the tgz file directly from Stanford and browsed a few sources at
> random, but I didn't see any "weird" characters.  One of the mail-related
> scripts I reviewed seemed to have legitimate square bracket pairs, so maybe
> it isn't that particular issue?
>
> I did much the same, and noticed that in the listing files there seems to
> have been some post processing done to (among other things) generate text
> boxes For example, in Mainframe\GS.MIL\MILTEN.SOURCE\MSVC there is a line
> starting with *box which in the matching listing
> Assemblies\Milten\MIL#MSVC.txt generates a box made mostly of X'FE' for the
> horizontal lines, 9F for the vertical, and the four corners are BF, DC, BE,
> and BB. This is neither ASCII nor EBCDIC in any dialect I recognize, but
> all the box characters have been uniquely translated, so that may well also
> be true for any unusual characters in the actual source lines.
>
> I doubt that the long-standing claim that the Wylbur source is trashed is
> completely invented, but things certainly *look* salvageable at first
> glance.
>
> Tony H.
> --
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Storage & tape question

[Joe Monk]

Im sure that Kim Dotcom would love your legal theory...

Joe

On Thu, Jul 9, 2020 at 7:51 AM R.S.  wrote:

> Azure? Cloud?
> There is no cloud. It is just someone else's computer. ;-)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 08.07.2020 o 17:46, Joe Monk pisze:
> > I do a backup to spinning storage, then a copy of that backup to Azure
> for
> > long term.
> >
> > Joe
> >
> > On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz  wrote:
> >
> >> I've always gone with dual* backups, with one copy off site. Remote
> >> mirroring is a good option where policy permits, and even if
> retensioning
> >> is no longer relevant, rereading backups periodically will give you a
> heads
> >> up if one copy goes south. I would consider even correctable errors to
> be
> >> red flags.
> >>
> >> Any medium you use will have failure modes.
> >>
> >> Multiple PiT recovery is good for "whoops!" moments and possibly for
> >> audits.
> >>
> >> Large or small, each shop must do it's own risk assessments in the
> context
> >> of its own obligations and priorities.
> >>
> >> * Depending on the value of the data, you might want more than 2.
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> http://mason.gmu.edu/~smetz3
> >>
> >> 
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf
> >> of Bill Ogden [og...@us.ibm.com]
> >> Sent: Wednesday, July 8, 2020 9:27 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Storage & tape question
> >>
> >> Probably many others will chime in on this. I have lost RAID 5 arrays
> with
> >> two disk failures within an hour of each other. RAID is nice, but one
> must
> >> allow for failures.
> >>
> >> Long ago I was involved with reading archived tapes and transferring the
> >> data to CDs. The programs involved were home-written and the project
> ended
> >> up going nowhere. However, we discovered that tapes  kept too long
> started
> >> having errors. (At that point, for the CD copy, we just logged the error
> >> and accepted the corrupt data; what else could we do?) How long is "too
> >> long"?? It was variable, but measured in a few years. The advice then
> was
> >> to minimally read the tapes every year or so to "retension" them. Don't
> >> know if this would apply to more modern tape media.  (We also discovered
> >> that locally "burned" CDs are not expected last forever.)
> >>
> >> IMHO, the key point for tape backups are (1) off-site storage, (2)
> >> multiple PiT recovery, (3) logical error recovery. All this can be done
> >> with disk-only environments involving remote copy and lots of disk
> space,
> >> but all that becomes expensive for smaller shops.
> >>
> >> Bill Ogden
> >>
> >>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: IBM 2828-G01

[Joe Monk]

z/OS 2.4 is supported...

 z/OS® V2R4 is supported on the following IBM Z® servers:

   -  IBM® z15™ (z15)
   - IBM z14™ (z14)
   - IBM z14® ZR1
   - IBM z13® (z13®)
   - IBM z13s®™ (z13s)
   - IBM zEnterprise® EC12 (zEC12)
   - IBM zEnterprise BC12 (zBC12)


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/osproc.htm
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.e0zb100/hdwreqs.htm



On Fri, Jul 10, 2020 at 6:55 AM Richards, Robert B. <
01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:

> A quick Google search indicates z/OS 2.1 and z/VM 6.2 depending on
> features.
>
> There are multiple hits for IBM pages
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of CarlosM Martinez
> Sent: Friday, July 10, 2020 7:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM 2828-G01
>
> Does anyone know the latest release of  Z/VM , Z/OS and Z/VSE that can run
> on a IBM 2828-G01
>
> Was there a  page IBM had at one time?
>
>
>
> Thank you,
>
>
>
> Carlos Martinez
>
>
>
> SUNY Downstate
>
>
> --
> 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: Storage & tape question

[Joe Monk]

My point is, once you rent that computer and put your stuff on it, it is no
longer "someone else's computer". It is now YOUR computer. YOU are
responsible for it.

Joe

On Mon, Jul 13, 2020 at 5:35 AM R.S.  wrote:

> I heard about Kim Dotcom, but I don't understand what you mean.
> I'm not talking here about legal issues, so there is nothing to love.
> And the cloud is still someone else's computer, isn't it?
> Keeping data in cloud is still keeping data on someone else's media like
> disk or tape. Usually tape for large amounts and reasonable prices (with
> horrible access times). The main difference is you don't know where is
> your data.
>
> (off topic drift)
> Of course cloud is valuable in man cases, especially for smal and medium
> businesses. Sometimes "don't do it, use our services" is true. You don't
> buy brewery to have a beer to a dinner or you don't buy taxi car to get
> to airport. However many companies still have their own truck fleet.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> W dniu 09.07.2020 o 16:22, Joe Monk pisze:
> > Im sure that Kim Dotcom would love your legal theory...
> >
> > Joe
> >
> > On Thu, Jul 9, 2020 at 7:51 AM R.S. 
> wrote:
> >
> >> Azure? Cloud?
> >> There is no cloud. It is just someone else's computer. ;-)
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >>
> >> W dniu 08.07.2020 o 17:46, Joe Monk pisze:
> >>> I do a backup to spinning storage, then a copy of that backup to Azure
> >> for
> >>> long term.
> >>>
> >>> Joe
> >>>
> >>> On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz  wrote:
> >>>
> >>>> I've always gone with dual* backups, with one copy off site. Remote
> >>>> mirroring is a good option where policy permits, and even if
> >> retensioning
> >>>> is no longer relevant, rereading backups periodically will give you a
> >> heads
> >>>> up if one copy goes south. I would consider even correctable errors to
> >> be
> >>>> red flags.
> >>>>
> >>>> Any medium you use will have failure modes.
> >>>>
> >>>> Multiple PiT recovery is good for "whoops!" moments and possibly for
> >>>> audits.
> >>>>
> >>>> Large or small, each shop must do it's own risk assessments in the
> >> context
> >>>> of its own obligations and priorities.
> >>>>
> >>>> * Depending on the value of the data, you might want more than 2.
> >>>>
> >>>>
> >>>> --
> >>>> Shmuel (Seymour J.) Metz
> >>>> http://mason.gmu.edu/~smetz3
> >>>>
> >>>> 
> >>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> >> behalf
> >>>> of Bill Ogden [og...@us.ibm.com]
> >>>> Sent: Wednesday, July 8, 2020 9:27 AM
> >>>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>>> Subject: Re: Storage & tape question
> >>>>
> >>>> Probably many others will chime in on this. I have lost RAID 5 arrays
> >> with
> >>>> two disk failures within an hour of each other. RAID is nice, but one
> >> must
> >>>> allow for failures.
> >>>>
> >>>> Long ago I was involved with reading archived tapes and transferring
> the
> >>>> data to CDs. The programs involved were home-written and the project
> >> ended
> >>>> up going nowhere. However, we discovered that tapes  kept too long
> >> started
> >>>> having errors. (At that point, for the CD copy, we just logged the
> error
> >>>> and accepted the corrupt data; what else could we do?) How long is
> "too
> >>>> long"?? It was variable, but measured in a few years. The advice then
> >> was
> >>>> to minimally read the tapes every year or so to "retension" them.
> Don't
> >>>> know if this would apply to more modern tape media.  (We also
> discovered
> >>>> that locally "burned" CDs are not expected last forever.)
> >>>>
> >>>> IMHO, the key point for tape backups are (1) off-site storage, (2)
> >>>> multiple PiT recov

Re: Storage & tape question

[Joe Monk]

"Regarding Kim - AFAIK he was was found innocent. I'm talking about
Megaupload case, not several former cases."

Nope.He's still in New Zealand, fighting extradition to the USA for
criminal charges for the megaupload case.

Joe

On Mon, Jul 13, 2020 at 6:50 AM R.S.  wrote:

> OK, now I understand the legal aspect. I also disgree with that, but
> this is completely off-topic (and related to Kim's problems).
> However "something" as a service could mean colocation, PaaS, SaaS, etc.
> In some scenarios you buy working solution, not software license. In
> such case you are not responsible for the licenses. That's like cloud
> backup - I pay for backup, I'm not aware what backup software was used
> and wether it was licensed. I also don't check driver licence in a taxi,
> nor insurance policy. I pay for transfer to airport.
>
> Regarding Kim - AFAIK he was was found innocent. I'm talking about
> Megaupload case, not several former cases.
>
> BTW: interesting issue with data in a cloud. I did really use
> Megaupload. I don't feel uncomfortable with that, because I used it for
> transfer my photographs to a person who asked me for. My pictures from
> some tour. My selection of pictures with this guy and his wife (their
> camere failed, so I helped them). I uploaded it to Megaupload. Used
> password for privacy and sent password and link to this guy. Files were
> safe - everthing was in a cloud. Suddenly someone decided to destroy the
> service. Was he right? Not in case of my pictures. However he didn't
> care. More: legal court sentence was it wasn't right. What about my
> pictures? They gone.
> What can I do? Fortunately I have my own backup, so I had to repeat
> selection of the pictures and send it using other method.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 13.07.2020 o 13:25, Joe Monk pisze:
> > My point is, once you rent that computer and put your stuff on it, it is
> no
> > longer "someone else's computer". It is now YOUR computer. YOU are
> > responsible for it.
> >
> > Joe
> >
> > On Mon, Jul 13, 2020 at 5:35 AM R.S. 
> wrote:
> >
> >> I heard about Kim Dotcom, but I don't understand what you mean.
> >> I'm not talking here about legal issues, so there is nothing to love.
> >> And the cloud is still someone else's computer, isn't it?
> >> Keeping data in cloud is still keeping data on someone else's media like
> >> disk or tape. Usually tape for large amounts and reasonable prices (with
> >> horrible access times). The main difference is you don't know where is
> >> your data.
> >>
> >> (off topic drift)
> >> Of course cloud is valuable in man cases, especially for smal and medium
> >> businesses. Sometimes "don't do it, use our services" is true. You don't
> >> buy brewery to have a beer to a dinner or you don't buy taxi car to get
> >> to airport. However many companies still have their own truck fleet.
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >> W dniu 09.07.2020 o 16:22, Joe Monk pisze:
> >>> Im sure that Kim Dotcom would love your legal theory...
> >>>
> >>> Joe
> >>>
> >>> On Thu, Jul 9, 2020 at 7:51 AM R.S. 
> >> wrote:
> >>>> Azure? Cloud?
> >>>> There is no cloud. It is just someone else's computer. ;-)
> >>>>
> >>>> --
> >>>> Radoslaw Skorupka
> >>>> Lodz, Poland
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> W dniu 08.07.2020 o 17:46, Joe Monk pisze:
> >>>>> I do a backup to spinning storage, then a copy of that backup to
> Azure
> >>>> for
> >>>>> long term.
> >>>>>
> >>>>> Joe
> >>>>>
> >>>>> On Wed, Jul 8, 2020 at 10:12 AM Seymour J Metz 
> wrote:
> >>>>>
> >>>>>> I've always gone with dual* backups, with one copy off site. Remote
> >>>>>> mirroring is a good option where policy permits, and even if
> >>>> retensioning
> >>>>>> is no longer relevant, rereading backups periodically will give you
> a
> >>>> heads
> >>>>>> up if one copy goes south. I would consider even correctable errors
> t

Re: Storage & tape question

[Joe Monk]

So you take the discussion off-topic by the whole "its someone else
computer" thing, and then run.

Gotcha.

Joe

On Mon, Jul 13, 2020 at 10:02 AM R.S. 
wrote:

> I'm not Kim's fan, nor fan of piracy, etc.
> However he is still free. After 8 years. Yes, in New Zealand, not in US.
> But he lives in New Zealand not in North Korea or Cuba, or Biafra.
> And he has new business named MEGA, similar to Megaupload. MEGA started
> 7 years ago and since then it is still working.
> My pictures are still lost, damaged by someone who decided. I'm still
> not going to sue anybody for that damage. ;-)
>
> Note: this is far from discussion about disks and tapes. This is my last
> message in this sub-thread.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> W dniu 13.07.2020 o 16:21, Joe Monk pisze:
> > "Regarding Kim - AFAIK he was was found innocent. I'm talking about
> > Megaupload case, not several former cases."
> >
> > Nope.He's still in New Zealand, fighting extradition to the USA for
> > criminal charges for the megaupload case.
> >
> > Joe
> >
> > On Mon, Jul 13, 2020 at 6:50 AM R.S. 
> wrote:
> >
> >> OK, now I understand the legal aspect. I also disgree with that, but
> >> this is completely off-topic (and related to Kim's problems).
> >> However "something" as a service could mean colocation, PaaS, SaaS, etc.
> >> In some scenarios you buy working solution, not software license. In
> >> such case you are not responsible for the licenses. That's like cloud
> >> backup - I pay for backup, I'm not aware what backup software was used
> >> and wether it was licensed. I also don't check driver licence in a taxi,
> >> nor insurance policy. I pay for transfer to airport.
> >>
> >> Regarding Kim - AFAIK he was was found innocent. I'm talking about
> >> Megaupload case, not several former cases.
> >>
> >> BTW: interesting issue with data in a cloud. I did really use
> >> Megaupload. I don't feel uncomfortable with that, because I used it for
> >> transfer my photographs to a person who asked me for. My pictures from
> >> some tour. My selection of pictures with this guy and his wife (their
> >> camere failed, so I helped them). I uploaded it to Megaupload. Used
> >> password for privacy and sent password and link to this guy. Files were
> >> safe - everthing was in a cloud. Suddenly someone decided to destroy the
> >> service. Was he right? Not in case of my pictures. However he didn't
> >> care. More: legal court sentence was it wasn't right. What about my
> >> pictures? They gone.
> >> What can I do? Fortunately I have my own backup, so I had to repeat
> >> selection of the pictures and send it using other method.
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >>
> >> W dniu 13.07.2020 o 13:25, Joe Monk pisze:
> >>> My point is, once you rent that computer and put your stuff on it, it
> is
> >> no
> >>> longer "someone else's computer". It is now YOUR computer. YOU are
> >>> responsible for it.
> >>>
> >>> Joe
> >>>
> >>> On Mon, Jul 13, 2020 at 5:35 AM R.S. 
> >> wrote:
> >>>> I heard about Kim Dotcom, but I don't understand what you mean.
> >>>> I'm not talking here about legal issues, so there is nothing to love.
> >>>> And the cloud is still someone else's computer, isn't it?
> >>>> Keeping data in cloud is still keeping data on someone else's media
> like
> >>>> disk or tape. Usually tape for large amounts and reasonable prices
> (with
> >>>> horrible access times). The main difference is you don't know where is
> >>>> your data.
> >>>>
> >>>> (off topic drift)
> >>>> Of course cloud is valuable in man cases, especially for smal and
> medium
> >>>> businesses. Sometimes "don't do it, use our services" is true. You
> don't
> >>>> buy brewery to have a beer to a dinner or you don't buy taxi car to
> get
> >>>> to airport. However many companies still have their own truck fleet.
> >>>>
> >>>> --
> >>>> Radoslaw Skorupka
> >>>> Lodz, Poland
> >>>>
> >>>>
> >>>>
> >>&g

Re: Copying Extended format datasets between partitions

[Joe Monk]

Why not just dump them, FTP the dump file between the two partitions, then
restore the dump file?

Joe

On Tue, Jul 14, 2020 at 8:11 AM R.S.  wrote:

> Well, that change the perspective. It's a pity you didn't mention it
> before ;-)
> In this case one step is better (faster) than two-step approach.
> However in this case you should share catalog (BCS). Then you can try to
> share storage group.
> Or do it from target system - you still need to share volumes and BCS,
> but you can read datasets from "foreign" volumes and write them to
> target volume.
> Caution: sharing catalog usually means unique dataset names. Do you
> accept dataset rename, i.e. change of HLQ?
> Of course it is possible to rename dataset names after that or maybe use
> some paths and aliases.
>
> Another approach is to divide the task. You submit dump of first part,
> then submit restore on target. Then submit second part dump, and after
> that restore... It's still two-step, but temporary storage is not so
> big. Or use tape...
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 14.07.2020 o 12:44, Gadi Ben-Avi pisze:
> > Thanks
> > I guess I'll have to bite the bullet. It's 393GB of files.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of R.S.
> > Sent: Tuesday, July 14, 2020 1:23 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Copying Extended format datasets between partitions
> >
> > You cannot do it.
> > Both datasets require to be DFSMS-managed and then cataloged.
> > So you have to share the catalog (BCS), otherwise you will get error or
> uncataloged datasets on SMS volume, which is also not the best idea.
> > Another method: dump you datasets to PS file on shared volume. Then
> restore it on target system. Much easier and less error-prone.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> > W dniu 14.07.2020 o 12:06, Gadi Ben-Avi pisze:
> >> HI,
> >> I have to copy extended format (PS-E and VS-E) datasets between
> partitions.
> >> The partitions share DASD but do not share anything else.
> >> They have different SMS configurations.
> >> The same Storage Group is defined in both partitions, but each
> partition has different volumes.
> >>
> >> I've been copying datasets between partitions like these for a while
> using this DFSMSdss copy command:
> >> COPY DATASET( -
> >>  INCLUDE( -
> >>  SYS1.IOA.V919.LNKLST -
> >>  SYS1.IODF24.CLUSTER -
> >>  )) -
> >>  REPLACE-
> >>  TOL(ENQF) -
> >>  BYPASSACS(**) -
> >>  NULLSTORCLAS  -
> >>  PROCESS(SYS1)  -
> >>  ALLDATA(*) ALLEXCP -
> >>  RECATALOG(ICFCAT.MCATZ23) -
> >>  OUTDYNAM(Z23R01) -
> >>  SHARE
> >>
> >> The catalog in the RECATALOG parameter is the catalog for the
> destination partition.
> >>
> >> Does anyone have an idea how to do this for SMS managed extended format
> datasets?
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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 

Re: Copying Extended format datasets between partitions

[Joe Monk]

I would agree with you if this weren't an LPAR to LPAR copy. So, there's a
direct connection between the LPARs, and most of the worries that you are
concerned about dont really exist in that situation.

Joe

On Tue, Jul 14, 2020 at 9:39 AM R.S.  wrote:

> Because of reasons. ;-)
> Seriously: it is better to make it simpler and faster.
>
> Your method: dump, ftp, restore.
> Other methods: a) dump, restore. b) copy.
> Which is faster?
> Which consume less CPU?
> Which require less disk space for intermediate copies?
>
> Not to mention issues with RECFM=U and ftp.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 14.07.2020 o 15:26, Joe Monk pisze:
> > Why not just dump them, FTP the dump file between the two partitions,
> then
> > restore the dump file?
> >
> > Joe
> >
> > On Tue, Jul 14, 2020 at 8:11 AM R.S. 
> wrote:
> >
> >> Well, that change the perspective. It's a pity you didn't mention it
> >> before ;-)
> >> In this case one step is better (faster) than two-step approach.
> >> However in this case you should share catalog (BCS). Then you can try to
> >> share storage group.
> >> Or do it from target system - you still need to share volumes and BCS,
> >> but you can read datasets from "foreign" volumes and write them to
> >> target volume.
> >> Caution: sharing catalog usually means unique dataset names. Do you
> >> accept dataset rename, i.e. change of HLQ?
> >> Of course it is possible to rename dataset names after that or maybe use
> >> some paths and aliases.
> >>
> >> Another approach is to divide the task. You submit dump of first part,
> >> then submit restore on target. Then submit second part dump, and after
> >> that restore... It's still two-step, but temporary storage is not so
> >> big. Or use tape...
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> >>
> >>
> >>
> >>
> >> W dniu 14.07.2020 o 12:44, Gadi Ben-Avi pisze:
> >>> Thanks
> >>> I guess I'll have to bite the bullet. It's 393GB of files.
> >>>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >> Behalf Of R.S.
> >>> Sent: Tuesday, July 14, 2020 1:23 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Copying Extended format datasets between partitions
> >>>
> >>> You cannot do it.
> >>> Both datasets require to be DFSMS-managed and then cataloged.
> >>> So you have to share the catalog (BCS), otherwise you will get error or
> >> uncataloged datasets on SMS volume, which is also not the best idea.
> >>> Another method: dump you datasets to PS file on shared volume. Then
> >> restore it on target system. Much easier and less error-prone.
> >>> --
> >>> Radoslaw Skorupka
> >>> Lodz, Poland
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> W dniu 14.07.2020 o 12:06, Gadi Ben-Avi pisze:
> >>>> HI,
> >>>> I have to copy extended format (PS-E and VS-E) datasets between
> >> partitions.
> >>>> The partitions share DASD but do not share anything else.
> >>>> They have different SMS configurations.
> >>>> The same Storage Group is defined in both partitions, but each
> >> partition has different volumes.
> >>>> I've been copying datasets between partitions like these for a while
> >> using this DFSMSdss copy command:
> >>>> COPY DATASET( -
> >>>>   INCLUDE( -
> >>>>   SYS1.IOA.V919.LNKLST -
> >>>>   SYS1.IODF24.CLUSTER -
> >>>>   )) -
> >>>>   REPLACE-
> >>>>   TOL(ENQF) -
> >>>>   BYPASSACS(**) -
> >>>>   NULLSTORCLAS  -
> >>>>   PROCESS(SYS1)  -
> >>>>   ALLDATA(*) ALLEXCP -
> >>>>   RECATALOG(ICFCAT.MCATZ23) -
> >>>>   OUTDYNAM(Z23R01) -
> >>>>   SHARE
> >>>>
> >>>> The catalog in the RECATALOG parameter is the catalog for the
> >> destination partition.
> >>>> Does anyone have an idea how to do this for SMS managed extended
> format
> >> datasets?
> >>
> >>
> >>
>
>
>
> =

Re: Using AN EAX value of PC Routineto index into the Authority Table

[Joe Monk]

This is explained on page 113:

"The example also shows the difference between cross memory data movement
with a move to primary (MVCP) and a data movement performed through ARs and
the MVC instruction. PGM1 uses the SSAR instruction to establish AS2 as the
secondary address space, then it uses MVCP to move data from AS2 to AS1.
PCRTN issues the SAC instruction to change the ASC mode to AR mode. Having
loaded the addresses and ALETs into the AR/GPR correctly, PCRTN uses MVC to
move data from AS2 to AS1."

Joe

On Sat, Jul 18, 2020 at 1:56 PM esst...@juno.com  wrote:

> Hello. I’m reading Chapter 5 Using Access Registers in MVS
> Programming Extended Addressability Guide (SA23-1394-30). Pages 113 –
> 116 “Procedures for establishing addressability to an address
> space”Regarding Figure 38I understand the EAX value of PCRTN indexes
> into the AT of AS2.I understand PC routine contains an ALESERV ADD request
> for an address spaceI understand Issuing the ETDEF macro to build the PC
> routine's ETD with the EAX parameter code.It’s the Target Address
> Space (AS2) that I have issues with.First of all – I am assuming
> PCRTN resides in the Private Area of the Accessing Address Space (AS1) and
> PCRTN is defined as a Non- Space Switching, Stacking PC , with a System LX.
> Is My understanding correct ?.Second - if AS2 (The Target Address space)
> can switch to Supervisor State, issue ATSET and a Cross Memory Post why
> can’t it simply Establish and Setup Its Own Cross Memory Environment,
> allowing AS1 or any other Address Space the capability of issuing a PC
> calls to it directly ? The procedure described for AS2 in Figure 38 seems
> un-necessary to me..Third – Given the technique described for Figure
> 38 – wouldn’t it be more appropriate for AS1 to define two
> Non-Space Switching PC routines. One residing in the Private Area of AS1,
> and the other in LPA. This would allow AS2 to PC to the second PC routine
> (in LPA) to issue ATSET and a Cross Memory POST. Does this make better
> sense?.Fourth – is any one on this discussion list aware of any IBM
> product, or OEM Vendor product, or installation written software, that uses
> the technique described with Figure 38 ?.Paul D’Angelo.
>
> --
> 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: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

"Historically, COBOL made the wrong choice when they codified COPY for
INCLUDE and used MOVE."

I respectfully disagree. COBOL's mother is FLOW-MATIC. MOVE was in
FLOW-MATIC.

Joe

On Sat, Jul 18, 2020 at 6:52 PM Wayne Bickerdike  wrote:

> Bob,
>
> David didn't say there were languages that did "moves". He said that there
> are several languages that implement a copy verb that does what MOVE does
> in COBOL.
>
> Historically, COBOL made the wrong choice when they codified COPY for
> INCLUDE and used MOVE.
>
> On Sun, Jul 19, 2020 at 12:51 AM Bob Bridges 
> wrote:
>
> > You may have done so - by now I don't remember who said what first :) -
> > but I was referring to Mr Crayford's post below.  As I understood them,
> > Tony Thigpen wrote that a MOVE is actually a copy, and Mr Crayford
> > disagreed.  I'm confused; is there any computer language in which the
> verb
> > MOVE exists and doesn't actually mean COPY?
> >
> > ...or SET, as you suggest.  Yes, I like SET better.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* In all affairs it's a healthy thing now and then to hang a question
> > mark on the things you have long taken for granted.  -Bertrand Russell
> > (1872-1970) */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Wayne Bickerdike
> > Sent: Saturday, July 18, 2020 04:42
> >
> > I referred to this since someone said that COBOL is English like. As such
> > the language is wrong because it does not describe correctly in English
> > what happens. COPY, REPLICATE, PROPAGATE would all be more precise
> English.
> >
> > IDEAL(CA/Broadcom)  has MOVE and SET. They do the same thing. Which do
> you
> > prefer:
> >
> > MOVE A TO B or
> > SET B = A ?
> >
> > --- On Sat, Jul 18, 2020 at 4:30 PM Bob Bridges 
> > wrote:
> > > Am I missing something obvious, here?  In what computer language(s) is
> a
> > > move not actually a copy?  And how?
> > >
> > > -Original Message-
> > > From: David Crayford
> > > Sent: Friday, July 17, 2020 00:53
> > >
> > > I beg to differ! For the programming languages I code in use there is a
> > > huge difference between copy and move semantics.
> > >
> > > --- On 2020-07-17 11:12 AM, Tony Thigpen wrote:
> > > > From the start, MOVE in the programming world has been equated to
> what
> > > > you are calling a COPY.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Wayne V. Bickerdike
>
> --
> 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: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

"Is that why you took the U out of COLOUR and LABOUR and the I from
ALUMINIUM? Or is it the Elizabethan English that America adopted?
Perpetuating Manglish?"

Do you bite your thumb at me sir?

The British Scientist (Davy) who discovered ALUMINUM named it that. It is
we Americans who are using the correct name ... the British press felt that
it should be in line with sodium and potassium and thus added to the
spelling.

Taking the "U" out of color and labor was a cost-saving measure. By doing
so, it was estimated to save a page every eighteen. In the 1700's saving
money on printing was no small endeavor.

Joe

On Sat, Jul 18, 2020 at 10:17 PM Wayne Bickerdike  wrote:

> *"I respectfully disagree. COBOL's mother is FLOW-MATIC. MOVE was
> inFLOW-MATIC."*
>
> Is that why you took the U out of COLOUR and LABOUR and the I from
> ALUMINIUM? Or is it the Elizabethan English that America adopted?
> Perpetuating Manglish?
>
> On Sun, Jul 19, 2020 at 12:57 PM Seymour J Metz  wrote:
>
> > What are COMTRAN and FACT, chopped liver?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > ________
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Joe Monk [joemon...@gmail.com]
> > Sent: Saturday, July 18, 2020 10:41 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: OOBOL and English was Re: Still COBOL After All These Years?
> >
> > "Historically, COBOL made the wrong choice when they codified COPY for
> > INCLUDE and used MOVE."
> >
> > I respectfully disagree. COBOL's mother is FLOW-MATIC. MOVE was in
> > FLOW-MATIC.
> >
> > Joe
> >
> > On Sat, Jul 18, 2020 at 6:52 PM Wayne Bickerdike 
> > wrote:
> >
> > > Bob,
> > >
> > > David didn't say there were languages that did "moves". He said that
> > there
> > > are several languages that implement a copy verb that does what MOVE
> does
> > > in COBOL.
> > >
> > > Historically, COBOL made the wrong choice when they codified COPY for
> > > INCLUDE and used MOVE.
> > >
> > > On Sun, Jul 19, 2020 at 12:51 AM Bob Bridges 
> > > wrote:
> > >
> > > > You may have done so - by now I don't remember who said what first
> :) -
> > > > but I was referring to Mr Crayford's post below.  As I understood
> them,
> > > > Tony Thigpen wrote that a MOVE is actually a copy, and Mr Crayford
> > > > disagreed.  I'm confused; is there any computer language in which the
> > > verb
> > > > MOVE exists and doesn't actually mean COPY?
> > > >
> > > > ...or SET, as you suggest.  Yes, I like SET better.
> > > >
> > > > ---
> > > > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> > > >
> > > > /* In all affairs it's a healthy thing now and then to hang a
> question
> > > > mark on the things you have long taken for granted.  -Bertrand
> Russell
> > > > (1872-1970) */
> > > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ]
> > On
> > > > Behalf Of Wayne Bickerdike
> > > > Sent: Saturday, July 18, 2020 04:42
> > > >
> > > > I referred to this since someone said that COBOL is English like. As
> > such
> > > > the language is wrong because it does not describe correctly in
> English
> > > > what happens. COPY, REPLICATE, PROPAGATE would all be more precise
> > > English.
> > > >
> > > > IDEAL(CA/Broadcom)  has MOVE and SET. They do the same thing. Which
> do
> > > you
> > > > prefer:
> > > >
> > > > MOVE A TO B or
> > > > SET B = A ?
> > > >
> > > > --- On Sat, Jul 18, 2020 at 4:30 PM Bob Bridges <
> robhbrid...@gmail.com
> > >
> > > > wrote:
> > > > > Am I missing something obvious, here?  In what computer language(s)
> > is
> > > a
> > > > > move not actually a copy?  And how?
> > > > >
> > > > > -Original Message-
> > > > > From: David Crayford
> > > > > Sent: Friday, July 17, 2020 00:53
> > > > >
> > > > > I beg to differ! For the programming languages I code in use there
> > is a
> > > &g

Re: Using AN EAX value of PC Routineto index into the Authority Table

[Joe Monk]

"Sorry for the garbled message -.If the AS2 has the capability of switching
to supervisor state; why can't it (AS2) create
its own Cross Memory environment allowing Address Space (AS1) the ability
to issue a PC to AS2 and the PC Service Routine use AR Mode to transfer
data from the Target Address Space (AS2) to the Accessing Address Space
(AS1) ?"

How does it know what address space is the accessing address space (AS1)
before it is called by that address space?

Joe



On Sun, Jul 19, 2020 at 6:39 AM esst...@juno.com  wrote:

> -- Original Message ------
> From: Joe Monk 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using AN EAX value of PC Routineto index into the Authority
> Table
> Date: Sat, 18 Jul 2020 20:27:39 -0500
>
> This is explained on page 113:
>
> "The example also shows the difference between cross memory data movement
> with a move to primary (MVCP) and a data movement performed through ARs and
> the MVC instruction. PGM1 uses the SSAR instruction to establish AS2 as the
> secondary address space, then it uses MVCP to move data from AS2 to AS1.
> PCRTN issues the SAC instruction to change the ASC mode to AR mode. Having
> loaded the addresses and ALETs into the AR/GPR correctly, PCRTN uses MVC to
> move data from AS2 to AS1."
>
> Joe
>
> On Sat, Jul 18, 2020 at 1:56 PM esst...@juno.com  wrote:
>
> > Hello. I’m reading Chapter 5 Using Access Registers in MVS
> > Programming Extended Addressability Guide (SA23-1394-30). Pages 113
> –
> > 116 “Procedures for establishing addressability to an address
> > space”Regarding Figure 38I understand the EAX value of PCRTN
> indexes
> > into the AT of AS2.I understand PC routine contains an ALESERV ADD
> request
> > for an address spaceI understand Issuing the ETDEF macro to build the PC
> > routine's ETD with the EAX parameter code.It’s the Target Address
> > Space (AS2) that I have issues with.First of all – I am assuming
> > PCRTN resides in the Private Area of the Accessing Address Space (AS1)
> and
> > PCRTN is defined as a Non- Space Switching, Stacking PC , with a System
> LX.
> > Is My understanding correct ?.Second - if AS2 (The Target Address space)
> > can switch to Supervisor State, issue ATSET and a Cross Memory Post why
> > can’t it simply Establish and Setup Its Own Cross Memory
> Environment,
> > allowing AS1 or any other Address Space the capability of issuing a PC
> > calls to it directly ? The procedure described for AS2 in Figure 38 seems
> > un-necessary to me..Third – Given the technique described for
> Figure
> > 38 – wouldn’t it be more appropriate for AS1 to define two
> > Non-Space Switching PC routines. One residing in the Private Area of AS1,
> > and the other in LPA. This would allow AS2 to PC to the second PC routine
> > (in LPA) to issue ATSET and a Cross Memory POST. Does this make better
> > sense?.Fourth – is any one on this discussion list aware of any IBM
> > product, or OEM Vendor product, or installation written software, that
> uses
> > the technique described with Figure 38 ?.Paul D’Angelo.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

Centigrade? It always thought it's Celsius. :)

Joe

On Wed, Jul 22, 2020 at 11:16 AM Bob Bridges  wrote:

> Interesting; centigrade is the one system I use nowadays without having to
> think much about it.  It's so easy:  0s are cold, 10s are cool, 20s are
> warm, 30s are hot.
>
> I get kilometers but I think in miles.  For short measurements I like
> centimeters and millimeters, but I couldn’t tell you how tall I am in cm.
> I'm happy in either pounds or kilos, but I'd have to calculate to tell you
> how many kg I weigh.  But centigrade makes complete sense to me.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* If you read the New Testament with an Old-Covenant heart, it will be
> just
> Law to you.  Likewise, if you read the Old Testament with a New-Covenant
> heart, you will see Christ in all of it.  -Rick Joyner, “The Apostolic
> Ministry” */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jackson, Rob
> Sent: Monday, July 20, 2020 23:23
>
> It disturbs me that I agree with Shmuel three times in as many days.
>
> Tony, what's your mass here lately after Insanity-19?  Let's have it in
> slugs, please, since that's the unit.  Take you a dram and a scruple; add
> in
> a grain or two for precision, but make sure you convert it to mass.
>
> American standard--Imperial units; they're rubbish.  Abject garbage.  SI is
> not a fad, despite its origins.  No fan of the "French;" no fan of "Trump;"
> no fan of anything political.  But SI, revised a couple times or three, is
> a
> beautiful system of units in which one may compute physics.  If you
> disagree, then I assert you have a challenge understanding many things
> about
> physics.  I'm talking about mechanics and fluid dynamics.  I'm too stupid
> for E&M, although the same equivalency attempts apply there.
>
> P.S.  Apparently Imperial units have been redefined as relative to SI.
> Imagine that.  https://www.britannica.com/topic/Imperial-unit
>
> P.P.S.  This reminds me of many conversations with my father.  He
> absolutely
> couldn't stand this type of thing, i.e. SI being obviously superior.  I
> don't get it.  It is what it is.
>
> As a disclaimer, I'm not a complete bigot.  I say miles and yards; but I
> have this nasty habit of converting them to meters in my mind every time I
> say them.  The one thing I cannot get used to in every-day life is Celsius
> degrees.  I think in Fahrenheit degrees.  Oddly enough, since they're
> exactly the same thing, I find it easier to talk in Kelvins rather than
> Celsius degrees.  Maybe I just like starting at zero.  :)  I couldn't tell
> you what absolute zero in Fahrenheit is; I guess I never cared.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Seymour J Metz
> Sent: Monday, July 20, 2020 5:02 PM
>
> The practical value doesn't depend on how it started. Yes, I could say all
> sorts of things about how the mob interpreted "Liberté, égalité,
> fraternité", but it doesn't change the fact that nobody understands the
> English system of units. How many gills in a gallon? (That's a trick
> question; it depends on which kind of gallon.) How many ounces in a ton?
> Can
> you convert furlongs per fortnight to miles per hour?
>
> --
> 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: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

The measure of weight is a kgf. Kilogram force. It is a kilogram multiplied
by 9.8 (gravity force).

But in shorthand we say kilogram.

On Wed, Jul 22, 2020, 15:36 Pommier, Rex  wrote:

> A kilogram may not technically be a weight, but if not the whole world, at
> least a large percentage of the world uses it as such.  Looking at a
> package of dried fruit in front of me and it says net weight 340 grams
> which I believe translates to .34 kilograms.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Jackson, Rob
> Sent: Wednesday, July 22, 2020 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: OOBOL and English was Re: Still COBOL After All
> These Years?
>
> A kilogram is not a weight, Bob.  Never has been; never will be.  I'm not
> one to be anal-retentive.  This point is more important than anything like
> that.
>
> I like your quote.  That was a wise person.
>
> First Horizon Bank
> Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Wednesday, July 22, 2020 2:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OOBOL and English was Re: Still COBOL After All These Years?
>
> [External Email. Exercise caution when clicking links or opening
> attachments.]
>
> Who doesn't?  You may not, but lots of other people do.  What am I
> missing, here?
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* A human being should be able to change a diaper, plan an invasion,
> butcher a hog, conn a ship, design a building, write a sonnet, balance
> accounts, build a wall, set a bone, comfort the dying, take orders, give
> orders, cooperate, act alone, solve equations, analyze a new problem, pitch
> manure, program a computer, cook a tasty meal, fight efficiently, die
> gallantly.  Specialization is for insects.  -Lazarus Long */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jackson, Rob
> Sent: Wednesday, July 22, 2020 12:22
>
> My high school physics teacher would be rolling in his grave about now.
> You don't weigh anything in kilograms.  :)
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Wednesday, July 22, 2020 12:16 PM
>
> Interesting; centigrade is the one system I use nowadays without having to
> think much about it.  It's so easy:  0s are cold, 10s are cool, 20s are
> warm, 30s are hot.
>
> I get kilometers but I think in miles.  For short measurements I like
> centimeters and millimeters, but I couldn't tell you how tall I am in cm.
> I'm happy in either pounds or kilos, but I'd have to calculate to tell you
> how many kg I weigh.  But centigrade makes complete sense to me.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> Confidentiality notice:
> This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
> --
> 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: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

Kelvin (absolute temperature) is converted from Celsius. Centigrade doesn't
exist.

On Wed, Jul 22, 2020, 13:46 Jackson, Rob  wrote:

> We have definitely devolved . . . like we always do on this forum.  It's
> fun though, right?
>
> I agree on Celsius.  The name disturbs me too.  Centigrade is more
> pleasant for some reason.  Reminds me of tardigrade.  Now that is something
> we could all ponder and be better off.
>
> First Horizon Bank
> Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Bob Bridges
> Sent: Wednesday, July 22, 2020 2:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OOBOL and English was Re: Still COBOL After All These Years?
>
> [External Email. Exercise caution when clicking links or opening
> attachments.]
>
> I just think the word "Celsius" is ugly; "centigrade" is comparatively
> euphonious.  A personal bias.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Do you know what constitutes a "hate crime"?  Put your thinking caps
> on.  What tools do we need to determine whether a crime was motivated by
> hate or prejudice?  Answer: We need thought police.  -from "See, I Told You
> So" by Rush Limbaugh */
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Monk
> Sent: Wednesday, July 22, 2020 12:17
>
> Centigrade? It always thought it's Celsius. :)
>
> --- On Wed, Jul 22, 2020 at 11:16 AM Bob Bridges 
> wrote:
> > Interesting; centigrade is the one system I use nowadays without
> > having to think much about it.  It's so easy:  0s are cold, 10s are
> > cool, 20s are warm, 30s are hot.
> >
> > -Original Message-
> > From: Jackson, Rob
> > Sent: Monday, July 20, 2020 23:23
> >
> > As a disclaimer, I'm not a complete bigot.  I say miles and yards; but
> > I have this nasty habit of converting them to meters in my mind every
> > time I say them.  The one thing I cannot get used to in every-day life
> > is Celsius degrees.  I think in Fahrenheit degrees.  Oddly enough,
> > since they're exactly the same thing, I find it easier to talk in
> > Kelvins rather than Celsius degrees.  Maybe I just like starting at
> > zero.  :)  I couldn't tell you what absolute zero in Fahrenheit is; I
> guess I never cared.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> Confidentiality notice:
> This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
>
>
> --
> 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: DFSORT task (I hope)

[Joe Monk]

If you want to do it DFSORT, I think you'll have to use ICETOOL with the
SPLICE option.

Joe

On Thu, Jul 23, 2020 at 3:11 AM R.S.  wrote:

> I have the following case:
>
> Large (thousands) list containing filenames,
> filea10002
> fileb10041
> filec20043
> filed39093
> longfileabc
> anotherfile
> ...
>
> and small (dozens) list of filename "exlusions"
> longfileabc
> fileb10041
> ...
>
> Short list is subset of long list. All files has fixed lentgh name, no
> other fields exist in the record.
> The goal is to exclude from large list all the entries which are present
> in the short list.
> Lists are unsorted, but I think it doesn't matter. I see it is candidate
> for REXX script, but DFSORT job seems to be more elegant.
> Any clue?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

"Lb Foot is not a measure of pressure" ... correct. It is a measure of
torque.

A pound-foot (lbf⋅*ft*) is a unit of torque (a pseudovector). One
pound-foot is the torque created by one pound of force acting at a
perpendicular distance of one foot from a pivot point. Conversely one
pound-foot is the moment about an axis that applies one pound-force at a
radius of one foot.

Joe

On Wed, Jul 22, 2020 at 10:08 PM Wayne Bickerdike  wrote:

> Time for us to go back to school.
>
> Lb Foot is not a measure of pressure, it needs to act on area to be a
> measure of pressure. Lbs / square foot/ PSI etc. are common measurements of
> pressure (tires etc.).
>
> In the 60's we were taught poundals as a measure of force, ie the force
> required to accelerate  a mass of one pound at a rate of one foot per
> second per second.
>
> Thankfully SI came to the rescue by the time I went to college.
> Isaac Newton, quintessentially English gets an SI unit, as does Faraday,
> Tesla, Curie. Very multicultural...
>
>
> On Thu, Jul 23, 2020 at 12:44 PM Mike Schwab 
> wrote:
>
> > And the metric equivalent is Newton Meters.  You can get torque
> > wrenches in either measurement, I would think some have both.  Some
> > bolts will fail if too loose or too tight.
> >
> > On Wed, Jul 22, 2020 at 7:31 PM Gibney, Dave  wrote:
> > >
> > > Foot pounds is a measure of pressure
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Seymour J Metz
> > > > Sent: Wednesday, July 22, 2020 5:29 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > >
> > > > Yes, and whyat is lbf?
> > > >
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> > > > BY0HMszNaDT!78SA9VzAdbjMTRYvnKQIT6jc0VOHrKWRan9aUIqsjvsI210oVzT
> > > > j6BY-5Ot12g$
> > > >
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > > > behalf of Gibney, Dave 
> > > > Sent: Wednesday, July 22, 2020 8:26 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > >
> > > > Actually, the pound is a unit of force in English units. I believe
> > weight is
> > > > measured in stones.
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List  On
> > > > > Behalf Of Seymour J Metz
> > > > > Sent: Wednesday, July 22, 2020 4:23 PM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > > >
> > > > > You have the same mass versus weight issue with pound.
> > > > >
> > > > >
> > > > > --
> > > > > Shmuel (Seymour J.) Metz
> > > > >
> > > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> > > > >
> > > > BY0HMszNaDT!6qfIOAdssnfWNb9bnHdVr6MfJemAcckz1N2FLwezCZtDcak8bJ
> > > > > a3JHuDBIGmlQ$
> > > > >
> > > > > 
> > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > > > > behalf of Tony Thigpen [t...@vse2pdf.com]
> > > > > Sent: Wednesday, July 22, 2020 6:05 PM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > > >
> > > > > See! SI is a "FANTASTIC" improvement over old stuff. It's all
> > > > > standardized and everyone talks in the same way. (NOT!)
> > > > >
> > > > > Thank you France.
> > > > >
> > > > > Vive la pound, and inch, and mile...
> > > > >
> > > > > (This post was posted with sarcastic mode set to "on".)
> > > > >
> > > > > Tony Thigpen
> > > > >
> > > > > Paul Gilmartin wrote on 7/22/20 5:58 PM:
> > > > > > On Wed, 22 Jul 2020 17:05:29 +, Seymour J Metz wrote:
> > > > > >
> > > > > >> I took me a while before I realized that, of course, kg is a
> unit
> > of mass,
> > > > not
> > > > > of weight; you weigh tings in kilogram-force (kgf or kgF).
> > > > > >>
> > > > > > Which of the following would you envision and welcome as an
> > idiomatic
> > > > > > alternative?:
> > > > > > o ... how many kg I mass?
> > > > > > o ... how many kgF I weigh?
> > > > > > o Other (specify)?
> > > > > >
> > > > > > Should an outfitter sell climbing ropes rated in Newtons?
> > > > > >
> > > > > > (BTW, what's the SI unit of Specific Impulse?  And the formula
> for
> > ∆v?
> > > > > Ugh!)
> > > > > >
> > > > > >> 
> > > > > >> From: Jackson, Rob
> > > > > >> Sent: Wednesday, July 22, 2020 12:21 PM
> > > > > >>
> > > > > >> -Original Message-
> > > > > >> From: Bob Bridges
> > > > > >> Sent: Wednesday, July 22, 2020 12:16 PM
> > > > > >>
> > > > > >> [External Email. Exercise caution when clicking links or opening
> > > > > attachments.]
> > > > > >>
> > > > > >> ... I'd have to calculate to tell you how many kg I weigh.
> > > > > >
> > > > > > -- gi

Re: Influence of IBSYS/IBJOB on OS/360

[Joe Monk]

I dont think you'll find such a thing.

I always thought IBSYS/IBJOB were the predecessors of DOS/360, and DOS/360
was written as a temporary holdover to run on the 360 until OS was ready,
because OS was completely new implementation of things on the new machine
(i.e.  a completely new OS).

Joe

On Sun, Jul 26, 2020 at 5:39 PM Seymour J Metz  wrote:

> That's certainly where I go for manuals, but I'm not aware of any
> historical documents on bitsavers going into the history of OS/360 and what
> influenced it. I was hoping for an online reprint of relevant articles
> from, e.g., CACM, IBM Journal of Research and Development, IBM Systems
> Journal. Thanks.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Mark Jacobs [0224d287a4b1-dmarc-requ...@listserv.ua.edu]
> Sent: Sunday, July 26, 2020 6:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Influence of IBSYS/IBJOB on OS/360
>
> I haven't dug into anything here, but this might be something to look at.
> http://secure-web.cisco.com/1XBYfOiRCaSxGJEfUHzAE6zFAk_s-r9c9YBuYxxcz7AaK72_SELNp6GV4pSfzPM9bojxTQ7FRegl1TiNfmaxJCDI1DqKMWgxBM64c6VlHqbV--W5oKpQeSC4lbrvFj7mFtDN4mQW49mCNAsM_7JFgCk4aoi2XaGqTCG7UlBxkl5g94hAe8T4QywxuwSqeOatKiYKRMLpUpdoqq1xKJUm2jvKeG1slvZhCslt4wEp8Ls9HW6r7A60muJXNL2NT7n6RwLZPvb4HU4rHLH2fqvZYf1fCWXGJ2UKXporCsV4IcRwszDDG98uNOiN5jD7823Eyu27JbczOZkWb9Kw7NeZGOoq1h_wRZsOw89zT2FoYa7etW8mRszp2DXA67hVtq6G5RUsVDyNIHKoebwaoB_oKayZOt7ruzOa56H-sOs9VhP4GfL8kyYaJ5YeXOFWYMXex/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F360%2F
>
> Mark Jacobs
>
> Sent from ProtonMail, Swiss-based encrypted email.
>
> GPG Public Key -
> https://secure-web.cisco.com/1GB8QC-i7N7jc_SDSDsn2Xgj6HAQqtmDDH4834_7aag-_xPNlbNpm916vQZ4jjvq23_1PzfwmzoRMaCrgx_JrNDqpKbvEsKU4g1nGmOLvNoFE-H98fMun_04Sb0vJbuenzkBxMMn3q_yDnjDildwDuABexYKFmr4F28DEvSgTYVTe019gJMGg_JLuIpt7rfEkNExUj8zwmdUkd3tvgPcqtoMSuTg_UOTsiycvCZ5H-z-MQeEvXM8V0Yd9yF0xVf4tLpsJGgrl8RbHg3EhF_SUxDsf-3uQGZWdR7JGq1NfnrUsXPKSKKXNAyaX97k3j1iAHp7uc3WirZ9rIuF1pO8ImF19jQU3Ke1svDv4gVz_mrkA16coO97SQ6XLyaMNhLnI_BTtbD2o_ZT75sG8JgNUXpV9n-VzjN-bal7QLoTLP7Uc5G-kwzgGGCk5r8CIHyKU/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com
>
> ‐‐‐ Original Message ‐‐‐
> On Sunday, July 26, 2020 5:23 PM, Seymour J Metz  wrote:
>
> > Does anybody have a reference that I can cite on wikipedia, describing
> the influence of IBSYS/IBJOB on the design of OS/360?
> >
> >
> >
> --
> >
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Keeping TSO users our of CICS

[Joe Monk]

You can get around the problem with an MPF exit to automatically REVOKE.
Look at CBT 708.

Joe

On Mon, Jul 27, 2020 at 3:32 PM McCabe, Ron 
wrote:

> Hello IBM Listers,
>
> Got an interesting problem that I would like to know how we can avoid.
> Our Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can
> reset passwords and define new users.  These TSO accounts are not defined
> to CICS but every once in awhile one of them will try to login to CICS
> using their TSO account and after messing up their password 3 times the
> system puts out an ICH302D message asking if we want to REVOKE them or let
> them try again (we REVOKE), this message waits for a reply and while it is
> waiting CICS hangs until a reply is given.  We thought about defining their
> TSO accounts to CICS but that does not help if they actually do mess up
> their password.  We thought we could do it with RACF but RACF doesn't check
> any authorization until "after" the user successfully signs on so we would
> still get the ICH302D message.
>
> Does anyone else run into this problem?  Is there a way we can get around
> this problem?  We thought about having MSGTABLE do an automated response
> but there could be times when we don't want to have the user REVOKED.
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
>
>
> Confidentiality Notice: This e- mail and all attachments may contain
> CONFIDENTIAL information and are meant solely for the intended recipient.
> It may contain controlled, privileged, or proprietary information that is
> protected under applicable law and shall not be disclosed to any
> unauthorized third party. If you are not the intended recipient, you are
> hereby notified that any unauthorized review, action, disclosure,
> distribution, or reproduction of any information contained in this e- mail
> and any attachments is strictly PROHIBITED. If you received this e- mail in
> error, please reply to the sender immediately stating that this
> transmission was misdirected, and delete or destroy all electronic and
> paper copies of this e-mail and attachments without disclosing the
> contents. This e- mail does not grant or assign rights of ownership in the
> proprietary subject matter herein, nor shall it be construed as a joint
> venture, partnership, teaming agreement, or any other formal business
> relationship.
>
> --
> 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: Started task stopping immediately. No error messages.

[Joe Monk]

IMHO, the clue to this is in his printout.

PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'

IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002

So, it looks some exit is killing the task because he has REGION=0M.

The SMFLIMxx policy is killing the task (ONOUDONT).

Joe


On Mon, Jul 27, 2020 at 4:42 PM Charles Mills  wrote:

> Oh man! Talk about user-hostile programming. How could anyone ship a
> customer-facing program that detects an error and then just quits with (a.)
> RC=0 and (b.) no message whatsoever. No "Hello World I am FTPD V2R3" and no
> error message. Even if you can't open your usual log or listing file you
> can
> WTO 'Unable to open SYSPRINT' (or whatever) or issue a documented ABEND.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Monday, July 27, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> It looks like you're using JES3. I thought thad SDSF didn't support it.
>
> CC 0 would have been a useful datum in the original question. It looks like
> the FTP server doesn't issue an informational message when a copy is
> already
> running. RFE?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of
> Skippy the Ancient [kkin...@email.com]
> Sent: Monday, July 27, 2020 8:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> Responding to all posters, not just Mr Metz.
>
> 1. I already tried calling the proc from JCL.  It ran, stopped immediately
> and returned no error messages.
> 2. I started the proc with the MSGCLASS and did receive output.  It was
> identical to the JCL call; immediate stop and no error messages.  I will
> post this below.
> 3. The started task is a second FTP server supporting FTPS. To simplify, I
> copied the FTPD proc and renamed it FTPSD.  In theory, it is running
> exactly
> as the original FTPD task with a different port. (990)
> 4. The PROFILE update reads like this -
> AUTOLOG
>FTPSD JOBNAME FTPSD  ; FTPS SERVER
> ENDAUTOLOG
> PORT
>989 TCP OMVS; FTPS SERVER
>990 TCP FTPSD NOAUTOLOG ; FTPS SERVER
>
> Here is the output of running the started task - (system specifics changed
> for security reasons)
>  08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.SEZATCP
>  08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.XXLOAD
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER
> FTPSD   , GROUP 
>  08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
>  08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
>  08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
> //FTPSDJOB MSGCLASS=T, *
> // MSGLEVEL=1
> //STARTING EXEC FTPSD
> 1 //FTPSDJOB MSGCLASS=T,
> *
>   // MSGLEVEL=1
> 2 //STARTING EXEC FTPSD
> 3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
> 4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
>   XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
>   IEFC653I SUBSTITUTION JCL -
> PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
> 5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
> 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
> 7 XXCEEDUMP  DD SYSOUT=*
> 8 XXSYSOUT   DD SYSOUT=*
> 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
>10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
>  STMT NO. MESSAGE
> 2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY
> SYSX.PROCLIB
> IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   ,
> GROUP USSGRPX
> IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
> Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
> IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
> IEF373I STEP/FTPD/START 2020209.0826
> IEF032I STEP/FTPD/STOP  2020209.0826
> CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00
> SEC
> VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
> ATB- REAL:12K  SLOTS: 0K
>  

Re: z/VM guest with old z/OS

[Joe Monk]

Brian,

You said:

"> I don't know about z/VM 5.3, but running z/OS 1.10 under z/VM on a
> z13 and z14 works (and probably also on a z15), so it's likely that
> it will work on a z12."

Jim said:

"Prior to z/OS 1.12, z/OS IPL uses Dynamic Address Translation while
still in ESA/390 mode.  z14  and later machines do not do ESA/390 DAT.  So
the
oldest z/OS that could possibly IPL on a z14 or later machine would be z/OS
1.12.
Running under z/VM would make no difference in this regard."

There's nothing to differ about Brian. You said that running z/OS 1.10
under z/VM on z13 and z14 works, and Jim said thats physically impossible
because the hardware doesnt support it, since it doesnt do ESA/390 DAT.

Joe

On Fri, Jul 31, 2020 at 11:24 PM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> Jim,
>
> I beg to differ, he wants to run things on the z12 (I assume either an
> ec12 or bc12).  z/OS lifecycle extensions for 1.10 on the z12 (which was
> offered at the z12 announcement and updated several times afterwards)
> certainly isn't going to alter the z12 hardware in any way, and I doubt
> that the ptfs installed to 1.10 for lifecycle are going to change DAT in
> any significant way, but maybe they do.  In any case, they were (and still
> are I think) available, if you can do it with the extensions then you can
> do it with z/VM as well.
>
> (this is from the 2013 IBM presentation slide #6)
> • zEC12 and zBC12 capabilities differ depending on z/OS release
> – Toleration support provided on z/OS V1.10 and z/OS V1.11
> • The Lifecycle Extension for z/OS V1.10 or z/OS V1.11 is required to
> acquire toleration PTFs and for support
> – Exploitation support provided on z/OS V1.12 and higher
> • z/OS V1.12
> – Exploitation of selected functions
> • z/OS V1.13
> – Exploitation of most functions
> • z/OS V2.1
> – Full exploitation in base
>
> also (from the  technical introduction)
>
> Operating systems Use of some features might require the latest releases.
> The following operating systems are supported by the zEC12 and zBC12:
>  z/OS Version 2 Release 1
>  z/OS Version 1 Release 13 with PTFs
>  z/OS Version 1 Release 12 with PTFs
>  z/OS Version 1 Release 11 with the IBM Lifecycle Extension with PTFs
>  z/OS Version 1 Release 10 with the IBM Lifecycle Extension with PTFs
>  z/VM Version 6 Release 3 with PTFs
>  z/VM Version 6 Release 2 with PTFs
>  z/VM Version 5 Release 4 with PTFs
>  z/VSE Version 4 Release 3 or later, with PTFs
>
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/VM guest with old z/OS

[Joe Monk]

Jim,

So has ESA/390 been eliminated from z/Architecture?

Joe

On Sun, Aug 2, 2020 at 11:16 PM Jim Mulder  wrote:

>   There is no "might" about it.  As shipped by IBM, nothing lower than
> z/OS 1.12 will run  on a z14 or z15.  I don't know who you think "might"
> know more about this particular topic than I do.  I implemented the
> code in z/OS 1.12 which allows it to IPL on a z14.  I also know which
> z/OS 1.12 modules can be copied to z/OS 1.6 through z/OS 1.11 to
> allow them to IPL under VM on a z14, but that is for IBM internal use
> only in case we ever need to test some fix on an old release in
> our lab, since we moved our  lab VM systems to z14 and z15.
>
>  Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
> "IBM Mainframe Discussion List"  wrote on
> 08/02/2020 03:46:54 AM:
>
> > From: "Brian Westerman" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 08/02/2020 11:51 PM
> > Subject: Re: z/VM guest with old z/OS
> > Sent by: "IBM Mainframe Discussion List" 
> >
> > Oops, I may be wrong, I really should read what people have written
> > completely.  The z/OS 1.8 system does work on the z13s at the DR
> > site (which is running z/VM, we have not tried it native), but you
> > are correct that it "might" not run on a z14 or z15.  It might, but
> > I have no way to test it.  I had assumed that since you can upgrade
> > a z13 to a z14 in the same frame that they would be pretty similar,
> > but maybe I'm wrong.
> >
> > Anyway the OP should have no problems running z/OS 1.10 on their new
> > z12, assuming he gets the toleration PTFs, and assuming he is up to
> > the most "current" z/OS 1.10 maintenance it likely would run without
> > them as well, just some parts might not work completely.  The
> > extensions are not overly expensive. (even from my very cheap point of
> view).
> >
> > Brian
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/VM guest with old z/OS

[Joe Monk]

So what level of z/vm are you upgrading to?

Joe

On Mon, Aug 3, 2020 at 10:11 AM CarlosM Martinez 
wrote:

> I am  on a 2818 M02 (Z114) running Z/VM 5.4.0. service level 0902 (64
> bit)  with Z/OS 01.13 moving over to a Z/15 soon,
>
> Carlos Martinez
> SUNY Downstate
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Monday, August 03, 2020 10:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/VM guest with old z/OS
>
> W dniu 02.08.2020 o 09:46, Brian Westerman pisze:
> > Oops, I may be wrong, I really should read what people have written
> completely.  The z/OS 1.8 system does work on the z13s at the DR site
> (which is running z/VM, we have not tried it native), but you are correct
> that it "might" not run on a z14 or z15.  It might, but I have no way to
> test it.  I had assumed that since you can upgrade a z13 to a z14 in the
> same frame that they would be pretty similar, but maybe I'm wrong.
> >
> > Anyway the OP should have no problems running z/OS 1.10 on their new
> z12, assuming he gets the toleration PTFs, and assuming he is up to the
> most "current" z/OS 1.10 maintenance it likely would run without them as
> well, just some parts might not work completely.  The extensions are not
> overly expensive. (even from my very cheap point of view).
>
> To clarify:
> z/OS 1.10 and older will NOT work on z14 and next machines. Dot.
> z/VM will not help.
> It was mentioned by IBM many times.
>
> Note: we talk about work/not work, not about what is supported/not
> supported.
>
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: OT: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

"Federal limits, state limits... This is something I don't understand."

It is a concept called federalism. The state has certain powers, and the
federal government has certain powers.

Joe









On Wed, Aug 5, 2020 at 7:16 AM R.S.  wrote:

> Federal limits, state limits... This is something I don't understand.
> Standarization is good thing and common rules are easier to follow.
> I just checked - 85mph in Texas, even for trucks. And 55mph in District
> of Columbia (not to mention Guam). From the other hand Residential Areas
> limits vary from 15 to 55mph.
> Howeve it is matter of simple table with different values for each row
> (state), because the columns (rules) vary also. That lead to confusion.
> It's even more complex than baseball and non-SI measures! ;-)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 05.08.2020 o 08:34, Bob Bridges pisze:
> > Technically the 55mph limit wasn't a federal law; Rex is right that
> speed limits are set and enforced by each state.  But in the '70s Congress
> (the Federal Congress) passed a law that Federal highway money would not be
> forthcoming to states that allowed their speed limits to exceed 55mph.
> Most states went along.  The 55mph speed limit is long gone now;
> interstates I drive on east of the Mississippi river are mostly 65 and 70,
> except through dicey parts of cities where it can go as low as 55 or even
> 45.  I saw a piece of I-10 in AZ that was 75, or maybe 80, but that's all
> I've seen myself.
> >
> > I remember my driver's-ed teacher in high school telling us that in some
> western states the statutory speed limit used to be 120, and even that was
> enforced spottily.
> >
> > Before the 55 limit, in 1972 and at the mature age of 17, I hitchhiked
> across the country.  (NC to CA; for Europeans, it's about 4100 km.)  A guy
> who picked me up in Texas had just had a new engine put into his car, and
> he  didn't want to go too fast until he'd broken in the engine a bit.  But
> the roads in Texas are straight and flat; he kept creeping up over 100mph
> without realizing it.  Then we'd hit a very slight curve, the car would
> make a slight noise as it pulled against friction toward the outside of the
> road, he'd glance down at the speedometer and slow down again.  All very
> interesting to a boy who'd never gone that fast before.  But of course in
> such flat land it didn't really seem that fast.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* Wink at small faults; remember thou hast great ones.  -Poor Richard */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tony Thigpen
> > Sent: Tuesday, August 4, 2020 09:09
> >
> > The 55 MPH limit was a federal law designed to force people to save fuel
> > by driving slower during the 70's when the fuel crisis hit the US. And,
> > we were stuck with for a long time even after the fuel crisis was over.
> > Some studies showed that while it saved fuel for autos, it cost fuel for
> > long-haul trucking.
> >
> > Just like the 18% interest rates of the 70's, we hope to never see a
> > national 55MPH speed limit again.
> >
> > --- Pommier, Rex wrote on 8/4/20 9:01 AM:
> >> Speed limits are different in the States based on which state you're
> in.  Each state can set its own speed limit.  I am in South Dakota, and
> most smaller 2 lane roads are 55 MPH.  Many of the state 2 lane roads are
> 65, and the interstates have an 80 MPH speed limit, the equivalent of about
> 130 KPH.  So the divided highways - at least in South Dakota - are
> reasonable.
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf Of R.S.
> >> Sent: Tuesday, August 4, 2020 7:23 AM
> >>
> >> My opinion: I like american cars and roads.
> >> However I don't understand common speed limit 55 mph which is in my
> opinion too low for the road on desert.
> >>
> >> BTW:
> >> Here in Poland default limit on highway is 140 km/h.
> >> However in Germany default is ...your sanity. No speed limit. Most cars
> have factory limit at 250 km/h, but not luxury ones. And yes, it is legal
> to drive 300 km/h Of course this is for highways only. And speed limit
> signs may reduce it.
> >
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS

Re: Edit Macro

[Joe Monk]

Well...

The first thing youve got to do is fix your edit macro. When you run an
edit macro in batch, it has to end with "ISREDIT END".

So, you might have two different versions, one for batch and one for online.

Second, when you run ISREDIT in batch, you have to use a macro to supply
the input. So, you'll probably need to rethink how youre invoking ISREDIT
in batch.

Joe



On Thu, Aug 6, 2020 at 5:40 PM Steely.Mark 
wrote:

> Send again hope it keeps the formatting.
>
> I have this edit macro EICUPDT:
>
> * Top of Data 
> ISREDIT MACRO (NUM1)
> ISREDIT COPY EICLIST 20 20 BEFORE 1
> ISREDIT COPY EICLIST &NUM1 &NUM1 BEFORE 1
> EXIT: +
> EXIT CODE(0)
>  Bottom of Data **
>
> When I am in a edit member session and I enter this command "EICUPDT 3"
> from the command line the Macro works as expected. All this does is copy 2
> lines from EICLIST. It always copies line 20 but I supply a number for the
> other line to copy.
>
> I am trying to execute this in batch. I have done this in the past but I
> never needed to pass a parm.
>
> //TSOBTCH1  EXEC PGM=IKJEFT01
> //SYSTSPRT  DD SYSOUT=*
> ...
> //SYSTSIN   DD *
> PROFILE PREFIX(xx)
> ISPSTART CMD(%EDITREX1 XXX0111.DATA(DATAXX) - EICUPDT PARM(1))
> /*
> //*
>
> Here is EDITREX1:
> * Top of Data *
> /* REXX */
> TRACE IR
> /* -- */
> /* All REXX reserved words are shown in CAPS and all user */
> /* defined variables are shown in 'lower case'.   */
> /* -- */
> PARSE ARG filename macro1 macro2
> ADDRESS ISPEXEC "EDIT DATASET('"filename"') MACRO("macro1") "macro2
>  Bottom of Data ***
>
> I added macro2 to accept the parm value.
>
> This is the results:
>
>>O>   "EDIT DATASET('XXX0111.DATA(DATAXX)') MACRO(EICUPDT)
> PARM(1)" <---This is the last line that the trace produced
>   ISRP124 Macro parameter error   -/-The parameter specified by PARM
> keyword of the EDIT service could not be resolved.
> READY
>
> I have tried several different ways. Too many to show here.
>
> Any help would be appreciated.
>
> Thank You
> *** Disclaimer ***
> This communication (including all attachments) is solely for the use of
> the person to whom it is addressed and is a confidential AAA communication.
> If you are not the intended recipient, any use, distribution, printing, or
> copying is prohibited. If you received this email in error, please
> immediately delete it and notify the sender.
>
> --
> 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: Edit Macro

[Joe Monk]

It is a  REQUIREMENT that when you run ISREDIT in BATCH, the INPUT TO
ISREDIT MUST BE SUPPLIED BY A MACRO.

So, when your REXX exec launches ISREDIT, it must supply all of the input
to ISREDIT VIA A MACRO.

Joe

On Thu, Aug 6, 2020 at 6:18 PM Steely.Mark 
wrote:

> Thanks for the ISREDIT END suggestion.
>
> I did add that - but the process is not executing the macro.
>
> So that is not the problem.
>
> Thanks
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Joe Monk
> Sent: Thursday, August 06, 2020 5:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Edit Macro
>
> ATTENTION: This e-mail came from an external source. Do not open
> attachments or click on links from unknown or unexpected emails.
>
>
> Well...
>
> The first thing youve got to do is fix your edit macro. When you run an
> edit macro in batch, it has to end with "ISREDIT END".
>
> So, you might have two different versions, one for batch and one for
> online.
>
> Second, when you run ISREDIT in batch, you have to use a macro to supply
> the input. So, you'll probably need to rethink how youre invoking ISREDIT
> in batch.
>
> Joe
>
>
>
> On Thu, Aug 6, 2020 at 5:40 PM Steely.Mark 
> wrote:
>
> > Send again hope it keeps the formatting.
> >
> > I have this edit macro EICUPDT:
> >
> > * Top of Data  ISREDIT MACRO
> > (NUM1) ISREDIT COPY EICLIST 20 20 BEFORE 1 ISREDIT COPY EICLIST &NUM1
> > &NUM1 BEFORE 1
> > EXIT: +
> > EXIT CODE(0)
> >  Bottom of Data **
> >
> > When I am in a edit member session and I enter this command "EICUPDT 3"
> > from the command line the Macro works as expected. All this does is
> > copy 2 lines from EICLIST. It always copies line 20 but I supply a
> > number for the other line to copy.
> >
> > I am trying to execute this in batch. I have done this in the past but
> > I never needed to pass a parm.
> >
> > //TSOBTCH1  EXEC PGM=IKJEFT01
> > //SYSTSPRT  DD SYSOUT=*
> > ...
> > //SYSTSIN   DD *
> > PROFILE PREFIX(xx)
> > ISPSTART CMD(%EDITREX1 XXX0111.DATA(DATAXX) - EICUPDT PARM(1))
> > /*
> > //*
> >
> > Here is EDITREX1:
> > * Top of Data
> > *
> > /* REXX */
> > TRACE IR
> > /* --
> > */
> > /* All REXX reserved words are shown in CAPS and all user */
> > /* defined variables are shown in 'lower case'.   */
> > /* --
> > */ PARSE ARG filename macro1 macro2 ADDRESS ISPEXEC "EDIT
> > DATASET('"filename"') MACRO("macro1") "macro2
> >  Bottom of Data
> > ***
> >
> > I added macro2 to accept the parm value.
> >
> > This is the results:
> >
> >>O>   "EDIT DATASET('XXX0111.DATA(DATAXX)') MACRO(EICUPDT)
> > PARM(1)" <---This is the last line that the trace produced
> >   ISRP124 Macro parameter error   -/-The parameter specified by PARM
> > keyword of the EDIT service could not be resolved.
> > READY
> >
> > I have tried several different ways. Too many to show here.
> >
> > Any help would be appreciated.
> >
> > Thank You
> > *** Disclaimer ***
> > This communication (including all attachments) is solely for the use
> > of the person to whom it is addressed and is a confidential AAA
> communication.
> > If you are not the intended recipient, any use, distribution,
> > printing, or copying is prohibited. If you received this email in
> > error, please immediately delete it and notify the sender.
> >
> > --
> > 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
>
> *** Disclaimer ***
> This communication (including all attachments) is solely for the use of
> the person to whom it is addressed and is a confidential AAA communication.
> If you are not the intended recipient, any use, distribution, printing, or
> copying is prohibited. If you received this email in error, please
> immediately delete it and notify the sender.
>
> --
> 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: Edit Macro

[Joe Monk]

So, you would do it like this:

ISPEXEC EDIT DSN(BLAHBLAH) MACRO(START)

In START:

ISREDIT MACRO
ISREDIT EICUPDT 5
ISREDIT END

The initial macro has to call the EICUPDT macro.

Joe

On Thu, Aug 6, 2020 at 6:48 PM Joe Monk  wrote:

> It is a  REQUIREMENT that when you run ISREDIT in BATCH, the INPUT TO
> ISREDIT MUST BE SUPPLIED BY A MACRO.
>
> So, when your REXX exec launches ISREDIT, it must supply all of the input
> to ISREDIT VIA A MACRO.
>
> Joe
>
> On Thu, Aug 6, 2020 at 6:18 PM Steely.Mark 
> wrote:
>
>> Thanks for the ISREDIT END suggestion.
>>
>> I did add that - but the process is not executing the macro.
>>
>> So that is not the problem.
>>
>> Thanks
>>
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of Joe Monk
>> Sent: Thursday, August 06, 2020 5:57 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Edit Macro
>>
>> ATTENTION: This e-mail came from an external source. Do not open
>> attachments or click on links from unknown or unexpected emails.
>>
>>
>> Well...
>>
>> The first thing youve got to do is fix your edit macro. When you run an
>> edit macro in batch, it has to end with "ISREDIT END".
>>
>> So, you might have two different versions, one for batch and one for
>> online.
>>
>> Second, when you run ISREDIT in batch, you have to use a macro to supply
>> the input. So, you'll probably need to rethink how youre invoking ISREDIT
>> in batch.
>>
>> Joe
>>
>>
>>
>> On Thu, Aug 6, 2020 at 5:40 PM Steely.Mark 
>> wrote:
>>
>> > Send again hope it keeps the formatting.
>> >
>> > I have this edit macro EICUPDT:
>> >
>> > * Top of Data  ISREDIT MACRO
>> > (NUM1) ISREDIT COPY EICLIST 20 20 BEFORE 1 ISREDIT COPY EICLIST &NUM1
>> > &NUM1 BEFORE 1
>> > EXIT: +
>> > EXIT CODE(0)
>> >  Bottom of Data **
>> >
>> > When I am in a edit member session and I enter this command "EICUPDT 3"
>> > from the command line the Macro works as expected. All this does is
>> > copy 2 lines from EICLIST. It always copies line 20 but I supply a
>> > number for the other line to copy.
>> >
>> > I am trying to execute this in batch. I have done this in the past but
>> > I never needed to pass a parm.
>> >
>> > //TSOBTCH1  EXEC PGM=IKJEFT01
>> > //SYSTSPRT  DD SYSOUT=*
>> > ...
>> > //SYSTSIN   DD *
>> > PROFILE PREFIX(xx)
>> > ISPSTART CMD(%EDITREX1 XXX0111.DATA(DATAXX) - EICUPDT PARM(1))
>> > /*
>> > //*
>> >
>> > Here is EDITREX1:
>> > * Top of Data
>> > *
>> > /* REXX */
>> > TRACE IR
>> > /* --
>> > */
>> > /* All REXX reserved words are shown in CAPS and all user */
>> > /* defined variables are shown in 'lower case'.   */
>> > /* --
>> > */ PARSE ARG filename macro1 macro2 ADDRESS ISPEXEC "EDIT
>> > DATASET('"filename"') MACRO("macro1") "macro2
>> >  Bottom of Data
>> > ***
>> >
>> > I added macro2 to accept the parm value.
>> >
>> > This is the results:
>> >
>> >>O>   "EDIT DATASET('XXX0111.DATA(DATAXX)') MACRO(EICUPDT)
>> > PARM(1)" <---This is the last line that the trace produced
>> >   ISRP124 Macro parameter error   -/-The parameter specified by PARM
>> > keyword of the EDIT service could not be resolved.
>> > READY
>> >
>> > I have tried several different ways. Too many to show here.
>> >
>> > Any help would be appreciated.
>> >
>> > Thank You
>> > *** Disclaimer ***
>> > This communication (including all attachments) is solely for the use
>> > of the person to whom it is addressed and is a confidential AAA
>> communication.
>> > If you are not the intended recipient, any use, distribution,
>> > printing, or copying is prohibited. If you received this email in
>> > error, please immediately delete it and notify the sender.
>> >
>> > ---

Re: OT: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

Not a good idea to be hurling insults from a work account.

Joe

On Fri, Aug 7, 2020 at 4:25 AM R.S.  wrote:

> BBC
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 07.08.2020 o 03:28, Seymour J Metz pisze:
> > PKB
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of R.S. 
> > Sent: Thursday, August 6, 2020 5:25 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: OT: OOBOL and English was Re: Still COBOL After All These
> Years?
> >
> > W dniu 05.08.2020 o 17:07, Seymour J Metz pisze:
> >> Must you be so obtuse? The structure that they devised is extremely
> hard to change. Look at how long it took for everyone to switch from the
> Julian Calendar to the Gregorian calendar.
> >>
> >> Yes, Europe has had treaties, and before the ones that you mentioned at
> that, but some things are easier to change than others. Let me know when,
> e.g., Europe gets rid of its royalty (yes, I know that they're mostly
> symbolic.)
> > Must you be so boorish?
> > Must you insult people?
> > Don't you have better hobby? This is not the place for your rudeness,
> > better would be psychiatric office.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> 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, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: Multiprise 3000

[Joe Monk]

Did you look on ebay?

Joe

On Sat, Aug 8, 2020 at 6:10 AM W Mainframe <
01304632a58d-dmarc-requ...@listserv.ua.edu> wrote:

> Guys,Any suggestion about a small storage unit for a Multiprise 3000
> (7060-P30)? I am just looking for internal ssa disks... But seems they are
> hidden... :)
> ThanksDan
>
>
> Sent from Yahoo Mail for iPhone
>
> --
> 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: EC6 ABEND with X'00FFCE54' in R15

[Joe Monk]

Umm... dont you maintain a table of your pthreads? Like storing off their
ids somewhere?

If not maybe you should? Then you can have a routine in your exit that
kills off the pthreads from the table using their id
before you exit...

Joe

On Sun, Aug 9, 2020 at 6:14 AM Thomas David Rivers 
wrote:

> Thanks all!   Turns out I was confused by the EC6 doc;
> thinking the reason-code should be in R15.
>
> But - it's not - it's clearly where it needs to be... I'm
> getting an EC6 ABEND with a REASON code of 
> which means that the BPX _exit() was invoked with
> subtasks (in this case, pthread subtasks.)
>
> Although - I _thought_ all the pthreads had been either
> joined or detached.   I didn't think a pthread TASK would
> "stay around" (these are all HEAVY-weighted pthreads.)
>
> Is there some call that says "hey - end all the extent tasks
> waiting on pthreads".   (I don't have a pthread_t thread-id
> because they have all "gone away" so I can't pthread_join
> the thread or anything...)
>
> Or - do we just "live with" this EC6 ABEND in this case?
>
>- Dave Rivers -
>
> p.s To Peter - yeah - I should have said ESTAE... sorry for the inaccuracy.
>
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
>
> --
> 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: EC6 ABEND with X'00FFCE54' in R15

[Joe Monk]

"I wonder what's so special about TSO?"

TSO in batch or TSO Interactive?

But either way, doesnt TSO normally spin off subtasks with an
ATTACH/ATTACHX?

Joe

On Sun, Aug 9, 2020 at 11:01 AM Thomas David Rivers 
wrote:

> Joe Monk wrote:
>
> >Umm... dont you maintain a table of your pthreads? Like storing off their
> >ids somewhere?
> >
> >If not maybe you should? Then you can have a routine in your exit that
> >kills off the pthreads from the table using their id
> >before you exit...
> >
> >Joe
> >
> >O
> >
> Yeah - but how do you kill a pthread?  You can send it a signal
> or a cancel, but if it's not in a "good place" it won't act on those...
> and you have no way of knowing if it's dead-or-alive.
>
> And - there is another chicken-and-egg problem - what if one of
> the pthreads is the one invoking BPX _exit()?   What kills the
> other pthreads?
>
> This 'feels like' it's better handled as an OS function... not an
> application one.
> And, I think, in any environment except TSO it is done that way, I wonder
> what's so special about TSO?
>
>
>- Dave
>
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
>
> --
> 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