Re: COBOL "problem" (not really), but sort of.

[Timothy Sipples]

John McKown writes:
>But COBOL doesn't have the DWIW (Do What I Want) verb.

We're working on it. :-)

Just be patient and keep smiling, John. You'll get there. Perhaps (as
another idea) there's already a bit of working, tested, efficient code in
house that implements substantially the same function the programmer is
trying to achieve?


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
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

Re: PDS/E, Shared Dasd, and COBOL V5

[Timothy Sipples]

I cracked open a (metaphorical) history book, and I discovered that IBM
introduced PDSEs in 1989 -- about 24 years ago as I write this.

I agree with John Gilmore. A 2013 PDSE prerequisite for Enterprise COBOL
5.1 is not too soon.

I should point out that IBM announced no charge 90-day trials of CICS
Transaction Server 5.1 and Enterprise COBOL 5.1. You can try these products
for 90 days without worrying about single version charge (SVC) periods. You
can confirm how much more efficiently your CPU-intensive COBOL applications
run after recompiling, for example. You can also get acquainted with PDSEs
and their impacts. (Did I actually just write that? :-))

By the way, I *frequently* encounter customers that don't submit SCRT
reports with Enterprise COBOL correctly associated only with the LPARs
where they run it. IBM receives SCRT reports where Enterprise COBOL is
assumed to be running in every z/OS LPAR, and then IBM bills accordingly.
(Thanks for that.) But Enterprise COBOL 5.1 now generates its very own Type
89 SMF records so you don't have to be aware of "NO89" (many aren't) and
don't have to worry about it. Hurray for that too.

Give the products a spin and kick the tires, at no additional charge.
You'll probably like them very much. Unless perhaps you're the person John
Gilmore is describing. :-)


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
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

Re: Recursive SSI abend - Was: SSI update

[Jon Perryman]

No apology needed. 

The problem is with the subsystem you added. You will need to capture the abend 
information and analyze it. Look at logrec to see if a record was generated for 
it. If not, then you probably need to capture a dump. Or maybe the abend 
messages that you are looking at would help. Since the SSI is called regularly, 
this probably is not be a recursive abend.

Jon Perryman.

>
> From: mf db 
>
>Apology for the confusion, Recently in one of my test system I added a
>subsystem to SSI and i have started experiencing recursive abends. After
>adding I started seeing some of the STC which were started taking more Real
>storage(Which Usually doesn't take much during normal).


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

Re: PDS/E, Shared Dasd, and COBOL V5

[Mark Zelden]

On Wed, 11 Sep 2013 21:48:32 +, Gibney, Dave  wrote:

>Very simple set-up. No ring at all. Independent monplexes. NO serialization. 

So in what way do you disagree with my earlier post?  I wrote you can share
PDSE using NORMAL sharing without a sysplex as long as you have a GRSplex.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS/E, Shared Dasd, and COBOL V5

[nitz-...@gmx.net]

> I had begun to think that my experience with PDSEs was somehow
> atypical, too lucky, because I had not encountered the grievous
> problems that featured in others' war stories.
> 
> I therefore spent a long afternoon trying to reproduce and clear some
> of these problems.  My experience was much like Mark's.  The problems
> reported here did---some of them anyway---occur; but they were readily
> cleared away.

Use a (batch) TSO address space with a truly multitasking application. Have 
that application call an authorized command or program (iebcopy will suffice) 
on at least two processors/tcbs at the same time. Wait for the deadlock inside 
that address space on a PDSE latch that EVERY PDSE access in the system needs. 
Then try to clean up the resulting mess. No sysplex involved, single system 
only.

Barbara

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

Re: PDS/E, Shared Dasd, and COBOL V5

[nitz-...@gmx.net]

> >Thanks!  BTW, with "huge", are we talking about >> 1 members ? 
> 
> Generally,  yes - because of the way things are split between different major
> applications. I looked and saw one loadlib with about 20,000 members,
> but most are under 5K.  

Are we also talking about PDSEs with LRECL=V in some flavour? 

Barbara

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

Re: SSI update

[mf db]

Hello Sir,

Apology for the confusion, Recently in one of my test system I added a
subsystem to SSI and i have started experiencing recursive abends. After
adding I started seeing some of the STC which were started taking more Real
storage(Which Usually doesn't take much during normal).


On Wed, Sep 11, 2013 at 8:34 PM, Jon Perryman  wrote:

> I'm also confused by your question. What makes you ask this question? What
> did you read or hear about that made you ask this question? Are you talking
> about the "subsystem interface" or is SSI in reference to something else?
>
> Any time a program moves information to storage, it is overlaying storage.
> It's only a bad thing when it overlays the wrong storage. We use the term
> "storage overlay" to mean overlaying the wrong storage. Assembler macro
> IEFSSI and MVS command SETSSI add/update the SSCT which overlays
> information in an SSCT or the SSCT chain. If your program overlays the
> wrong storage, then it can cause abends.
>
> Great care must be taken in programs that run from the SSI. The SSI runs
> all the time and in all address spaces. If something bad happens, you could
> be IPL'ing your system.
>
> Jon Perryman..
>
>
>
>
> >
> > From: mf db 
>
> >Yes, My question can it cause any abend by overlaying storage ?
> >
> >On Wed, Sep 11, 2013 at 2:43 PM, Lizette Koehler  >wrote:
> >> Are you asking can it cause an abend by overlaying storage?
> >>
> >> -Original Message-
> >>From: mf db 
> >>
> >> I am trying to understand if Dynamic SSI update can overlay the storage.
> >> Could someone please shed some light on dynamic SSI update.
>
> --
> 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: IEE313I when varying a console online

[גדי בן אבי]

Hi Bill,

I haven't seen any mention of a /con parameter in the documentation I have.

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Bishop (TEMA TPC)
Sent: Wednesday, September 11, 2013 9:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Do you have the /con entry in the parameters section of the 2074 definitions 
for the terminal being used as a console?

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development & Support
Toyota Motor Engineering & Manufacturing North America, Inc.
bill.bis...@tema.toyota.com
(502) 570-6143

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Wednesday, September 11, 2013 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Hi

The answer is yes to both questions.
I can very it online, but I cannot vary console.
The output from D U is O or OFFLINE.
Is is defined in the consolexx member.

Gadi



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
John McKown [john.archie.mck...@gmail.com]
Sent: 11 September 2013 18:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Is the address specified exist in the I/O configuration? D U,,,,1 gives 
back valid information. If so, what is it's status? It needs to be OFFLINE 
before it can be varied as a CONSOLE. And it needs to be specified in the 
CONSOLxx member which was specified at IPL time.


On Wed, Sep 11, 2013 at 10:35 AM, גדי בן אבי  wrote:

> Hi,
>
> I am in the process of installing a 2074 for a client. I know it's
> ancient, and unsupported, but everything this client has is ancient
> and unsupported.
>
> I managed to get a working console session on the 2074.
> When I try to configure PCOM, I get the 2074 index message.
>
> When I try to vary the device (V xxx,console) i get:
> IEE313I UNIT REF. INVALID.
>
> What can the reason for this be?
> How do I fix it.
>
> The machine is a 2074 model 3
> The computer is a 9672-R14
> OS is OS/390 v2.8.
>
> Thanks
>
>
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או
> מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה,
> הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך
> כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no
> offer, agreement, concession or representation is binding on the
> company, unless accompanied by a duly signed separate document (or a
> scanned version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the company's seal.

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed 

Re: Wait all CPU's enabled at least once

[Jim Mulder]

> Is there an instruction that waits for all CPU's to be enabled at least 
once?

  No. Bind Break does a SIGP EMS (via the RISGNL macro) to every 
processor,
and RISGNL spins until the target processor accepts and processes the 
EMS external interrupt, and it has to be enabled to accept the interrupt. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


> > CPU Offline processing turns off the CSD alive bit, and zeros the 
> > PCCAVT and LCCAVT entries for the CPU that is going offline.  Then 
> > a Bind Break is done, and this does not complete until every other
> > CPU has enabled at least once.  After that, the LCCA, PCCA, and PSA
> > can be freed.  So if you disable, and then fetch a non-zero address
> > for a PCCA from the PCCAVT or LCCA from the LCCAVT, the PCCA, LCCA, 
> > and associated PSA will not be freed as long as you remain disabled. 

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

Wait all CPU's enabled at least once

[Jon Perryman]

Is there an instruction that waits for all CPU's to be enabled at least once?

Jon Perryman.


- Original Message -
> From: Jim Mulder 
> 
> CPU Offline processing turns off the CSD alive bit, and zeros the 
> PCCAVT and LCCAVT entries for the CPU that is going offline.  Then 
> a Bind Break is done, and this does not complete until every other
> CPU has enabled at least once.  After that, the LCCA, PCCA, and PSA
> can be freed.  So if you disable, and then fetch a non-zero address
> for a PCCA from the PCCAVT or LCCA from the LCCAVT, the PCCA, LCCA, 
> and associated PSA will not be freed as long as you remain disabled. 


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

Re: COBOL "problem" (not really), but sort of.

[John McKown]

Doesn't surprise me. We get blank and zero overlays all the time. What I
really needed, and have, is a good way to explain what is happening and how
he is misunderstanding what is needed in COBOL, according to the manual. I
am not a COBOL programmer. And I explain things is assembler ways, which
sometimes confuse them. And they often want me to make COBOL work the way
that they think that it should or explain why it doesn't. I don't think
that way. So I get "short" with them. I'm not good with children, either.
On Sep 11, 2013 7:00 PM, "Hardee, Chuck" 
wrote:

> You do realize that +1077952576 is the same as x'40404040' which is the
> value of the FILLER field in the first 01.
> This may be an alignment issue in addition to expecting to get something
> for nothing from COBOL.
>
>
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> CCG Information Technology
> Thermo Fisher Scientific
> 300 Industry Drive
> Pittsburgh, PA 15275
> Direct: 724-517-2633
> FAX: 412-490-9230
> chuck.har...@thermofisher.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 11, 2013 5:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL "problem" (not really), but sort of.
>
> I have now studied the program source. Let's just drop this discussion
> because the program is junk.
>
> FD  XDF-FILE.
>
> 01 XDF-RECORD
>  02 XDF-REC-LNG S9(5)COMP  +400
>  02 FILLER  X(04)  SPACES
>  02 XDF-KEY X(16) MP05356899M00
> 01 XDF-RECORDV
>  02 XDF-DATAOCCURS 00 TO 12040
> DEPENDING ON XDF-REC-LNG.
>
>
> WORKING-STORAGE SECTION.
> 01 WSV-WORK-VARIABLES
>  02 WSV-X1 9(2).
>  02 WSV-REC-LNG S9(5)COMP.
>
> LINKAGE-SECTION.
> 01 MSSXDFIO-LINKAGE
>  02 MSSXDFIO-FILE   X(01)  A
>   88 MSSXDFIO-FILE-ACTV   'A'
>   88 MSSXDFIO-FILE-ARCH   'R'
>  02 MSSXDFIO-RC X(02)  00
> 01 LINK-RECORD
>  02 LINK-REC-LNGS9(5)COMP  +400
>  02 FILLER  X(04)  SPACES
>  02 LINK-KEYX(16) MP05356899M00
>  02 LINK-DATAX
>   03 LINK-DATA  OCCURS 00 TO 13000
> DEPENDING ON WSV-REC-LNG
>
> PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD.
>
> MOVE LINK-REC-LNG TO WSV-REC-LEN.
> READ FILE INTO LINK-RECORD.
>
> In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What the
> programmer expected was that the READ would read the logical record into
> the FD area (true).  And then MOVE however much was just READ into
> LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at the
> time of the copy. This is just poor coding. And he doesn't want to change
> it to be proper. The values in the FD area are correct after the READ. But
> he doesn't want to do a MOVE after the READ. I don't know why. I don't
> think he really understands how COBOL does things. And he is not a
> youngster.
>
>
> I am now on vacation for 4 days. Thanks to all.
>
>
>
>
>
> On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg  >wrote:
>
> > I thought the length field was in LINKAGE SECTION given by the caller ?
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> >
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of John McKown
> > > Sent: Wednesday, September 11, 2013 10:16 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: COBOL "problem" (not really), but sort of.
> > >
> > > Well explained. I will keep this to show him when this next abends. It
> > > is a problem just waiting for a critical month end to come around.
> > >
> > >
> > > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> > > peter.far...@broadridge.com> wrote:
> > >
> > > > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
> > > > Long
> > > > said:  "Ignorance is curable, only stupidity is fatal."
> > > >
> > > > Second, let's try one more time to penetrate the thick cranial
> > > > boundary in question (not yours):
> > > >
> > > > IF the FILE definition looks like this:
> > > >
> > > > FD  IN-FILE ...  .
> > > > 01  FILE-RECORD.
> > > > 05  FILE-REC-LENPIC S9(5) COMP.
> > > > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> > > > DEPENDING ON FILE-REC-LEN
> > > > PIC X.
> > > >
> > > > And the working-storage area looks like this:
> > > >
> > > > 01  WORK-RECORD.
> > > > 05  WORK-R

Re: Currently dispatched TCB in SRB mode

[Micheal Butz]

This delay offline processing for a nano second or less would that have any 
impact ?

Sent from my iPhone

On Sep 11, 2013, at 8:43 PM, Jim Mulder  wrote:

>>> With disablement, you can guarantee that your processor will not be
>>> interrupted between fetching the address and accessing it
>> 
>> You can not, however, be guarntied that another processor won't change
>> anything. What happens if z/OS is in the middle of taking the other
>> CPU offline?
> 
> CPU Offline processing turns off the CSD alive bit, and zeros the 
> PCCAVT and LCCAVT entries for the CPU that is going offline.  Then 
> a Bind Break is done, and this does not complete until every other
> CPU has enabled at least once.  After that, the LCCA, PCCA, and PSA
> can be freed.  So if you disable, and then fetch a non-zero address
> for a PCCA from the PCCAVT or LCCA from the LCCAVT, the PCCA, LCCA, 
> and associated PSA will not be freed as long as you remain disabled. 
> 
> 
> Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY
> 
> --
> 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: Currently dispatched TCB in SRB mode

[Jim Mulder]

> >With disablement, you can guarantee that your processor will not be
> >interrupted between fetching the address and accessing it 
> 
> You can not, however, be guarntied that another processor won't change
> anything. What happens if z/OS is in the middle of taking the other
> CPU offline?

 CPU Offline processing turns off the CSD alive bit, and zeros the 
PCCAVT and LCCAVT entries for the CPU that is going offline.  Then 
a Bind Break is done, and this does not complete until every other
CPU has enabled at least once.  After that, the LCCA, PCCA, and PSA
can be freed.  So if you disable, and then fetch a non-zero address
for a PCCA from the PCCAVT or LCCA from the LCCAVT, the PCCA, LCCA, 
and associated PSA will not be freed as long as you remain disabled. 


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: COBOL "problem" (not really), but sort of.

[Hardee, Chuck]

You do realize that +1077952576 is the same as x'40404040' which is the value 
of the FILLER field in the first 01.
This may be an alignment issue in addition to expecting to get something for 
nothing from COBOL.



Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
chuck.har...@thermofisher.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, September 11, 2013 5:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL "problem" (not really), but sort of.

I have now studied the program source. Let's just drop this discussion
because the program is junk.

FD  XDF-FILE.

01 XDF-RECORD
 02 XDF-REC-LNG S9(5)COMP  +400
 02 FILLER  X(04)  SPACES
 02 XDF-KEY X(16) MP05356899M00
01 XDF-RECORDV
 02 XDF-DATAOCCURS 00 TO 12040
DEPENDING ON XDF-REC-LNG.


WORKING-STORAGE SECTION.
01 WSV-WORK-VARIABLES
 02 WSV-X1 9(2).
 02 WSV-REC-LNG S9(5)COMP.

LINKAGE-SECTION.
01 MSSXDFIO-LINKAGE
 02 MSSXDFIO-FILE   X(01)  A
  88 MSSXDFIO-FILE-ACTV   'A'
  88 MSSXDFIO-FILE-ARCH   'R'
 02 MSSXDFIO-RC X(02)  00
01 LINK-RECORD
 02 LINK-REC-LNGS9(5)COMP  +400
 02 FILLER  X(04)  SPACES
 02 LINK-KEYX(16) MP05356899M00
 02 LINK-DATAX
  03 LINK-DATA  OCCURS 00 TO 13000
DEPENDING ON WSV-REC-LNG

PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD.

MOVE LINK-REC-LNG TO WSV-REC-LEN.
READ FILE INTO LINK-RECORD.

In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What the
programmer expected was that the READ would read the logical record into
the FD area (true).  And then MOVE however much was just READ into
LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at the
time of the copy. This is just poor coding. And he doesn't want to change
it to be proper. The values in the FD area are correct after the READ. But
he doesn't want to do a MOVE after the READ. I don't know why. I don't
think he really understands how COBOL does things. And he is not a
youngster.


I am now on vacation for 4 days. Thanks to all.





On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg wrote:

> I thought the length field was in LINKAGE SECTION given by the caller ?
>
>
>
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
>
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 10:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: COBOL "problem" (not really), but sort of.
> >
> > Well explained. I will keep this to show him when this next abends. It
> > is a problem just waiting for a critical month end to come around.
> >
> >
> > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> > peter.far...@broadridge.com> wrote:
> >
> > > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
> > > Long
> > > said:  "Ignorance is curable, only stupidity is fatal."
> > >
> > > Second, let's try one more time to penetrate the thick cranial
> > > boundary in question (not yours):
> > >
> > > IF the FILE definition looks like this:
> > >
> > > FD  IN-FILE ...  .
> > > 01  FILE-RECORD.
> > > 05  FILE-REC-LENPIC S9(5) COMP.
> > > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> > > DEPENDING ON FILE-REC-LEN
> > > PIC X.
> > >
> > > And the working-storage area looks like this:
> > >
> > > 01  WORK-RECORD.
> > > 05  WORK-REC-LENPIC S9(5) COMP.
> > > 05  WORK-REC-DATA   OCCURS 1 TO 32760
> > > DEPENDING ON FILE-REC-LEN
> > > PIC X.
> > >
> > > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
> > >
> > > READ IN-FILE
> > > AT END (do endfile processing)
> > > NOT AT END
> > > MOVE FILE-REC-LEN TO WORK-REC-LEN.
> > > MOVE FILE-RECORD  TO WORK-RECORD.
> > > END-READ
> > >
> > > The reason that it does not work with READ INTO is that the
> > > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the
> > > working-storage record area.  The MOVE is done at the 01 LEVEL, and in
> > > this case the TO-occurs-depending-on-variable must be set BEFORE the
> > > MOVE begins.  READ does not do that

Re: COBOL "problem" (not really), but sort of.

[John McKown]

Cut and paste, but only a small portion from a CompuWare CWMPMAIN COBOL
listing. Didn't really clean it up properly.
On Sep 11, 2013 5:58 PM, "Frank Swarbrick" 
wrote:

> If you're still up for it...
>
> The program you've posted is not valid COBOL.  Did you retype it?  Or do
> you have some sort of pre-processor that converts it to valid COBOL?  Even
> forgetting that, I don't see how this could possibly ever work.
> XDF-RECORDV is an implicit redefines of XDF-RECORD.  But in LINK-RECORD
> they are concatenated.  So I'm afraid it doesn't look like this is
> "reality".
>
> Frank
>
>
>
>
>
> >
> > From: John McKown 
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Sent: Wednesday, September 11, 2013 3:23 PM
> >Subject: Re: COBOL "problem" (not really), but sort of.
> >
> >
> >I have now studied the program source. Let's just drop this discussion
> >because the program is junk.
> >
> >FD  XDF-FILE.
> >
> >01 XDF-RECORD
> >02 XDF-REC-LNG S9(5)COMP  +400
> >02 FILLER  X(04)  SPACES
> >02 XDF-KEY X(16) MP05356899M00
> >01 XDF-RECORDV
> >02 XDF-DATAOCCURS 00 TO 12040
> >DEPENDING ON XDF-REC-LNG.
> >
> >
> >WORKING-STORAGE SECTION.
> >01 WSV-WORK-VARIABLES
> >02 WSV-X1 9(2).
> >02 WSV-REC-LNG S9(5)COMP.
> >
> >LINKAGE-SECTION.
> >01 MSSXDFIO-LINKAGE
> >02 MSSXDFIO-FILE   X(01)  A
> >  88 MSSXDFIO-FILE-ACTV   'A'
> >  88 MSSXDFIO-FILE-ARCH   'R'
> >02 MSSXDFIO-RC X(02)  00
> >01 LINK-RECORD
> >02 LINK-REC-LNGS9(5)COMP  +400
> >02 FILLER  X(04)  SPACES
> >02 LINK-KEYX(16) MP05356899M00
> >02 LINK-DATAX
> >  03 LINK-DATA  OCCURS 00 TO 13000
> >DEPENDING ON WSV-REC-LNG
> >
> >PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD.
> >
> >MOVE LINK-REC-LNG TO WSV-REC-LEN.
> >READ FILE INTO LINK-RECORD.
> >
> >In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What
> the
> >programmer expected was that the READ would read the logical record into
> >the FD area (true).  And then MOVE however much was just READ into
> >LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at the
> >time of the copy. This is just poor coding. And he doesn't want to change
> >it to be proper. The values in the FD area are correct after the READ. But
> >he doesn't want to do a MOVE after the READ. I don't know why. I don't
> >think he really understands how COBOL does things. And he is not a
> >youngster.
> >
> >
> >I am now on vacation for 4 days. Thanks to all.
> >
> >
> >
> >
> >
> >On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg  >wrote:
> >
> >> I thought the length field was in LINKAGE SECTION given by the caller ?
> >>
> >>
> >>
> >> Best Regards
> >> Thomas Berg
> >> ___
> >> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >>
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> > Behalf Of John McKown
> >> > Sent: Wednesday, September 11, 2013 10:16 PM
> >> > To: IBM-MAIN@LISTSERV.UA.EDU
> >> > Subject: Re: COBOL "problem" (not really), but sort of.
> >> >
> >> > Well explained. I will keep this to show him when this next abends. It
> >> > is a problem just waiting for a critical month end to come around.
> >> >
> >> >
> >> > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> >> > peter.far...@broadridge.com> wrote:
> >> >
> >> > > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
> >> > > Long
> >> > > said:  "Ignorance is curable, only stupidity is fatal."
> >> > >
> >> > > Second, let's try one more time to penetrate the thick cranial
> >> > > boundary in question (not yours):
> >> > >
> >> > > IF the FILE definition looks like this:
> >> > >
> >> > > FD  IN-FILE ...  .
> >> > > 01  FILE-RECORD.
> >> > > 05  FILE-REC-LENPIC S9(5) COMP.
> >> > > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> >> > > DEPENDING ON FILE-REC-LEN
> >> > > PIC X.
> >> > >
> >> > > And the working-storage area looks like this:
> >> > >
> >> > > 01  WORK-RECORD.
> >> > > 05  WORK-REC-LENPIC S9(5) COMP.
> >> > > 05  WORK-REC-DATA   OCCURS 1 TO 32760
> >> > > DEPENDING ON FILE-REC-LEN
> >> > > PIC X.
> >> > >
> >> > > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
> >> > >
> >> > > READ IN-FILE
> >> > > AT END (do endfile processing)
> >> > > NOT AT END
> >> > > MOVE FIL

Re: How to display JES2 fields from the PDDB

[Joe D'Alessandro]

Hello:
You may be better served by using an IF SLIP and writing trace records 
(A=TRACE) to a GTF that specifies TRACE=SLIP so that you can get a greater 
variety of PDDB iterations.   A dump is going to just get you one PDDB  at that 
point in time.

Use $DMOD(modname) to get the address of the exit’s load point.  Use that 
address to build the SLIP.  Here is an example of a SLIP one of my co-workers 
wrote in the past:

SLIP SET,IF,DISABLE,ID=TRCJ,ACTION=TRACE,J=JES2,
 RA=(1A9DE4F8+01F0,1A9DE4F8+0FC6),
 TD=(STD,REGS),
 END

It looks legit to me.  I never did an IF trace for a JES2 exit, but I have used 
IF for other traces and in those cases I  actually coded a module name.   

The RANGE you code would be the address in your exit where you knew the PDDB’s 
address was loaded into reg2.  You might just place the IF on one instruction 
(in the above example, he was tracing code path thru some module).  

And you would add to the TRDATA parameter that the locations pointed to by reg2 
should be written to the trace record, e.g.,  TD=(STD,REGS,2r?+14,2r?+20) 

Which means “dump the standard trace record and the register values and what 
reg2 is pointing to plus x’14’ thru x’20’.

After you set the SLIP (and warn everyone first that you are setting a PER 
trap), start the GTF to capture the trace records.  Then submit jobs to create 
PDDBs.

For what it's worth, my observation of a PDDB found this combination of values 
(JES2 v1.11):   PDBDRMT is interpreted as a U value or a Rnnn value 
depending on PDBDNODE.  I was only checking for certain values of PDBDNODE so I 
came up with this partial set of field contents: 

PDBDNODE   PDBDRMT   PDBDUSER 
  zero   ¬zero  spacesPDBDRMT is a U value 
 our-node ¬zero  spacesPDBDRMT is Rnnn value.
 our-node  zero   U PDBDUSER contains the actual U 
value
 our-node  zero   spaceslocal SYSOUT

I did not care if PDBDNODE contained another node's value so I am not going to 
state what would be in PDBDRMT or PDBDUSER in that case, but the SLIP / TRACE 
should find that if you need to know.

regards, Joe D'Alessandro

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

Re: How to display JES2 fields from the PDDB

[Ed Jaffe]

On 9/11/2013 9:01 AM, Hansen, Dave L - Eagan, MN wrote:

Dear Group,

I am debugging a JES2 EXIT40.  I was asked what do the fields PDBDNODE, 
PDBDRMT and PDBUSER contain.  I am told PDBDRMT may not contain a non-zero 
value.  There is no command which will give me this information.  I am told I 
can set a slip trap on entry to the exit and take a dump at that point.

Q).  Is there a good book on taking a dump from an Exit?  Does anyone have an 
example of a slip trap to help me debug our PDDB (REG 2 is $PDDB, offset x'14' 
for 12 bytes is the routing info)?


If you are an (E)JES customer, you can issue the DU (dump) line command 
against the job to browse a comprehensive dump of all its SPOOL-resident 
control blocks. The part you are interested in looks like this:


*
* I O T  (ALLOCATION)
*

 SPOOL ADDRESS: 02.023C55

 COMMON SECTION:

   0068  C9D6E340 E2D4C6C4 E4D4D740 0002AFB6   *IOT SMFDUMP ..®¶*
 0010  0078  CBF2AA52  1800 02023C55 *ô2¡ê...í*
 0020  0088      **
 0030  0098  0145 66BC 0002  *...á..ï*
 0040  00A8   1000 0280  *...Ø*
 0050  00B8      **
 ===> Data at relative offset 00C8 through 00D7 is same as above <===

 TGAE SECTION:

 0070    0223 C500   *E...*
 0080  0010      **
 ===> Data at relative offset 0020 through 013F is same as above <===

 PDDB ENTRY:

 01B0    68800050 02023C53  0001 *ÇØ.&...ë*
 01C0  0010  0180E201    *.ØS.*
 01D0  0020  0800 0002  007E *...=*
 01E0  0030  E2E3C440 40404040 5C5C5C5C 5C5C5C5C   *STD *
 01F0  0040  40404040 40404040     * *
 0200  0050  5C5C5C5C 5C5C5C5C 5C5C5C5C 5C5C5C5C **
 0210  0060  5C5C5C5C 5C5C5C5C FF00  **
 0220  0070   0800   **
 0230  0080   CBF2AA52   *ô2¡ê*
 0240  0090     40404040   * *
 0250  00A0  40404040 40404040 40404040 D1C5E2D1   * JESJ*
 0260  00B0  C3D3C9D5 40404040 40404040 5001A051   *CLIN &.µé*
 0270  00C0  1555   829DB29D *íí.íb¸¥¸*
 0280  00D0  8DA71515 B7819315 15151515 829DB29D *ýx..¼al.b¸¥¸*
 0290  00E0  8DA71515   B7B6969C *ýx..¼¶oæ*
 02A0  00F0  808C918C   B7819315 *Øðjð¼al.*
 02B0  0100  15151515 B7BDB7A4 15151515 E2D4C640   *¼]¼uSMF *
 02C0  0110  40404040   8000   * ..Ø.*
 02D0  0120  00020402    **
 02E0  0130      **
 02F0  0140  0200    **
 0300  0150   E2D4C64B E2D4C6C4 E4D4D74B *SMF.SMFDUMP.*
 0310  0160  E2F0F1F7 F6F0F5F4 4BC4F0F0 F0F0F0F0 *S0176054.D00*
 0320  0170  F14BD1C5 E2D1C3D3 C9D54040 40404040   *1.JESJCLIN *

etc...

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

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

Re: COBOL "problem" (not really), but sort of.

[Sambataro, Anthony (NIH/NBS) [E]]

Could you point the programmer to the COBOL Reference and the following section?

Alignment rules
.
Alphanumeric, alphanumeric-edited, alphabetic, DBCS
For these receiving items, the following rules apply:
1. The data is aligned at the leftmost character position, and (if 
necessary)
truncated or padded with spaces at the right.

And since the caller's data/storage address is passed to the subroutine the 
caller's data area gets padded.

-Original Message-
From: John McKown [mailto:john.archie.mck...@gmail.com] 
Sent: Wednesday, September 11, 2013 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL "problem" (not really), but sort of.

I can try that. The programmer says that he intents to define the passed in 
area in the calling program at the front of his WORKING-STORAGE so that the 
area is larger. I.e. it is _planning_ on a buffer overflow and _hoping_ that it 
doesn't affect the calling program. I don't have authority to disallow this. 
And we don't do any kind of peer review because we just don't have the people 
left.


On Wed, Sep 11, 2013 at 12:09 PM, Thomas Berg wrote:

> I would say: the READ .. INTO .. statement doesn't look at the 
> numerical value in the length field, it only looks at the max possible 
> length as defined. And acts accordingly.
>
>
>
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 7:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: COBOL "problem" (not really), but sort of.
> >
> > A programmer came by today with a problem. He is sometimes getting a
> > S0C4-4 abend in a COBOL program. This is a subroutine. One of the 
> > parameters passed in is a data area, which can be of various 
> > lengths. It is defined with an OCCURS DEPENDING ON with a data 
> > element within the area. I.e. the first 05 level is PIC S9(5) COMP. 
> > The subroutine does a READ of a data set into this area. This is 
> > where the abend occurs. The reason is because the OCCURS DEPENDING 
> > ON maximum size is significantly larger than what the caller is 
> > passing it. And the READ to the 01 is trying to pad the entire possible 01 
> > level with blanks.
> >
> > The problem is how do I describe this to a COBOL programmer who just 
> > doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> > occurrences with blanks. And, if fact, to not even reference this 
> > area wherein they would have resided, had they existed. I'm just get 
> > "deer in headlights" looks. I'm not using the correct words, somehow.
> >
> > --
> > As of next week, passwords will be entered in Morse code.
> >
> > 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
>



--
As of next week, passwords will be entered in Morse code.

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: COBOL "problem" (not really), but sort of.

[John McKown]

Thanks. I'll point him to it. He has already, somewhat jokingly, said "fix
it!" But COBOL doesn't have the DWIW (Do What I Want) verb.


On Wed, Sep 11, 2013 at 12:46 PM, Sambataro, Anthony (NIH/NBS) [E] <
anthony.sambat...@nih.gov> wrote:

> Could you point the programmer to the COBOL Reference and the following
> section?
>
> Alignment rules
> .
> Alphanumeric, alphanumeric-edited, alphabetic, DBCS
> For these receiving items, the following rules apply:
> 1. The data is aligned at the leftmost character position, and (if
> necessary)
> truncated or padded with spaces at the right.
>
> And since the caller's data/storage address is passed to the subroutine
> the caller's data area gets padded.
>
> -Original Message-
> From: John McKown [mailto:john.archie.mck...@gmail.com]
> Sent: Wednesday, September 11, 2013 1:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL "problem" (not really), but sort of.
>
> I can try that. The programmer says that he intents to define the passed
> in area in the calling program at the front of his WORKING-STORAGE so that
> the area is larger. I.e. it is _planning_ on a buffer overflow and _hoping_
> that it doesn't affect the calling program. I don't have authority to
> disallow this. And we don't do any kind of peer review because we just
> don't have the people left.
>
>
> On Wed, Sep 11, 2013 at 12:09 PM, Thomas Berg  >wrote:
>
> > I would say: the READ .. INTO .. statement doesn't look at the
> > numerical value in the length field, it only looks at the max possible
> > length as defined. And acts accordingly.
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown
> > > Sent: Wednesday, September 11, 2013 7:02 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: COBOL "problem" (not really), but sort of.
> > >
> > > A programmer came by today with a problem. He is sometimes getting a
> > > S0C4-4 abend in a COBOL program. This is a subroutine. One of the
> > > parameters passed in is a data area, which can be of various
> > > lengths. It is defined with an OCCURS DEPENDING ON with a data
> > > element within the area. I.e. the first 05 level is PIC S9(5) COMP.
> > > The subroutine does a READ of a data set into this area. This is
> > > where the abend occurs. The reason is because the OCCURS DEPENDING
> > > ON maximum size is significantly larger than what the caller is
> > > passing it. And the READ to the 01 is trying to pad the entire
> possible 01 level with blanks.
> > >
> > > The problem is how do I describe this to a COBOL programmer who just
> > > doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> > > occurrences with blanks. And, if fact, to not even reference this
> > > area wherein they would have resided, had they existed. I'm just get
> > > "deer in headlights" looks. I'm not using the correct words, somehow.
> > >
> > > --
> > > As of next week, passwords will be entered in Morse code.
> > >
> > > 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
> >
>
>
>
> --
> As of next week, passwords will be entered in Morse code.
>
> 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
>



-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

Re: COBOL "problem" (not really), but sort of.

[Frank Swarbrick]

If you're still up for it...

The program you've posted is not valid COBOL.  Did you retype it?  Or do you 
have some sort of pre-processor that converts it to valid COBOL?  Even 
forgetting that, I don't see how this could possibly ever work.  XDF-RECORDV is 
an implicit redefines of XDF-RECORD.  But in LINK-RECORD they are concatenated. 
 So I'm afraid it doesn't look like this is "reality".

Frank





>
> From: John McKown 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, September 11, 2013 3:23 PM
>Subject: Re: COBOL "problem" (not really), but sort of.
> 
>
>I have now studied the program source. Let's just drop this discussion
>because the program is junk.
>
>FD  XDF-FILE.
>
>01 XDF-RECORD
>02 XDF-REC-LNG                     S9(5)    COMP      +400
>02 FILLER                          X(04)              SPACES
>02 XDF-KEY                         X(16)                 MP05356899M00
>01 XDF-RECORDV
>02 XDF-DATA                        OCCURS 00 TO 12040
>                                    DEPENDING ON XDF-REC-LNG.
>
>
>WORKING-STORAGE SECTION.
>01 WSV-WORK-VARIABLES
>02 WSV-X1                         9(2).
>02 WSV-REC-LNG                     S9(5)    COMP.
>
>LINKAGE-SECTION.
>01 MSSXDFIO-LINKAGE
>02 MSSXDFIO-FILE                   X(01)              A
>  88 MSSXDFIO-FILE-ACTV                               'A'
>  88 MSSXDFIO-FILE-ARCH                               'R'
>02 MSSXDFIO-RC                     X(02)              00
>01 LINK-RECORD
>02 LINK-REC-LNG                    S9(5)    COMP      +400
>02 FILLER                          X(04)              SPACES
>02 LINK-KEY                        X(16)                 MP05356899M00
>02 LINK-DATAX
>  03 LINK-DATA                      OCCURS 00 TO 13000
>                                    DEPENDING ON WSV-REC-LNG
>
>PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD.
>
>MOVE LINK-REC-LNG TO WSV-REC-LEN.
>READ FILE INTO LINK-RECORD.
>
>In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What the
>programmer expected was that the READ would read the logical record into
>the FD area (true).  And then MOVE however much was just READ into
>LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at the
>time of the copy. This is just poor coding. And he doesn't want to change
>it to be proper. The values in the FD area are correct after the READ. But
>he doesn't want to do a MOVE after the READ. I don't know why. I don't
>think he really understands how COBOL does things. And he is not a
>youngster.
>
>
>I am now on vacation for 4 days. Thanks to all.
>
>
>
>
>
>On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg wrote:
>
>> I thought the length field was in LINKAGE SECTION given by the caller ?
>>
>>
>>
>> Best Regards
>> Thomas Berg
>> ___
>> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
>>
>>
>>
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> > Behalf Of John McKown
>> > Sent: Wednesday, September 11, 2013 10:16 PM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: COBOL "problem" (not really), but sort of.
>> >
>> > Well explained. I will keep this to show him when this next abends. It
>> > is a problem just waiting for a critical month end to come around.
>> >
>> >
>> > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
>> > peter.far...@broadridge.com> wrote:
>> >
>> > > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
>> > > Long
>> > > said:  "Ignorance is curable, only stupidity is fatal."
>> > >
>> > > Second, let's try one more time to penetrate the thick cranial
>> > > boundary in question (not yours):
>> > >
>> > > IF the FILE definition looks like this:
>> > >
>> > > FD  IN-FILE ...  .
>> > > 01  FILE-RECORD.
>> > >     05  FILE-REC-LEN        PIC S9(5) COMP.
>> > >     05  FILE-REC-DATA       OCCURS 1 TO 32760
>> > >                             DEPENDING ON FILE-REC-LEN
>> > >                             PIC X.
>> > >
>> > > And the working-storage area looks like this:
>> > >
>> > > 01  WORK-RECORD.
>> > >     05  WORK-REC-LEN        PIC S9(5) COMP.
>> > >     05  WORK-REC-DATA       OCCURS 1 TO 32760
>> > >                             DEPENDING ON FILE-REC-LEN
>> > >                             PIC X.
>> > >
>> > > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
>> > >
>> > > READ IN-FILE
>> > >     AT END (do endfile processing)
>> > >     NOT AT END
>> > >         MOVE FILE-REC-LEN TO WORK-REC-LEN.
>> > >         MOVE FILE-RECORD  TO WORK-RECORD.
>> > > END-READ
>> > >
>> > > The reason that it does not work with READ INTO is that the
>> > > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the
>> > > working-storage record area.  The MOVE is done at the 01 LEVEL, and in
>> > > this case the TO-occurs-depending-on-variable must be set BEFORE the
>> > > MOVE begins.  READ does not

FW: JES2 "Node" Question

[Hansen, Dave L - Eagan, MN]

I request for knowledge.

CROSS POSTED to JES2 and IBM.

From: Hansen, Dave L - Eagan, MN
Sent: Wednesday, September 11, 2013 10:45 AM
To: 'jes...@listserv.vt.edu'; 'i...@listserv.uark.edu'
Subject: JES2 "Node" Question

Dear Group,

   I have been working with IBM to Implement a JES2 EXIT 40.  I am doing this 
without too much JES knowledge.  I was asked to move output from one MVS spool 
to another.  We had a product (VPS) that would take the print off the MVS spool 
and send it to remote printers.  Now we don't run that software at our "west 
side" location.  I just want to change N1.U1234 to N2.U1234.  Then JES will 
ROUTE the output from N1 to N2.  However the change results in N1.U1234 being 
modified to N2.R1234.  I did some testing and things are not as I expected.

Q).  On the SDSF screen - With the EXIT in place, Why doesn't Node reflect my 
change to N2?  RMT is now 1234.  NODE is supposed to be the "JES Print Node".  
I would expect the node to be the destination node.



   From SDSF I entered NODE.  It see N2, MN1 and OWNNODE.  So we are #2 aka MN1.

Q).  Is there an advantage to using "N2" over "MN1"?  The terminology gets 
confusing.



I tried this just to confuse myself:
I ran three jobs to print output, but I put them on HOLD.  My OUTPUTS were:
   DEFAULT=Y,DEST=N4.U9889DP,CLASS=H
   DEFAULT=Y,DEST=N2.U9889DP,CLASS=H   *** OWNNODE ***
   DEFAULT=Y,DEST=N12.U9889DP,CLASS=H
I looked at SDSF "O" and saw:  RMT is Blank and NODE is "2" for all three.  
DEST is LOCAL .  The output for N2.U9889DP has an extra piece with DEST U9889DP 
(The actual payload to print).

Q).  Why doesn't "4" or "12" show up under NODE?  I used "N4" and "N12".



  Perhaps we have something in JES setup to change something to "R"?  We are 
testing this on two separate JES2 systems.  They may not be the same, and I 
sure don't know what is "normal".   On one system I see SDSF output with RMT as 
7298, NODE as BLANK, and DEST as U7298.

Q).  Why would this job have a BLANK NODE?  The systems are different and I bet 
the jobs we ran were different also.  I guess it all "depends".  I'm just not 
sure what it all depends on.



   The reason I ask is my assembler job is looking to match $OWNNODE to 
PDBDNODE.  I took out that line because I have no idea what these NODEs should 
be.  Right now I just change PDBDNODE regardless of what it was.



   Please send help,  Dave

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

Paper: z/OS WebSphere and J2EE Security

[Ed Gould]

>http://www-01.ibm.com/marketing/campaigns/US-103GP31E/2013 Q3 App  
Driven internal.html?language=en_US<


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

Re: 1403 Printer components manual GA24-3073-3

[Tony Babonas]

Ah, what non-fond memories!  We had a computer room operator that was 
sensitive to the IBM provided glue, which had a potent aroma.  We found 
that a 1 inch length of ordinary scotch tape, cut in two lengthwise, 
worked well and outlasted the actual CC tape itself.  Eventually the 
sprocket holes would wear out and drive mechanism would race out of 
control.  We made a point of creating numerous spares and discarding any 
suspect ones before it died dramatically.  Each shift would inspect the 
existing CCt for wear, similarly to eyeballing a car's fan belt or 
serpentine.  If in doubt, replace.  Cheap insurance.






On 9/11/2013 4:01 PM, Gerhard Postpischil wrote:

On 9/11/2013 2:39 PM, efinnell15 wrote:

in two. The paper tapes for forms control were like gold with special
forms. In a pinch could be duplicated with a hole punch and
cellophane tape.


IIRC, these were mylar tapes, and came fairly late. We used heavy duty
paper that came with an attached marking sheet - the programmer or
operations staff marked the positions to be punched, the corresponding
holes would be punched out, the the tape would be separated and trimmed
to length, then glued.

We imposed the additional restriction that all channels had to have at
least one punch in them, to prevent run-away paper ejection.

Gerhard Postpischil
Bradford, Vermont

--
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: PDS/E, Shared Dasd, and COBOL V5

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Zelden
> Sent: Wednesday, September 11, 2013 12:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E, Shared Dasd, and COBOL V5
> 
> On Wed, 11 Sep 2013 19:08:19 +, Gibney, Dave 
> wrote:
> 
> >>
> >> Neither.  zFS can safely be shared R/O outside sysplex / GRS
> >> boundaries.   BTW, with PDSESHARING(NORMAL), PDSE can
> >> be shared R/W outside the sysplex, but the boundaries must still
> >> be within the GRSplex.   However, they can't be shared R/W between
> >> systems managed by MII (MIM) because the ENQs issued for
> >> SYSZIGW0 and SYSZIGW1 are issued with RNL=NO.  IIRC, this
> >> wasn't always the case and IBM "broke this" for CA MIM
> >> customers around DFSMS/MVS 1.5.  Thank you IBM.
> >>
> >> Regards,
> 
> 
> >I usually don't disagree with Mark, but my experience is that without the XCF
> >communication Barbara mentioned (i.e. inside a sysplex), updating a PDS/E
> >from one LPAR can cause abends of address spaces in another LPAR that are
> >actively using the PDS/E.
>  >Specifically, when VPS from LRS shipped with all PDS/E including the CNTL
> >libraries, I abended my production VPS by modifying shared printer
> >definitions from the development LPAR.
> 
> 
> XCF is not involved when PDSE is using PDSESHARING(NORMAL).Were
> you using PDSESHARING(EXTENDED)?  WAS PDSESHARING(NORMAL)
> in effect on BOTH systems involved?   Were your 2 systems involved
> in the same GRS ring?   With PDSESHARING(NORMAL) you would not
> have even been able to update a member on one system if the other system
> had the PDSE opened for update.  The sharing is on a data set level, not on a
> member level (sharing at the member level on the same system does work).

Very simple set-up. No ring at all. Independent monplexes. NO serialization.
Yes it is playing with fire :)
For the most part, updates to files on the few shared volumes are done by a 
Sysprog. Down to two of us.
The point of the shared executable and parm (cntl) is to attempt to minimize 
differences between production and devl/test LPARs while separating the impacts.

If I know I am the only person updating a PDS and I know I'm doing it from LPAR 
A, I know I shouldn't have a compress job or something running in LPAR B. I 
even know that a job running in LPAR B having done a BLDL or such will always 
get the same old member for the life of that BLDL (insert known caution about 
new extents).
Again, I know it is playing with fire, but it does work. As long as the updates 
are controlled, limited and one-way or at least not any degree of simultaneity.

Update PDS/E from LPAR A and information already loaded by active address 
spaces in LPAR B becomes immediately invalid leading to fetch and other 
errors/abends.

And as I stated in  earlier note, our application change management system is 
dependent on updating the production libraries from the development LPAR while 
at the same time supporting ongoing read for execution from both production and 
development LPARs.

> 
> Regards,
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> ITIL v3 Foundation Certified
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> 
> 
> 
> 
> 
> 
> --
> 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 "problem" (not really), but sort of.

[Thomas Berg]

OMG


Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 11, 2013 11:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL "problem" (not really), but sort of.
> 
> I have now studied the program source. Let's just drop this discussion
> because the program is junk.
> 
> FD  XDF-FILE.
> 
> 01 XDF-RECORD
>  02 XDF-REC-LNG S9(5)COMP  +400
>  02 FILLER  X(04)  SPACES
>  02 XDF-KEY X(16) MP05356899M00
> 01 XDF-RECORDV
>  02 XDF-DATAOCCURS 00 TO 12040
> DEPENDING ON XDF-REC-LNG.
> 
> 
> WORKING-STORAGE SECTION.
> 01 WSV-WORK-VARIABLES
>  02 WSV-X1 9(2).
>  02 WSV-REC-LNG S9(5)COMP.
> 
> LINKAGE-SECTION.
> 01 MSSXDFIO-LINKAGE
>  02 MSSXDFIO-FILE   X(01)  A
>   88 MSSXDFIO-FILE-ACTV   'A'
>   88 MSSXDFIO-FILE-ARCH   'R'
>  02 MSSXDFIO-RC X(02)  00
> 01 LINK-RECORD
>  02 LINK-REC-LNGS9(5)COMP  +400
>  02 FILLER  X(04)  SPACES
>  02 LINK-KEYX(16) MP05356899M00
>  02 LINK-DATAX
>   03 LINK-DATA  OCCURS 00 TO 13000
> DEPENDING ON WSV-REC-LNG
> 
> PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD.
> 
> MOVE LINK-REC-LNG TO WSV-REC-LEN.
> READ FILE INTO LINK-RECORD.
> 
> In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What
> the programmer expected was that the READ would read the logical record
> into the FD area (true).  And then MOVE however much was just READ into
> LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at
> the time of the copy. This is just poor coding. And he doesn't want to
> change it to be proper. The values in the FD area are correct after the
> READ. But he doesn't want to do a MOVE after the READ. I don't know why.
> I don't think he really understands how COBOL does things. And he is not
> a youngster.
> 
> 
> I am now on vacation for 4 days. Thanks to all.
> 
> 
> 
> 
> 
> On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg
> wrote:
> 
> > I thought the length field was in LINKAGE SECTION given by the caller
> ?
> >
> >
> >
> > Best Regards
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> >
> >
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown
> > > Sent: Wednesday, September 11, 2013 10:16 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: COBOL "problem" (not really), but sort of.
> > >
> > > Well explained. I will keep this to show him when this next abends.
> > > It is a problem just waiting for a critical month end to come
> around.
> > >
> > >
> > > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> > > peter.far...@broadridge.com> wrote:
> > >
> > > > If I am not misremembering, Mr. Robert Heinlein's character
> > > > Lazurus Long
> > > > said:  "Ignorance is curable, only stupidity is fatal."
> > > >
> > > > Second, let's try one more time to penetrate the thick cranial
> > > > boundary in question (not yours):
> > > >
> > > > IF the FILE definition looks like this:
> > > >
> > > > FD  IN-FILE ...  .
> > > > 01  FILE-RECORD.
> > > > 05  FILE-REC-LENPIC S9(5) COMP.
> > > > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> > > > DEPENDING ON FILE-REC-LEN
> > > > PIC X.
> > > >
> > > > And the working-storage area looks like this:
> > > >
> > > > 01  WORK-RECORD.
> > > > 05  WORK-REC-LENPIC S9(5) COMP.
> > > > 05  WORK-REC-DATA   OCCURS 1 TO 32760
> > > > DEPENDING ON FILE-REC-LEN
> > > > PIC X.
> > > >
> > > > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
> > > >
> > > > READ IN-FILE
> > > > AT END (do endfile processing)
> > > > NOT AT END
> > > > MOVE FILE-REC-LEN TO WORK-REC-LEN.
> > > > MOVE FILE-RECORD  TO WORK-RECORD.
> > > > END-READ
> > > >
> > > > The reason that it does not work with READ INTO is that the
> > > > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for
> > > > the working-storage record area.  The MOVE is done at the 01
> > > > LEVEL, and in this case the TO-occurs-depending-on-variable must
> > > > be set BEFORE the MOVE begins.  READ does not do that for you; it
> > > >

Re: Currently dispatched TCB in SRB mode

[Shmuel Metz (Seymour J.)]

In <0fl0391cl08fpq7fjacml790i0ukfv2...@4ax.com>, on 09/11/2013
   at 02:40 PM, Binyamin Dissen  said:

>With disablement, you can guarantee that your processor will not be
>interrupted between fetching the address and accessing it 

You can not, however, be guarntied that another processor won't change
anything. What happens if z/OS is in the middle of taking the other
CPU offline?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: COBOL "problem" (not really), but sort of.

[Frank Swarbrick]

I agree.



>
> From: "Farley, Peter x23353" 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, September 11, 2013 3:02 PM
>Subject: Re: COBOL "problem" (not really), but sort of.
> 
>
>That will work, but I can't tell from John's original post if in his case the 
>occurs-depending on AND the "record varying" data names are the same.  The 
>fact that they are all the same in your example is what makes it work.
>
>If all the "depending on" parts are the same name, your technique will 
>certainly work, even if the "vlen-record" is in the LINKAGE section.  The key 
>is to make all of them use the same name.
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Frank Swarbrick
>Sent: Wednesday, September 11, 2013 4:50 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: COBOL "problem" (not really), but sort of.
>
>I'm not sure if I'm understanding this 100% correctly, but take a look at this:
>
> identification division.
> program-id.  vlen.
> environment division.
> input-output section.
> file-control.
> select vlen-file
>    assign to vlenfl.
> data division.
> file section.
> fd  vlen-file
> record varying depending on vlen-len.
> 01  vlen-buffer.
> 05  pic x occurs 1 to 252 depending on vlen-len.
>
> working-storage section.
> 01  at-end-sw   pic x value 'N'.
> 88  at-end    value 'Y'.
> 01  vlen-record.
> 05  vlen-len    pic 9(4) comp-5.
> 05  vlen-data.
> 10  pic x occurs 1 to 32760 depending on vlen-len.
> linkage section.
> procedure division.
> open input vlen-file
> perform until at-end
>*    move zero to vlen-len
> read vlen-file into vlen-data
> at end set at-end to true
> not at end
> display vlen-len
> display vlen-data
> end-read
> end-perform
> close vlen-file
> goback.
>
>It appears to me to work (even if the "move zero to vlen-len" statement is 
>uncommented).  I believe that the key here is the "record varying depending on 
>vlen-len".  I haven't looked at the generated code, but my guess is that this 
>generates code that first moves the actual length red into vlen-len and then 
>moves the data from the buffer into vlen-data, but only for a length of 
>vlen-len.
>
>Obviously in the case of the original example the vlen-record area is being 
>passed in via the linkage section.  But that should not matter, as long as its 
>big enough to hold the largest possible record size in the file.
>
>Frank
>
>
>
>
>
>>
>> From: "Farley, Peter x23353" 
>>To: IBM-MAIN@LISTSERV.UA.EDU 
>>Sent: Wednesday, September 11, 2013 2:11 PM
>>Subject: Re: COBOL "problem" (not really), but sort of.
>> 
>>
>>If I am not misremembering, Mr. Robert Heinlein's character Lazurus Long 
>>said:  "Ignorance is curable, only stupidity is fatal."
>>
>>Second, let's try one more time to penetrate the thick cranial boundary in 
>>question (not yours):
>>
>>IF the FILE definition looks like this:
>>
>>FD  IN-FILE ...  .
>>01  FILE-RECORD.
>>    05  FILE-REC-LEN        PIC S9(5) COMP.
>>    05  FILE-REC-DATA       OCCURS 1 TO 32760
>>                            DEPENDING ON FILE-REC-LEN
>>                            PIC X.
>>
>>And the working-storage area looks like this:
>>
>>01  WORK-RECORD.
>>    05  WORK-REC-LEN        PIC S9(5) COMP.
>>    05  WORK-REC-DATA       OCCURS 1 TO 32760
>>                            DEPENDING ON FILE-REC-LEN
>>                            PIC X.
>>
>>Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
>>
>>READ IN-FILE
>>    AT END (do endfile processing)
>>    NOT AT END
>>        MOVE FILE-REC-LEN TO WORK-REC-LEN.
>>        MOVE FILE-RECORD  TO WORK-RECORD.
>>END-READ
>>
>>The reason that it does not work with READ INTO is that the 
>>occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the 
>>working-storage record area.  The MOVE is done at the 01 LEVEL, and in this 
>>case the TO-occurs-depending-on-variable must be set BEFORE the MOVE begins.  
>>READ does not do that for you; it never did and never will.
>>
>>You might ask him how he thinks the READ is supposed to knows what the 
>>correct value for the OTHER occurs-depending-on-variable is supposed to be?  
>>Especially if it is passed in as a LINKAGE SECTION item, the program 
>>containing the READ CANNOT KNOW what that value is at the present time, NOR 
>>what its current value is.  Rules of MOVE mean that the value must be set 
>>BEFORE THE MOVE BEGINS.  READ does not and will not do it for you.
>>
>>If that doesn't make it all the way through the dense bony material with 
>>which you are dealing, then I guess your answer is best: ignore the results.
>>
>>Good luck.
>>
>>Peter
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>Behalf Of John McKown
>>Sent: Wedn

Re: PDS/E, Shared Dasd, and COBOL V5

[John Gilmore]

I had begun to think that my experience with PDSEs was somehow
atypical, too lucky, because I had not encountered the grievous
problems that featured in others' war stories.

I therefore spent a long afternoon trying to reproduce and clear some
of these problems.  My experience was much like Mark's.  The problems
reported here did---some of them anyway---occur; but they were readily
cleared away.

I conclude that this is a problem of a different sort.   Some people
will continue to use PDSs, 3270 emulators, and the like until they are
pried, irrelevantly, from their cold dead hands.

They are and should be free to do this, but it  needs to be understood
that no technical argument will avail against their rooted
preferences.

John Gilmore, Ashland, MA 01721 - USA

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

Re: COBOL "problem" (not really), but sort of.

[Frank Swarbrick]

I'm not sure if I'm understanding this 100% correctly, but take a look at this:

 identification division.
 program-id.  vlen.
 environment division.
 input-output section.
 file-control.
 select vlen-file
    assign to vlenfl.
 data division.
 file section.
 fd  vlen-file
 record varying depending on vlen-len.
 01  vlen-buffer.
 05  pic x occurs 1 to 252 depending on vlen-len.

 working-storage section.
 01  at-end-sw   pic x value 'N'.
 88  at-end    value 'Y'.
 01  vlen-record.
 05  vlen-len    pic 9(4) comp-5.
 05  vlen-data.
 10  pic x occurs 1 to 32760 depending on vlen-len.
 linkage section.
 procedure division.
 open input vlen-file
 perform until at-end
*    move zero to vlen-len
 read vlen-file into vlen-data
 at end set at-end to true
 not at end
 display vlen-len
 display vlen-data
 end-read
 end-perform
 close vlen-file
 goback.

It appears to me to work (even if the "move zero to vlen-len" statement is 
uncommented).  I believe that the key here is the "record varying depending on 
vlen-len".  I haven't looked at the generated code, but my guess is that this 
generates code that first moves the actual length red into vlen-len and then 
moves the data from the buffer into vlen-data, but only for a length of 
vlen-len.

Obviously in the case of the original example the vlen-record area is being 
passed in via the linkage section.  But that should not matter, as long as its 
big enough to hold the largest possible record size in the file.

Frank





>
> From: "Farley, Peter x23353" 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, September 11, 2013 2:11 PM
>Subject: Re: COBOL "problem" (not really), but sort of.
> 
>
>If I am not misremembering, Mr. Robert Heinlein's character Lazurus Long said: 
> "Ignorance is curable, only stupidity is fatal."
>
>Second, let's try one more time to penetrate the thick cranial boundary in 
>question (not yours):
>
>IF the FILE definition looks like this:
>
>FD  IN-FILE ...  .
>01  FILE-RECORD.
>    05  FILE-REC-LEN        PIC S9(5) COMP.
>    05  FILE-REC-DATA       OCCURS 1 TO 32760
>                            DEPENDING ON FILE-REC-LEN
>                            PIC X.
>
>And the working-storage area looks like this:
>
>01  WORK-RECORD.
>    05  WORK-REC-LEN        PIC S9(5) COMP.
>    05  WORK-REC-DATA       OCCURS 1 TO 32760
>                            DEPENDING ON FILE-REC-LEN
>                            PIC X.
>
>Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
>
>READ IN-FILE
>    AT END (do endfile processing)
>    NOT AT END
>        MOVE FILE-REC-LEN TO WORK-REC-LEN.
>        MOVE FILE-RECORD  TO WORK-RECORD.
>END-READ
>
>The reason that it does not work with READ INTO is that the 
>occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the 
>working-storage record area.  The MOVE is done at the 01 LEVEL, and in this 
>case the TO-occurs-depending-on-variable must be set BEFORE the MOVE begins.  
>READ does not do that for you; it never did and never will.
>
>You might ask him how he thinks the READ is supposed to knows what the correct 
>value for the OTHER occurs-depending-on-variable is supposed to be?  
>Especially if it is passed in as a LINKAGE SECTION item, the program 
>containing the READ CANNOT KNOW what that value is at the present time, NOR 
>what its current value is.  Rules of MOVE mean that the value must be set 
>BEFORE THE MOVE BEGINS.  READ does not and will not do it for you.
>
>If that doesn't make it all the way through the dense bony material with which 
>you are dealing, then I guess your answer is best: ignore the results.
>
>Good luck.
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of John McKown
>Sent: Wednesday, September 11, 2013 2:27 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: COBOL "problem" (not really), but sort of.
>
>What you said was basically what I told the programmer to do. What he
>really wants is for the READ  INTO to do is to read in the record
>"somewhere" (i.e. the I/O buffer). The ODO value is within the record
>itself. So he was wanting COBOL to effectively do a MOVE of the ODO
>variable, then do the rest of the MOVE dependent on the just updated value
>of the ODO variable. Like a "two stage" move. I told him that I didn't
>think COBOL would do it that way, but he basically insisted that it was
>what he wanted and was going to get or die (ABEND) trying. I don't know why
>he doesn't just READ without the INTO and then MOVE from the 01 in the FD
>to the 01 in the LINKAGE SECTION (sorry, said WORKING STORAGE in previous
>posts). He just doesn't want to. I have noted the program name and will
>just shrug if/when it starts abending in production (if it gets that far).
>
>
>On Wed, Sep 11, 2013 at 1:13 

Re: COBOL "problem" (not really), but sort of.

[John McKown]

I have now studied the program source. Let's just drop this discussion
because the program is junk.

FD  XDF-FILE.

01 XDF-RECORD
 02 XDF-REC-LNG S9(5)COMP  +400
 02 FILLER  X(04)  SPACES
 02 XDF-KEY X(16) MP05356899M00
01 XDF-RECORDV
 02 XDF-DATAOCCURS 00 TO 12040
DEPENDING ON XDF-REC-LNG.


WORKING-STORAGE SECTION.
01 WSV-WORK-VARIABLES
 02 WSV-X1 9(2).
 02 WSV-REC-LNG S9(5)COMP.

LINKAGE-SECTION.
01 MSSXDFIO-LINKAGE
 02 MSSXDFIO-FILE   X(01)  A
  88 MSSXDFIO-FILE-ACTV   'A'
  88 MSSXDFIO-FILE-ARCH   'R'
 02 MSSXDFIO-RC X(02)  00
01 LINK-RECORD
 02 LINK-REC-LNGS9(5)COMP  +400
 02 FILLER  X(04)  SPACES
 02 LINK-KEYX(16) MP05356899M00
 02 LINK-DATAX
  03 LINK-DATA  OCCURS 00 TO 13000
DEPENDING ON WSV-REC-LNG

PROCEDURE DIVISION USING MSSXDFIO-LINKAGE LINK-RECORD.

MOVE LINK-REC-LNG TO WSV-REC-LEN.
READ FILE INTO LINK-RECORD.

In the dump, WSV-REC-LEN at the time of the S0C4-4 is +1077952576! What the
programmer expected was that the READ would read the logical record into
the FD area (true).  And then MOVE however much was just READ into
LINK-RECORD, apparently with NO regard to the value of WSV-REC-LEN at the
time of the copy. This is just poor coding. And he doesn't want to change
it to be proper. The values in the FD area are correct after the READ. But
he doesn't want to do a MOVE after the READ. I don't know why. I don't
think he really understands how COBOL does things. And he is not a
youngster.


I am now on vacation for 4 days. Thanks to all.





On Wed, Sep 11, 2013 at 3:39 PM, Thomas Berg wrote:

> I thought the length field was in LINKAGE SECTION given by the caller ?
>
>
>
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
>
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 10:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: COBOL "problem" (not really), but sort of.
> >
> > Well explained. I will keep this to show him when this next abends. It
> > is a problem just waiting for a critical month end to come around.
> >
> >
> > On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> > peter.far...@broadridge.com> wrote:
> >
> > > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
> > > Long
> > > said:  "Ignorance is curable, only stupidity is fatal."
> > >
> > > Second, let's try one more time to penetrate the thick cranial
> > > boundary in question (not yours):
> > >
> > > IF the FILE definition looks like this:
> > >
> > > FD  IN-FILE ...  .
> > > 01  FILE-RECORD.
> > > 05  FILE-REC-LENPIC S9(5) COMP.
> > > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> > > DEPENDING ON FILE-REC-LEN
> > > PIC X.
> > >
> > > And the working-storage area looks like this:
> > >
> > > 01  WORK-RECORD.
> > > 05  WORK-REC-LENPIC S9(5) COMP.
> > > 05  WORK-REC-DATA   OCCURS 1 TO 32760
> > > DEPENDING ON FILE-REC-LEN
> > > PIC X.
> > >
> > > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
> > >
> > > READ IN-FILE
> > > AT END (do endfile processing)
> > > NOT AT END
> > > MOVE FILE-REC-LEN TO WORK-REC-LEN.
> > > MOVE FILE-RECORD  TO WORK-RECORD.
> > > END-READ
> > >
> > > The reason that it does not work with READ INTO is that the
> > > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the
> > > working-storage record area.  The MOVE is done at the 01 LEVEL, and in
> > > this case the TO-occurs-depending-on-variable must be set BEFORE the
> > > MOVE begins.  READ does not do that for you; it never did and never
> > will.
> > >
> > > You might ask him how he thinks the READ is supposed to knows what the
> > > correct value for the OTHER occurs-depending-on-variable is supposed
> > to be?
> > >  Especially if it is passed in as a LINKAGE SECTION item, the program
> > > containing the READ CANNOT KNOW what that value is at the present
> > > time, NOR what its current value is.  Rules of MOVE mean that the
> > > value must be set BEFORE THE MOVE BEGINS.  READ does not and will not
> > do it for you.
> > >
> > > If that doesn't make it all the way through the dense bony material
> > > with which you are dealing, then I guess your answer is best: ignore
> > the results.
> > 

Re: COBOL "problem" (not really), but sort of.

[Farley, Peter x23353]

True, John did say that in his original post.  But the principal is the same -- 
the occurs-depending-on variable in the TO area must be set before the MOVE for 
the length that the programmer wants to be moved, whether more or exactly as 
much as the input record area, or even less for that matter.

Of course, if there is a disagreement between the maximum stated size of the TO 
area between the caller and the callee, all bets are off -- abends would be a 
probable (though not guaranteed) result in that case.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Berg
Sent: Wednesday, September 11, 2013 4:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL "problem" (not really), but sort of.

I thought the length field was in LINKAGE SECTION given by the caller ?

Best Regards
Thomas Berg

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 11, 2013 10:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL "problem" (not really), but sort of.
> 
> Well explained. I will keep this to show him when this next abends. It
> is a problem just waiting for a critical month end to come around.
> 
> 
> On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
> 
> > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
> > Long
> > said:  "Ignorance is curable, only stupidity is fatal."
> >
> > Second, let's try one more time to penetrate the thick cranial
> > boundary in question (not yours):
> >
> > IF the FILE definition looks like this:
> >
> > FD  IN-FILE ...  .
> > 01  FILE-RECORD.
> > 05  FILE-REC-LENPIC S9(5) COMP.
> > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> > DEPENDING ON FILE-REC-LEN
> > PIC X.
> >
> > And the working-storage area looks like this:
> >
> > 01  WORK-RECORD.
> > 05  WORK-REC-LENPIC S9(5) COMP.
> > 05  WORK-REC-DATA   OCCURS 1 TO 32760
> > DEPENDING ON FILE-REC-LEN
> > PIC X.
> >
> > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
> >
> > READ IN-FILE
> > AT END (do endfile processing)
> > NOT AT END
> > MOVE FILE-REC-LEN TO WORK-REC-LEN.
> > MOVE FILE-RECORD  TO WORK-RECORD.
> > END-READ
> >
> > The reason that it does not work with READ INTO is that the
> > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the
> > working-storage record area.  The MOVE is done at the 01 LEVEL, and in
> > this case the TO-occurs-depending-on-variable must be set BEFORE the
> > MOVE begins.  READ does not do that for you; it never did and never
> will.
> >
> > You might ask him how he thinks the READ is supposed to knows what the
> > correct value for the OTHER occurs-depending-on-variable is supposed
> to be?
> >  Especially if it is passed in as a LINKAGE SECTION item, the program
> > containing the READ CANNOT KNOW what that value is at the present
> > time, NOR what its current value is.  Rules of MOVE mean that the
> > value must be set BEFORE THE MOVE BEGINS.  READ does not and will not
> do it for you.
> >
> > If that doesn't make it all the way through the dense bony material
> > with which you are dealing, then I guess your answer is best: ignore
> the results.
> >
> > Good luck.
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 2:27 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: COBOL "problem" (not really), but sort of.
> >
> > What you said was basically what I told the programmer to do. What he
> > really wants is for the READ  INTO to do is to read in the record
> > "somewhere" (i.e. the I/O buffer). The ODO value is within the record
> > itself. So he was wanting COBOL to effectively do a MOVE of the ODO
> > variable, then do the rest of the MOVE dependent on the just updated
> > value of the ODO variable. Like a "two stage" move. I told him that I
> > didn't think COBOL would do it that way, but he basically insisted
> > that it was what he wanted and was going to get or die (ABEND) trying.
> > I don't know why he doesn't just READ without the INTO and then MOVE
> > from the 01 in the FD to the 01 in the LINKAGE SECTION (sorry, said
> > WORKING STORAGE in previous posts). He just doesn't want to. I have
> > noted the program name and will just shrug if/when it starts abending
> in production (if it gets that far).
> >
> >
> > On Wed, Sep 11, 2013 at 1:13 PM, Joel C. Ewing 
> wrote:
> >
> > > On 09/11/2013 12:02 PM, John McKown wrote:
> > > > A programmer came by today with a problem. He is sometimes getting
> > > > a
> > > S0C4-4
> > > > abend in a COBOL program. This is a subroutine. One of the
> > > > paramet

Re: 1403 Printer components manual GA24-3073-3

[Gerhard Postpischil]

On 9/11/2013 2:39 PM, efinnell15 wrote:

in two. The paper tapes for forms control were like gold with special
forms. In a pinch could be duplicated with a hole punch and
cellophane tape.


IIRC, these were mylar tapes, and came fairly late. We used heavy duty 
paper that came with an attached marking sheet - the programmer or 
operations staff marked the positions to be punched, the corresponding 
holes would be punched out, the the tape would be separated and trimmed 
to length, then glued.


We imposed the additional restriction that all channels had to have at 
least one punch in them, to prevent run-away paper ejection.


Gerhard Postpischil
Bradford, Vermont

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

Re: COBOL "problem" (not really), but sort of.

[Farley, Peter x23353]

That will work, but I can't tell from John's original post if in his case the 
occurs-depending on AND the "record varying" data names are the same.  The fact 
that they are all the same in your example is what makes it work.

If all the "depending on" parts are the same name, your technique will 
certainly work, even if the "vlen-record" is in the LINKAGE section.  The key 
is to make all of them use the same name.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: Wednesday, September 11, 2013 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL "problem" (not really), but sort of.

I'm not sure if I'm understanding this 100% correctly, but take a look at this:

 identification division.
 program-id.  vlen.
 environment division.
 input-output section.
 file-control.
 select vlen-file
    assign to vlenfl.
 data division.
 file section.
 fd  vlen-file
 record varying depending on vlen-len.
 01  vlen-buffer.
 05  pic x occurs 1 to 252 depending on vlen-len.

 working-storage section.
 01  at-end-sw   pic x value 'N'.
 88  at-end    value 'Y'.
 01  vlen-record.
 05  vlen-len    pic 9(4) comp-5.
 05  vlen-data.
 10  pic x occurs 1 to 32760 depending on vlen-len.
 linkage section.
 procedure division.
 open input vlen-file
 perform until at-end
*    move zero to vlen-len
 read vlen-file into vlen-data
 at end set at-end to true
 not at end
 display vlen-len
 display vlen-data
 end-read
 end-perform
 close vlen-file
 goback.

It appears to me to work (even if the "move zero to vlen-len" statement is 
uncommented).  I believe that the key here is the "record varying depending on 
vlen-len".  I haven't looked at the generated code, but my guess is that this 
generates code that first moves the actual length red into vlen-len and then 
moves the data from the buffer into vlen-data, but only for a length of 
vlen-len.

Obviously in the case of the original example the vlen-record area is being 
passed in via the linkage section.  But that should not matter, as long as its 
big enough to hold the largest possible record size in the file.

Frank





>
> From: "Farley, Peter x23353" 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, September 11, 2013 2:11 PM
>Subject: Re: COBOL "problem" (not really), but sort of.
> 
>
>If I am not misremembering, Mr. Robert Heinlein's character Lazurus Long said: 
> "Ignorance is curable, only stupidity is fatal."
>
>Second, let's try one more time to penetrate the thick cranial boundary in 
>question (not yours):
>
>IF the FILE definition looks like this:
>
>FD  IN-FILE ...  .
>01  FILE-RECORD.
>    05  FILE-REC-LEN        PIC S9(5) COMP.
>    05  FILE-REC-DATA       OCCURS 1 TO 32760
>                            DEPENDING ON FILE-REC-LEN
>                            PIC X.
>
>And the working-storage area looks like this:
>
>01  WORK-RECORD.
>    05  WORK-REC-LEN        PIC S9(5) COMP.
>    05  WORK-REC-DATA       OCCURS 1 TO 32760
>                            DEPENDING ON FILE-REC-LEN
>                            PIC X.
>
>Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
>
>READ IN-FILE
>    AT END (do endfile processing)
>    NOT AT END
>        MOVE FILE-REC-LEN TO WORK-REC-LEN.
>        MOVE FILE-RECORD  TO WORK-RECORD.
>END-READ
>
>The reason that it does not work with READ INTO is that the 
>occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the 
>working-storage record area.  The MOVE is done at the 01 LEVEL, and in this 
>case the TO-occurs-depending-on-variable must be set BEFORE the MOVE begins.  
>READ does not do that for you; it never did and never will.
>
>You might ask him how he thinks the READ is supposed to knows what the correct 
>value for the OTHER occurs-depending-on-variable is supposed to be?  
>Especially if it is passed in as a LINKAGE SECTION item, the program 
>containing the READ CANNOT KNOW what that value is at the present time, NOR 
>what its current value is.  Rules of MOVE mean that the value must be set 
>BEFORE THE MOVE BEGINS.  READ does not and will not do it for you.
>
>If that doesn't make it all the way through the dense bony material with which 
>you are dealing, then I guess your answer is best: ignore the results.
>
>Good luck.
>
>Peter
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of John McKown
>Sent: Wednesday, September 11, 2013 2:27 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: COBOL "problem" (not really), but sort of.
>
>What you said was basically what I told the programmer to do. What he
>really wants is for the READ  INTO to do is to read in the record
>"somewhere" (i.e. the I/O buffer). The ODO value is within the record
>itself. So he 

Re: COBOL "problem" (not really), but sort of.

[Thomas Berg]

I thought the length field was in LINKAGE SECTION given by the caller ?



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 11, 2013 10:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL "problem" (not really), but sort of.
> 
> Well explained. I will keep this to show him when this next abends. It
> is a problem just waiting for a critical month end to come around.
> 
> 
> On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote:
> 
> > If I am not misremembering, Mr. Robert Heinlein's character Lazurus
> > Long
> > said:  "Ignorance is curable, only stupidity is fatal."
> >
> > Second, let's try one more time to penetrate the thick cranial
> > boundary in question (not yours):
> >
> > IF the FILE definition looks like this:
> >
> > FD  IN-FILE ...  .
> > 01  FILE-RECORD.
> > 05  FILE-REC-LENPIC S9(5) COMP.
> > 05  FILE-REC-DATA   OCCURS 1 TO 32760
> > DEPENDING ON FILE-REC-LEN
> > PIC X.
> >
> > And the working-storage area looks like this:
> >
> > 01  WORK-RECORD.
> > 05  WORK-REC-LENPIC S9(5) COMP.
> > 05  WORK-REC-DATA   OCCURS 1 TO 32760
> > DEPENDING ON FILE-REC-LEN
> > PIC X.
> >
> > Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
> >
> > READ IN-FILE
> > AT END (do endfile processing)
> > NOT AT END
> > MOVE FILE-REC-LEN TO WORK-REC-LEN.
> > MOVE FILE-RECORD  TO WORK-RECORD.
> > END-READ
> >
> > The reason that it does not work with READ INTO is that the
> > occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the
> > working-storage record area.  The MOVE is done at the 01 LEVEL, and in
> > this case the TO-occurs-depending-on-variable must be set BEFORE the
> > MOVE begins.  READ does not do that for you; it never did and never
> will.
> >
> > You might ask him how he thinks the READ is supposed to knows what the
> > correct value for the OTHER occurs-depending-on-variable is supposed
> to be?
> >  Especially if it is passed in as a LINKAGE SECTION item, the program
> > containing the READ CANNOT KNOW what that value is at the present
> > time, NOR what its current value is.  Rules of MOVE mean that the
> > value must be set BEFORE THE MOVE BEGINS.  READ does not and will not
> do it for you.
> >
> > If that doesn't make it all the way through the dense bony material
> > with which you are dealing, then I guess your answer is best: ignore
> the results.
> >
> > Good luck.
> >
> > Peter
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 2:27 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: COBOL "problem" (not really), but sort of.
> >
> > What you said was basically what I told the programmer to do. What he
> > really wants is for the READ  INTO to do is to read in the record
> > "somewhere" (i.e. the I/O buffer). The ODO value is within the record
> > itself. So he was wanting COBOL to effectively do a MOVE of the ODO
> > variable, then do the rest of the MOVE dependent on the just updated
> > value of the ODO variable. Like a "two stage" move. I told him that I
> > didn't think COBOL would do it that way, but he basically insisted
> > that it was what he wanted and was going to get or die (ABEND) trying.
> > I don't know why he doesn't just READ without the INTO and then MOVE
> > from the 01 in the FD to the 01 in the LINKAGE SECTION (sorry, said
> > WORKING STORAGE in previous posts). He just doesn't want to. I have
> > noted the program name and will just shrug if/when it starts abending
> in production (if it gets that far).
> >
> >
> > On Wed, Sep 11, 2013 at 1:13 PM, Joel C. Ewing 
> wrote:
> >
> > > On 09/11/2013 12:02 PM, John McKown wrote:
> > > > A programmer came by today with a problem. He is sometimes getting
> > > > a
> > > S0C4-4
> > > > abend in a COBOL program. This is a subroutine. One of the
> > > > parameters passed in is a data area, which can be of various
> > > > lengths. It is
> > defined
> > > > with an OCCURS DEPENDING ON with a data element within the area.
> I.e.
> > the
> > > > first 05 level is PIC S9(5) COMP. The subroutine does a READ of a
> > > > data
> > > set
> > > > into this area. This is where the abend occurs. The reason is
> > > > because
> > the
> > > > OCCURS DEPENDING ON maximum size is significantly larger than what
> > > > the caller is passing it. And the READ to the 01 is trying to pad
> > > > the
> > entire
> > > > possible 01 level with blanks.
> > > >
> > > > The problem is how do I describe this to 

Re: 1403 Printer components manual GA24-3073-3

[Paul Gilmartin]

On Wed, 11 Sep 2013 13:39:26 -0500, efinnell15 wrote:

>http://bitsavers.trailing-edge.com/pdf/ibm/140x/GA24-3073-8_1403_printer.pdf
>
>Found this on bitsavers. I remember the lid would come open when the paper ran 
>out, normally right after the shift supervisor put their beverage cup on it. 
>The ribbon stopped along with the paper when overprinting. If done with gusto, 
>
You mean, like, Snoopy Dog calendars, or the things operators printed off-shift?

>overprinting would saw the ribbon in two. 
>
WAD?  For shame!

>The paper tapes for forms control were like gold with special forms. In a 
>pinch could be duplicated with a hole punch and cellophane tape.
>
A CDC (IIRC) printer used conventional 8-channel Teletype tape.  Perhaps
not as durable, but more readily duplicated and replaced.

-- gil

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

Re: 1403 Printer components manual GA24-3073-3

[Tony Harminc]

On 11 September 2013 15:03, John McKown  wrote:
> Also, on DOS, I remember some sort of command the operator could issue to
> open it. I don't remember what the CCW was called, perhaps "open gate"?

The handy S/370 yellow card on my desk (the March 1974 version) shows
the 3211 having a "Raise Cover" CCW opcode 6B. This to some extent
confirms my memory that the 1403 raised its cover only under operator
command or running out of paper.

Tony H.

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

Re: COBOL "problem" (not really), but sort of.

[John McKown]

Well explained. I will keep this to show him when this next abends. It is a
problem just waiting for a critical month end to come around.


On Wed, Sep 11, 2013 at 3:11 PM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> If I am not misremembering, Mr. Robert Heinlein's character Lazurus Long
> said:  "Ignorance is curable, only stupidity is fatal."
>
> Second, let's try one more time to penetrate the thick cranial boundary in
> question (not yours):
>
> IF the FILE definition looks like this:
>
> FD  IN-FILE ...  .
> 01  FILE-RECORD.
> 05  FILE-REC-LENPIC S9(5) COMP.
> 05  FILE-REC-DATA   OCCURS 1 TO 32760
> DEPENDING ON FILE-REC-LEN
> PIC X.
>
> And the working-storage area looks like this:
>
> 01  WORK-RECORD.
> 05  WORK-REC-LENPIC S9(5) COMP.
> 05  WORK-REC-DATA   OCCURS 1 TO 32760
> DEPENDING ON FILE-REC-LEN
> PIC X.
>
> Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:
>
> READ IN-FILE
> AT END (do endfile processing)
> NOT AT END
> MOVE FILE-REC-LEN TO WORK-REC-LEN.
> MOVE FILE-RECORD  TO WORK-RECORD.
> END-READ
>
> The reason that it does not work with READ INTO is that the
> occurs-depending-on variable IS NOT YET KNOWN BEFORE THE READ for the
> working-storage record area.  The MOVE is done at the 01 LEVEL, and in this
> case the TO-occurs-depending-on-variable must be set BEFORE the MOVE
> begins.  READ does not do that for you; it never did and never will.
>
> You might ask him how he thinks the READ is supposed to knows what the
> correct value for the OTHER occurs-depending-on-variable is supposed to be?
>  Especially if it is passed in as a LINKAGE SECTION item, the program
> containing the READ CANNOT KNOW what that value is at the present time, NOR
> what its current value is.  Rules of MOVE mean that the value must be set
> BEFORE THE MOVE BEGINS.  READ does not and will not do it for you.
>
> If that doesn't make it all the way through the dense bony material with
> which you are dealing, then I guess your answer is best: ignore the results.
>
> Good luck.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 11, 2013 2:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL "problem" (not really), but sort of.
>
> What you said was basically what I told the programmer to do. What he
> really wants is for the READ  INTO to do is to read in the record
> "somewhere" (i.e. the I/O buffer). The ODO value is within the record
> itself. So he was wanting COBOL to effectively do a MOVE of the ODO
> variable, then do the rest of the MOVE dependent on the just updated value
> of the ODO variable. Like a "two stage" move. I told him that I didn't
> think COBOL would do it that way, but he basically insisted that it was
> what he wanted and was going to get or die (ABEND) trying. I don't know why
> he doesn't just READ without the INTO and then MOVE from the 01 in the FD
> to the 01 in the LINKAGE SECTION (sorry, said WORKING STORAGE in previous
> posts). He just doesn't want to. I have noted the program name and will
> just shrug if/when it starts abending in production (if it gets that far).
>
>
> On Wed, Sep 11, 2013 at 1:13 PM, Joel C. Ewing  wrote:
>
> > On 09/11/2013 12:02 PM, John McKown wrote:
> > > A programmer came by today with a problem. He is sometimes getting a
> > S0C4-4
> > > abend in a COBOL program. This is a subroutine. One of the parameters
> > > passed in is a data area, which can be of various lengths. It is
> defined
> > > with an OCCURS DEPENDING ON with a data element within the area. I.e.
> the
> > > first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data
> > set
> > > into this area. This is where the abend occurs. The reason is because
> the
> > > OCCURS DEPENDING ON maximum size is significantly larger than what the
> > > caller is passing it. And the READ to the 01 is trying to pad the
> entire
> > > possible 01 level with blanks.
> > >
> > > The problem is how do I describe this to a COBOL programmer who just
> > > doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> > > occurrences with blanks. And, if fact, to not even reference this area
> > > wherein they would have resided, had they existed. I'm just get "deer
> in
> > > headlights" looks. I'm not using the correct words, somehow.
> > >
> >
> > Presumably the "area" in question is the target of INTO as in "READ...
> > INTO area".
> >
> > The manuals say data movement for READ to the INTO "area" is governed by
> > the rules for "MOVE", and the semantics for MOVE says any length
> > evaluation of the receiving field is determined just "before" any data
> > is moved.  Is the DEPENDING ON variable in the receiving group item
> > initialized to  the proper expected v

Re: The Trainer's Friend Going Out Of Business Sale

[Steve Comstock]

Oooops. Sorry. Not meant for the list.

-Steve


On 9/11/2013 2:06 PM, Steve Comstock wrote:

On 9/11/2013 1:11 PM, Linda Mooney wrote:

Hi Steve,



I wish you only the best - and lots of it.



Sorry to hear that the business is closing.  38 years is a long run.  Hope we
will still see you on the list.



Thanks and Best Regards,

Linda


Thanks, Linda.

So, we got your order, but I'm confused because you entered
'this is request for quote only'. Since you did not need to
'Submit' to see the quote, I'm not clear on why you clicked
on 'Submit'.

What do you think? Do you want to purchase the batch of
courses listed?

Kind regards,

-Steve




- Original Message -


From: "Steve Comstock" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, September 9, 2013 5:19:34 AM
Subject: The Trainer's Friend Going Out Of Business Sale

After 38 years of creating and delivering training courses
for IBM mainframe (OS/360 through z/OS) application programmers,
The Trainer's Friend, Inc. is going out of business.

It's been a merry ride, giving us the chance to meet and work
with talented and dedicated people in hundreds of companies,
dozens of states, and ten foreign countries. Thanks to all
the people and companies we've worked with.

Although the company is shutting down on December 31 this
year, we are doing this in a structured way:

* Today we are kicking off a going out of business sale - we
are proud of the course materials we have developed and we
think companies can benefit by using these materials internally,
either for instructor led classes or for mentored self-study

We are offering all the courses developed by Steve Comstock
and Hunter Cobb at 90% off the list price, plus significant
additional discounts for volume purchases.

This sale includes all the courses I had in my earlier sale
*plus* our DB2, C/C++, PL/I and Debug Tool courses.


The sale will end on December 30, 2013.

Details are at:

   www.trainersfriend.com/SpecialSale


* From now to the end of the year, Hunter and I are still
available to teach under the auspices of The Trainer's Friend


* On January 1, 2014, The Trainer's Friend, Inc. will be
closed. It may be possible to contact Hunter or me
directly for teaching classes, but that will depend on
our personal schedules.



Thanks again for all the good times and your support over
the years.

Now get on over to www.trainersfriend.com/SpecialSale and
pick up your sets of training materials while you can.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752


P.S. I apologize if you get this announcement multiple times:
   I am sending it to all the mailing lists and individual
   email addresses I have, and some people are on many of
   the same lists.

--
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: The Trainer's Friend Going Out Of Business Sale

[Steve Comstock]

On 9/11/2013 1:11 PM, Linda Mooney wrote:

Hi Steve,



I wish you only the best - and lots of it.



Sorry to hear that the business is closing.  38 years is a long run.  Hope we 
will still see you on the list.



Thanks and Best Regards,

Linda


Thanks, Linda.

So, we got your order, but I'm confused because you entered
'this is request for quote only'. Since you did not need to
'Submit' to see the quote, I'm not clear on why you clicked
on 'Submit'.

What do you think? Do you want to purchase the batch of
courses listed?

Kind regards,

-Steve




- Original Message -


From: "Steve Comstock" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, September 9, 2013 5:19:34 AM
Subject: The Trainer's Friend Going Out Of Business Sale

After 38 years of creating and delivering training courses
for IBM mainframe (OS/360 through z/OS) application programmers,
The Trainer's Friend, Inc. is going out of business.

It's been a merry ride, giving us the chance to meet and work
with talented and dedicated people in hundreds of companies,
dozens of states, and ten foreign countries. Thanks to all
the people and companies we've worked with.

Although the company is shutting down on December 31 this
year, we are doing this in a structured way:

* Today we are kicking off a going out of business sale - we
are proud of the course materials we have developed and we
think companies can benefit by using these materials internally,
either for instructor led classes or for mentored self-study

We are offering all the courses developed by Steve Comstock
and Hunter Cobb at 90% off the list price, plus significant
additional discounts for volume purchases.

This sale includes all the courses I had in my earlier sale
*plus* our DB2, C/C++, PL/I and Debug Tool courses.


The sale will end on December 30, 2013.

Details are at:

   www.trainersfriend.com/SpecialSale


* From now to the end of the year, Hunter and I are still
available to teach under the auspices of The Trainer's Friend


* On January 1, 2014, The Trainer's Friend, Inc. will be
closed. It may be possible to contact Hunter or me
directly for teaching classes, but that will depend on
our personal schedules.



Thanks again for all the good times and your support over
the years.

Now get on over to www.trainersfriend.com/SpecialSale and
pick up your sets of training materials while you can.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752


P.S. I apologize if you get this announcement multiple times:
   I am sending it to all the mailing lists and individual
   email addresses I have, and some people are on many of
   the same lists.

--
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 "problem" (not really), but sort of.

[Farley, Peter x23353]

If I am not misremembering, Mr. Robert Heinlein's character Lazurus Long said:  
"Ignorance is curable, only stupidity is fatal."

Second, let's try one more time to penetrate the thick cranial boundary in 
question (not yours):

IF the FILE definition looks like this:

FD  IN-FILE ...  .
01  FILE-RECORD.
05  FILE-REC-LENPIC S9(5) COMP.
05  FILE-REC-DATA   OCCURS 1 TO 32760
DEPENDING ON FILE-REC-LEN
PIC X.

And the working-storage area looks like this:

01  WORK-RECORD.
05  WORK-REC-LENPIC S9(5) COMP.
05  WORK-REC-DATA   OCCURS 1 TO 32760
DEPENDING ON FILE-REC-LEN
PIC X.

Then the process will work BUT ONLY AS THREE SEPARATE STATEMENTS:

READ IN-FILE
AT END (do endfile processing)
NOT AT END
MOVE FILE-REC-LEN TO WORK-REC-LEN.
MOVE FILE-RECORD  TO WORK-RECORD.
END-READ

The reason that it does not work with READ INTO is that the occurs-depending-on 
variable IS NOT YET KNOWN BEFORE THE READ for the working-storage record area.  
The MOVE is done at the 01 LEVEL, and in this case the 
TO-occurs-depending-on-variable must be set BEFORE the MOVE begins.  READ does 
not do that for you; it never did and never will.

You might ask him how he thinks the READ is supposed to knows what the correct 
value for the OTHER occurs-depending-on-variable is supposed to be?  Especially 
if it is passed in as a LINKAGE SECTION item, the program containing the READ 
CANNOT KNOW what that value is at the present time, NOR what its current value 
is.  Rules of MOVE mean that the value must be set BEFORE THE MOVE BEGINS.  
READ does not and will not do it for you.

If that doesn't make it all the way through the dense bony material with which 
you are dealing, then I guess your answer is best: ignore the results.

Good luck.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, September 11, 2013 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL "problem" (not really), but sort of.

What you said was basically what I told the programmer to do. What he
really wants is for the READ  INTO to do is to read in the record
"somewhere" (i.e. the I/O buffer). The ODO value is within the record
itself. So he was wanting COBOL to effectively do a MOVE of the ODO
variable, then do the rest of the MOVE dependent on the just updated value
of the ODO variable. Like a "two stage" move. I told him that I didn't
think COBOL would do it that way, but he basically insisted that it was
what he wanted and was going to get or die (ABEND) trying. I don't know why
he doesn't just READ without the INTO and then MOVE from the 01 in the FD
to the 01 in the LINKAGE SECTION (sorry, said WORKING STORAGE in previous
posts). He just doesn't want to. I have noted the program name and will
just shrug if/when it starts abending in production (if it gets that far).


On Wed, Sep 11, 2013 at 1:13 PM, Joel C. Ewing  wrote:

> On 09/11/2013 12:02 PM, John McKown wrote:
> > A programmer came by today with a problem. He is sometimes getting a
> S0C4-4
> > abend in a COBOL program. This is a subroutine. One of the parameters
> > passed in is a data area, which can be of various lengths. It is defined
> > with an OCCURS DEPENDING ON with a data element within the area. I.e. the
> > first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data
> set
> > into this area. This is where the abend occurs. The reason is because the
> > OCCURS DEPENDING ON maximum size is significantly larger than what the
> > caller is passing it. And the READ to the 01 is trying to pad the entire
> > possible 01 level with blanks.
> >
> > The problem is how do I describe this to a COBOL programmer who just
> > doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> > occurrences with blanks. And, if fact, to not even reference this area
> > wherein they would have resided, had they existed. I'm just get "deer in
> > headlights" looks. I'm not using the correct words, somehow.
> >
>
> Presumably the "area" in question is the target of INTO as in "READ...
> INTO area".
>
> The manuals say data movement for READ to the INTO "area" is governed by
> the rules for "MOVE", and the semantics for MOVE says any length
> evaluation of the receiving field is determined just "before" any data
> is moved.  Is the DEPENDING ON variable in the receiving group item
> initialized to  the proper expected value or to the maximum acceptable
> value that the calling program can accept prior to the READ?
>
> The way I read the manuals, the implicit MOVE of the READ instruction
> will replace the DEPENDING ON value in the receiving structure, so
> afterwards it should reflect the actual number of occurrences present,
> but the length of the MOVE and any padding of the receiving field as
> part of that MOVE will be based o

Re: How to display JES2 fields from the PDDB

[Hansen, Dave L - Eagan, MN]

Ed,

   Thank you for the suggestion.  We do not have (E)JES, but I looked it up.


  Thanks again ,  Dave



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Wednesday, September 11, 2013 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to display JES2 fields from the PDDB

On 9/11/2013 9:01 AM, Hansen, Dave L - Eagan, MN wrote:
> Dear Group,
>
> I am debugging a JES2 EXIT40.  I was asked what do the fields PDBDNODE, 
> PDBDRMT and PDBUSER contain.  I am told PDBDRMT may not contain a non-zero 
> value.  There is no command which will give me this information.  I am told I 
> can set a slip trap on entry to the exit and take a dump at that point.
>
> Q).  Is there a good book on taking a dump from an Exit?  Does anyone have an 
> example of a slip trap to help me debug our PDDB (REG 2 is $PDDB, offset 
> x'14' for 12 bytes is the routing info)?

If you are an (E)JES customer, you can issue the DU (dump) line command against 
the job to browse a comprehensive dump of all its SPOOL-resident control 
blocks. The part you are interested in looks like this:

*
* I O T  (ALLOCATION)
*

  SPOOL ADDRESS: 02.023C55

  COMMON SECTION:

    0068  C9D6E340 E2D4C6C4 E4D4D740 0002AFB6   *IOT SMFDUMP ..®¶*
  0010  0078  CBF2AA52  1800 02023C55 *ô2¡ê...í*
  0020  0088      **
  0030  0098  0145 66BC 0002  *...á..ï*
  0040  00A8   1000 0280  *...Ø*
  0050  00B8      **
  ===> Data at relative offset 00C8 through 00D7 is same as above <===

  TGAE SECTION:

  0070    0223 C500   *E...*
  0080  0010      **
  ===> Data at relative offset 0020 through 013F is same as above <===

  PDDB ENTRY:

  01B0    68800050 02023C53  0001 *ÇØ.&...ë*
  01C0  0010  0180E201    *.ØS.*
  01D0  0020  0800 0002  007E *...=*
  01E0  0030  E2E3C440 40404040 5C5C5C5C 5C5C5C5C   *STD *
  01F0  0040  40404040 40404040     * *
  0200  0050  5C5C5C5C 5C5C5C5C 5C5C5C5C 5C5C5C5C **
  0210  0060  5C5C5C5C 5C5C5C5C FF00  **
  0220  0070   0800   **
  0230  0080   CBF2AA52   *ô2¡ê*
  0240  0090     40404040   * *
  0250  00A0  40404040 40404040 40404040 D1C5E2D1   * JESJ*
  0260  00B0  C3D3C9D5 40404040 40404040 5001A051   *CLIN &.µé*
  0270  00C0  1555   829DB29D *íí.íb¸¥¸*
  0280  00D0  8DA71515 B7819315 15151515 829DB29D *ýx..¼al.b¸¥¸*
  0290  00E0  8DA71515   B7B6969C *ýx..¼¶oæ*
  02A0  00F0  808C918C   B7819315 *Øðjð¼al.*
  02B0  0100  15151515 B7BDB7A4 15151515 E2D4C640   *¼]¼uSMF *
  02C0  0110  40404040   8000   * ..Ø.*
  02D0  0120  00020402    **
  02E0  0130      **
  02F0  0140  0200    **
  0300  0150   E2D4C64B E2D4C6C4 E4D4D74B *SMF.SMFDUMP.*
  0310  0160  E2F0F1F7 F6F0F5F4 4BC4F0F0 F0F0F0F0 *S0176054.D00*
  0320  0170  F14BD1C5 E2D1C3D3 C9D54040 40404040   *1.JESJCLIN *

etc...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.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: PDS/E, Shared Dasd, and COBOL V5

[Mark Zelden]

On Wed, 11 Sep 2013 19:08:19 +, Gibney, Dave  wrote:

>> 
>> Neither.  zFS can safely be shared R/O outside sysplex / GRS
>> boundaries.   BTW, with PDSESHARING(NORMAL), PDSE can   
>> be shared R/W outside the sysplex, but the boundaries must still
>> be within the GRSplex.   However, they can't be shared R/W between  
>> systems managed by MII (MIM) because the ENQs issued for
>> SYSZIGW0 and SYSZIGW1 are issued with RNL=NO.  IIRC, this   
>> wasn't always the case and IBM "broke this" for CA MIM  
>> customers around DFSMS/MVS 1.5.  Thank you IBM. 
>> 
>> Regards,
   
   
>I usually don't disagree with Mark, but my experience is that without the XCF 
>communication Barbara mentioned (i.e. inside a sysplex), updating a PDS/E 
>from one LPAR can cause abends of address spaces in another LPAR that are 
>actively using the PDS/E. 
 >Specifically, when VPS from LRS shipped with all PDS/E including the CNTL
>libraries, I abended my production VPS by modifying shared printer
>definitions from the development LPAR.  


XCF is not involved when PDSE is using PDSESHARING(NORMAL).Were
you using PDSESHARING(EXTENDED)?  WAS PDSESHARING(NORMAL) 
in effect on BOTH systems involved?   Were your 2 systems involved
in the same GRS ring?   With PDSESHARING(NORMAL) you would not
have even been able to update a member on one system if the other
system had the PDSE opened for update.  The sharing is on a data set
level, not on a member level (sharing at the member level on the
same system does work).  

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/

   


 

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

Re: 1403 Printer components manual GA24-3073-3

[John McKown]

Also, on DOS, I remember some sort of command the operator could issue to
open it. I don't remember what the CCW was called, perhaps "open gate"?


On Wed, Sep 11, 2013 at 1:39 PM, efinnell15  wrote:

>
> http://bitsavers.trailing-edge.com/pdf/ibm/140x/GA24-3073-8_1403_printer.pdf
>
> Found this on bitsavers. I remember the lid would come open when the paper
> ran out, normally right after the shift supervisor put their beverage cup
> on it. The ribbon stopped along with the paper when overprinting. If done
> with gusto, overprinting would saw the ribbon in two. The paper tapes for
> forms control were like gold with special forms. In a pinch could be
> duplicated with a hole punch and cellophane tape.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

Re: COBOL "problem" (not really), but sort of.

[Jon Perryman]

How about not making this about padding. My guess would be that cobol clears 
the storage before the read instead of padding storage after the read. I would 
telling the programmer:

Before a READ INTO, the storage is cleared with nulls. The size of the area to 
be cleared is set by his program in the 01 section (not by the program that 
called his program). 

Jon Perryman.


- Original Message -
> From: John McKown 
> 
> The problem is how do I describe this to a COBOL programmer who just
> doesn't "get it". He expects COBOL to _not_ pad the "non 
> existent"
> occurrences with blanks. 

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

Re: NTP server with System z for PCI-DSS compliance

[Paul Gilmartin]

On Wed, 11 Sep 2013 12:12:14 -0500, John McKown wrote:

>The "problem" is that z/OS _cannot_ allow the TOD clock (hardware clock) to
>go "backwards". The way that STP addresses this is that the STP software
>can "speed up" or "slow down" the TOD increment pulse (or whatever it's
>called). This is the hardware portion of STP. And I think that hardware
>addition is a major portion of the cost of getting STP.
> 
Aren't the facilities of STP and all its "speed up" and "slow down" registers
and the instructions to manipulate them described in the P[rO]ps?  Or
does this presume the customer has paid for (enabling) the hardware?
(I'm cynical enough to assume it's there anyway; you just need to pay for
the key.)

Suppose a customer has a z running nothing but Linux in LPARs?  How
does its time get set?  I understand that in the day Linux (also VM)
was ETR-ignorant.

>If your application software can be written to use the z/OS software (TIME
>macro et al.) timing interfaces, getting the _local_ time, then it is
>possible to have a NTP "steer" this by adjusting the GMT to local offset
>value in the CVT. This is basically doing a periodic SET CLOCK=hh.mm.ss
>type command. I assume everybody can understand the problem because there
>would now be no way to actually relate the TOD clock values to the current
>"software clock" values.
> 
Yuck!  If I were doing this, I'd "steer" CVTLSO (isn't its range sufficient?)
rather than CVTLDTO.  At least that would get GMT correct also.  Even
with the best facilities provided by IBM, STCKCONV gives results in error
by the value of CVTLSO at the time of the STCK.  (I'm guessing; IBM
refuses to document the behavior, claiming it's "common knowledge".)

-- gil

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Zelden
> Sent: Wednesday, September 11, 2013 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E, Shared Dasd, and COBOL V5
> 
> On Wed, 11 Sep 2013 07:57:47 -0400, Shmuel Metz (Seymour J.)
>  wrote:
> 
> >In <0DE6A9840123E547B061AC5B6765C026BD08EB@EXMB-
> 05.ad.wsu.edu>, on
> >09/10/2013
> >   at 02:44 AM, "Gibney, Dave"  said:
> >
> >>Yes, PDS/E shared outside of Sysplex is a problem if the sharing is
> >>not close to strictly read only. Specifically, address spaces with the
> >>PDS/E open in LPAR A will not like it after you update the PDS/E from
> >>LPAR B
> >
> >The same applies to two z/OS guests in the same LPAR but not the same
> >sysplex.
> >
> >Also, aren't there sharing issues even for R/O Or am I thinking of zFS?
> >
> 
> Neither.  zFS can safely be shared R/O outside sysplex / GRS
> boundaries.   BTW, with PDSESHARING(NORMAL), PDSE can
> be shared R/W outside the sysplex, but the boundaries must still
> be within the GRSplex.   However, they can't be shared R/W between
> systems managed by MII (MIM) because the ENQs issued for
> SYSZIGW0 and SYSZIGW1 are issued with RNL=NO.  IIRC, this
> wasn't always the case and IBM "broke this" for CA MIM
> customers around DFSMS/MVS 1.5.  Thank you IBM.
> 
> Regards,

 I usually don't disagree with Mark, but my experience is that without the XCF 
communication Barbara mentioned (i.e. inside a sysplex), updating a PDS/E from 
one LPAR can cause abends of address spaces in another LPAR that are actively 
using the PDS/E.
 Specifically, when VPS from LRS shipped with all PDS/E including the CNTL 
libraries, I abended my production VPS by modifying shared printer definitions 
from the development LPAR.

> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> ITIL v3 Foundation Certified
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
> --
> 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: The Trainer's Friend Going Out Of Business Sale

[Linda Mooney]

Hi Steve, 



I wish you only the best - and lots of it.  



Sorry to hear that the business is closing.  38 years is a long run.  Hope we 
will still see you on the list. 



Thanks and Best Regards, 

Linda 

- Original Message -


From: "Steve Comstock"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, September 9, 2013 5:19:34 AM 
Subject: The Trainer's Friend Going Out Of Business Sale 

After 38 years of creating and delivering training courses 
for IBM mainframe (OS/360 through z/OS) application programmers, 
The Trainer's Friend, Inc. is going out of business. 

It's been a merry ride, giving us the chance to meet and work 
with talented and dedicated people in hundreds of companies, 
dozens of states, and ten foreign countries. Thanks to all 
the people and companies we've worked with. 

Although the company is shutting down on December 31 this 
year, we are doing this in a structured way: 

* Today we are kicking off a going out of business sale - we 
   are proud of the course materials we have developed and we 
   think companies can benefit by using these materials internally, 
   either for instructor led classes or for mentored self-study 

   We are offering all the courses developed by Steve Comstock 
   and Hunter Cobb at 90% off the list price, plus significant 
   additional discounts for volume purchases. 

   This sale includes all the courses I had in my earlier sale 
   *plus* our DB2, C/C++, PL/I and Debug Tool courses. 


   The sale will end on December 30, 2013. 

   Details are at: 

      www.trainersfriend.com/SpecialSale 


* From now to the end of the year, Hunter and I are still 
   available to teach under the auspices of The Trainer's Friend 


* On January 1, 2014, The Trainer's Friend, Inc. will be 
   closed. It may be possible to contact Hunter or me 
   directly for teaching classes, but that will depend on 
   our personal schedules. 



Thanks again for all the good times and your support over 
the years. 

Now get on over to www.trainersfriend.com/SpecialSale and 
pick up your sets of training materials while you can. 


Kind regards, 

-Steve Comstock 
The Trainer's Friend, Inc. 
303-355-2752 


P.S. I apologize if you get this announcement multiple times: 
      I am sending it to all the mailing lists and individual 
      email addresses I have, and some people are on many of 
      the same lists. 

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

1403 Printer components manual GA24-3073-3

[efinnell15]

http://bitsavers.trailing-edge.com/pdf/ibm/140x/GA24-3073-8_1403_printer.pdf

Found this on bitsavers. I remember the lid would come open when the paper ran 
out, normally right after the shift supervisor put their beverage cup on it. 
The ribbon stopped along with the paper when overprinting. If done with gusto, 
overprinting would saw the ribbon in two. The paper tapes for forms control 
were like gold with special forms. In a pinch could be duplicated with a hole 
punch and cellophane tape.

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

Re: IEE313I when varying a console online

[Bill Bishop (TEMA TPC)]

Do you have the /con entry in the parameters section of the 2074 definitions 
for the terminal being used as a console?

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development & Support
Toyota Motor Engineering & Manufacturing North America, Inc.
bill.bis...@tema.toyota.com
(502) 570-6143

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Wednesday, September 11, 2013 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Hi

The answer is yes to both questions.
I can very it online, but I cannot vary console.
The output from D U is O or OFFLINE.
Is is defined in the consolexx member.

Gadi



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
John McKown [john.archie.mck...@gmail.com]
Sent: 11 September 2013 18:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Is the address specified exist in the I/O configuration? D U,,,,1 gives 
back valid information. If so, what is it's status? It needs to be OFFLINE 
before it can be varied as a CONSOLE. And it needs to be specified in the 
CONSOLxx member which was specified at IPL time.


On Wed, Sep 11, 2013 at 10:35 AM, גדי בן אבי  wrote:

> Hi,
>
> I am in the process of installing a 2074 for a client. I know it's 
> ancient, and unsupported, but everything this client has is ancient 
> and unsupported.
>
> I managed to get a working console session on the 2074.
> When I try to configure PCOM, I get the 2074 index message.
>
> When I try to vary the device (V xxx,console) i get:
> IEE313I UNIT REF. INVALID.
>
> What can the reason for this be?
> How do I fix it.
>
> The machine is a 2074 model 3
> The computer is a 9672-R14
> OS is OS/390 v2.8.
>
> Thanks
>
>
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או 
> מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, 
> הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך 
> כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום 
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no 
> offer, agreement, concession or representation is binding on the 
> company, unless accompanied by a duly signed separate document (or a 
> scanned version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the company's seal.

--
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: IEE313I when varying a console online

[גדי בן אבי]

Hi

The answer is yes to both questions.
I can very it online, but I cannot vary console.
The output from D U is O or OFFLINE.
Is is defined in the consolexx member.

Gadi



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
John McKown [john.archie.mck...@gmail.com]
Sent: 11 September 2013 18:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Is the address specified exist in the I/O configuration? D U,,,,1 gives
back valid information. If so, what is it's status? It needs to be OFFLINE
before it can be varied as a CONSOLE. And it needs to be specified in the
CONSOLxx member which was specified at IPL time.


On Wed, Sep 11, 2013 at 10:35 AM, גדי בן אבי  wrote:

> Hi,
>
> I am in the process of installing a 2074 for a client. I know it's
> ancient, and unsupported, but everything this client has is ancient and
> unsupported.
>
> I managed to get a working console session on the 2074.
> When I try to configure PCOM, I get the 2074 index message.
>
> When I try to vary the device (V xxx,console) i get:
> IEE313I UNIT REF. INVALID.
>
> What can the reason for this be?
> How do I fix it.
>
> The machine is a 2074 model 3
> The computer is a 9672-R14
> OS is OS/390 v2.8.
>
> Thanks
>
>
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג
> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את
> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון,
> ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no offer,
> agreement, concession or representation is binding on the company,
> unless accompanied by a duly signed separate document (or a scanned
> version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: COBOL "problem" (not really), but sort of.

[John McKown]

What you said was basically what I told the programmer to do. What he
really wants is for the READ  INTO to do is to read in the record
"somewhere" (i.e. the I/O buffer). The ODO value is within the record
itself. So he was wanting COBOL to effectively do a MOVE of the ODO
variable, then do the rest of the MOVE dependent on the just updated value
of the ODO variable. Like a "two stage" move. I told him that I didn't
think COBOL would do it that way, but he basically insisted that it was
what he wanted and was going to get or die (ABEND) trying. I don't know why
he doesn't just READ without the INTO and then MOVE from the 01 in the FD
to the 01 in the LINKAGE SECTION (sorry, said WORKING STORAGE in previous
posts). He just doesn't want to. I have noted the program name and will
just shrug if/when it starts abending in production (if it gets that far).


On Wed, Sep 11, 2013 at 1:13 PM, Joel C. Ewing  wrote:

> On 09/11/2013 12:02 PM, John McKown wrote:
> > A programmer came by today with a problem. He is sometimes getting a
> S0C4-4
> > abend in a COBOL program. This is a subroutine. One of the parameters
> > passed in is a data area, which can be of various lengths. It is defined
> > with an OCCURS DEPENDING ON with a data element within the area. I.e. the
> > first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data
> set
> > into this area. This is where the abend occurs. The reason is because the
> > OCCURS DEPENDING ON maximum size is significantly larger than what the
> > caller is passing it. And the READ to the 01 is trying to pad the entire
> > possible 01 level with blanks.
> >
> > The problem is how do I describe this to a COBOL programmer who just
> > doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> > occurrences with blanks. And, if fact, to not even reference this area
> > wherein they would have resided, had they existed. I'm just get "deer in
> > headlights" looks. I'm not using the correct words, somehow.
> >
>
> Presumably the "area" in question is the target of INTO as in "READ...
> INTO area".
>
> The manuals say data movement for READ to the INTO "area" is governed by
> the rules for "MOVE", and the semantics for MOVE says any length
> evaluation of the receiving field is determined just "before" any data
> is moved.  Is the DEPENDING ON variable in the receiving group item
> initialized to  the proper expected value or to the maximum acceptable
> value that the calling program can accept prior to the READ?
>
> The way I read the manuals, the implicit MOVE of the READ instruction
> will replace the DEPENDING ON value in the receiving structure, so
> afterwards it should reflect the actual number of occurrences present,
> but the length of the MOVE and any padding of the receiving field as
> part of that MOVE will be based on contents of the receiving field's
> DEPENDING ON variable prior to the move.
>
> If the programmer is expecting COBOL to *assume* that the length of the
> receiving field is the length of the source field (in this case, the
> record just read), the manuals seem to explicitly indicate that is not
> the way things work.
>
> If my understanding is correct, a more efficient way to avoid
> unnecessary padding would be to do a READ without "INTO", then set the
> DEPENDING ON value in the receiving area to minimum of max count space
> supplied by caller and the DEPENDING ON value in the actual record read,
> and finally MOVE the file record to the receiving area.
>
> --
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Mark Zelden]

>> From: IBM Mainframe Discussion List  mailto:IBM-MAIN@LISTSERV.UA.EDU  On 
>> 
>> Behalf Of Mark Zelden
>> 
>> Sent: Wednesday, September 11, 2013 6:24 PM  
>> 
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> 
>> Subject: Re: PDS/E, Shared Dasd, and COBOL V5
>> 
>>  
>> 
>> On Wed, 11 Sep 2013 16:46:49 +0200, Thomas Berg  
>> 
>>  wrote: 
>> 
>>  
>> 
>> >Have you any experience about performance differences to vanilla PDS.   
>> >
>> >E g in IMS TP ? 
>> >
>>  
>> 
>> No.  Performance is most likely better than it was (although I never 
>> 
>> measured it before and after way back then) and my client doesn't have   
>> 
>> the "huge" number of members / directories that have been known to cause 
>> 
>> performance issues and are addressed by PDSE V2 in z/OS 2.1. 
>> 


>Thanks!  BTW, with "huge", are we talking about >> 1 members ? 

Generally,  yes - because of the way things are split between different major
applications. I looked and saw one loadlib with about 20,000 members,
but most are under 5K.  

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/


   



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

Re: IEE313I when varying a console online

[Alan Field]

Have you IPL'd the system since it was added to the CONSOLxx member?

There is no way (until z/OS 2.1) to dynamically add a console. 

Alan Field
Technical Engineer Principal
BCBS Minnesota

Phone: 651.662.3546  Mobile:  651.428.8826





From:   "גדי בן אבי" 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/11/2013 12:51
Subject:Re: IEE313I when varying a console online
Sent by:IBM Mainframe Discussion List 



Hi

The answer is yes to both questions.
I can very it online, but I cannot vary console.
The output from D U is O or OFFLINE.
Is is defined in the consolexx member.

Gadi



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown [john.archie.mck...@gmail.com]
Sent: 11 September 2013 18:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Is the address specified exist in the I/O configuration? D U,,,,1 
gives
back valid information. If so, what is it's status? It needs to be OFFLINE
before it can be varied as a CONSOLE. And it needs to be specified in the
CONSOLxx member which was specified at IPL time.


On Wed, Sep 11, 2013 at 10:35 AM, גדי בן אבי  wrote:

> Hi,
>
> I am in the process of installing a 2074 for a client. I know it's
> ancient, and unsupported, but everything this client has is ancient and
> unsupported.
>
> I managed to get a working console session on the 2074.
> When I try to configure PCOM, I get the 2074 index message.
>
> When I try to vary the device (V xxx,console) i get:
> IEE313I UNIT REF. INVALID.
>
> What can the reason for this be?
> How do I fix it.
>
> The machine is a 2074 model 3
> The computer is a 9672-R14
> OS is OS/390 v2.8.
>
> Thanks
>
>
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג
> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא 
את
> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות 
מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון,
> ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no offer,
> agreement, concession or representation is binding on the company,
> unless accompanied by a duly signed separate document (or a scanned
> version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג 
מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את 
לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך 
סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום 
טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned 
version thereof), affixed with the company's seal.

--
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 "problem" (not really), but sort of.

[Joel C. Ewing]

On 09/11/2013 12:02 PM, John McKown wrote:
> A programmer came by today with a problem. He is sometimes getting a S0C4-4
> abend in a COBOL program. This is a subroutine. One of the parameters
> passed in is a data area, which can be of various lengths. It is defined
> with an OCCURS DEPENDING ON with a data element within the area. I.e. the
> first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data set
> into this area. This is where the abend occurs. The reason is because the
> OCCURS DEPENDING ON maximum size is significantly larger than what the
> caller is passing it. And the READ to the 01 is trying to pad the entire
> possible 01 level with blanks.
> 
> The problem is how do I describe this to a COBOL programmer who just
> doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> occurrences with blanks. And, if fact, to not even reference this area
> wherein they would have resided, had they existed. I'm just get "deer in
> headlights" looks. I'm not using the correct words, somehow.
> 

Presumably the "area" in question is the target of INTO as in "READ...
INTO area".

The manuals say data movement for READ to the INTO "area" is governed by
the rules for "MOVE", and the semantics for MOVE says any length
evaluation of the receiving field is determined just "before" any data
is moved.  Is the DEPENDING ON variable in the receiving group item
initialized to  the proper expected value or to the maximum acceptable
value that the calling program can accept prior to the READ?

The way I read the manuals, the implicit MOVE of the READ instruction
will replace the DEPENDING ON value in the receiving structure, so
afterwards it should reflect the actual number of occurrences present,
but the length of the MOVE and any padding of the receiving field as
part of that MOVE will be based on contents of the receiving field's
DEPENDING ON variable prior to the move.

If the programmer is expecting COBOL to *assume* that the length of the
receiving field is the length of the source field (in this case, the
record just read), the manuals seem to explicitly indicate that is not
the way things work.

If my understanding is correct, a more efficient way to avoid
unnecessary padding would be to do a READ without "INTO", then set the
DEPENDING ON value in the receiving area to minimum of max count space
supplied by caller and the DEPENDING ON value in the actual record read,
and finally MOVE the file record to the receiving area.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: COBOL "problem" (not really), but sort of.

[Frank Swarbrick]

Are you able to post a code snippet of what the code is actually doing?  Others 
seem to understand from your description what is occurring, but I understand 
code better.

Frank



>
> From: John McKown 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, September 11, 2013 11:02 AM
>Subject: COBOL "problem" (not really), but sort of.
> 
>
>A programmer came by today with a problem. He is sometimes getting a S0C4-4
>abend in a COBOL program. This is a subroutine. One of the parameters
>passed in is a data area, which can be of various lengths. It is defined
>with an OCCURS DEPENDING ON with a data element within the area. I.e. the
>first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data set
>into this area. This is where the abend occurs. The reason is because the
>OCCURS DEPENDING ON maximum size is significantly larger than what the
>caller is passing it. And the READ to the 01 is trying to pad the entire
>possible 01 level with blanks.
>
>The problem is how do I describe this to a COBOL programmer who just
>doesn't "get it". He expects COBOL to _not_ pad the "non existent"
>occurrences with blanks. And, if fact, to not even reference this area
>wherein they would have resided, had they existed. I'm just get "deer in
>headlights" looks. I'm not using the correct words, somehow.
>
>-- 
>As of next week, passwords will be entered in Morse code.
>
>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: COBOL "problem" (not really), but sort of.

[Thomas Berg]

I would say: the READ .. INTO .. statement doesn't look at the numerical value 
in the length field, it only looks at the max possible length as defined. And 
acts accordingly. 



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, September 11, 2013 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: COBOL "problem" (not really), but sort of.
> 
> A programmer came by today with a problem. He is sometimes getting a
> S0C4-4 abend in a COBOL program. This is a subroutine. One of the
> parameters passed in is a data area, which can be of various lengths. It
> is defined with an OCCURS DEPENDING ON with a data element within the
> area. I.e. the first 05 level is PIC S9(5) COMP. The subroutine does a
> READ of a data set into this area. This is where the abend occurs. The
> reason is because the OCCURS DEPENDING ON maximum size is significantly
> larger than what the caller is passing it. And the READ to the 01 is
> trying to pad the entire possible 01 level with blanks.
> 
> The problem is how do I describe this to a COBOL programmer who just
> doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> occurrences with blanks. And, if fact, to not even reference this area
> wherein they would have resided, had they existed. I'm just get "deer in
> headlights" looks. I'm not using the correct words, somehow.
> 
> --
> As of next week, passwords will be entered in Morse code.
> 
> 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: NTP server with System z for PCI-DSS compliance

[R.S.]

W dniu 2013-09-11 11:17, Timothy Sipples pisze:

Radoslaw Skorupka writes:

Although PCI-DSS does not mention explicitly NTP, but this is the only
solution for mainframe, which in turn requires STP enablement, which
means $$$, which is quite unique among other platforms, because others
can act as NTP client for free.

No, you cannot assume that.

Yes I can, unless you present other existing option.


[...] It depends on the definitions of words like "protected,"
"correct," "consistent," and "trusted." "Free" NTP might not be any/most of
those things, particularly in certain non-mainframe virtualized
environments.
There are free time sources which can be considered as consistent and 
tursted - like German goverment-supported time (FM signal), polish GUM 
servers (official "measurement" authoririty - they provide official 
standards for kg, second, meter, etc.) or just GPS. I can prove it in 
any court.



By the way, I'm rather tired of the implicit and explicit criticisms that
Server Time Protocol (STP) has a separate charge.

So get rest.

So it does. So what?

Maybe some holidays?


If you need STP, include its cost in your budgeting, negotiate, and/or make
whatever decisions you want to make, [...]
WRONG. I don't need STP. Vast majority of shops I know do not need STP 
(no sysplex there). However majority of them would be happy to have NTP. 
And ANY OTHER SYSTEM OR PLATFORM CAN BE NTP CLIENT FOR FREE.

That's why people repeat: "MAINFRAME IS EXPENSIVE". "MAINFRAME IS COMPLEX".
It is expensive to pay few dozens k$ for NTP. Note in the times of 
Sysplex Timer it was 2x50k = 100k$  (2x - for redundancy).
It is quite complex to set up the NTP, although it's not rocket science. 
It generates a lot of HW messages, which cannot be supressed even if you 
don't care about it (stratum change for any of NTP servers).
I'm rather tired of the continuous signals and proofs why the mainframe 
is expensive and complex and fading away.



--
Radoslaw Skorupka
Lodz, Poland






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

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


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

COBOL "problem" (not really), but sort of.

[John McKown]

A programmer came by today with a problem. He is sometimes getting a S0C4-4
abend in a COBOL program. This is a subroutine. One of the parameters
passed in is a data area, which can be of various lengths. It is defined
with an OCCURS DEPENDING ON with a data element within the area. I.e. the
first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data set
into this area. This is where the abend occurs. The reason is because the
OCCURS DEPENDING ON maximum size is significantly larger than what the
caller is passing it. And the READ to the 01 is trying to pad the entire
possible 01 level with blanks.

The problem is how do I describe this to a COBOL programmer who just
doesn't "get it". He expects COBOL to _not_ pad the "non existent"
occurrences with blanks. And, if fact, to not even reference this area
wherein they would have resided, had they existed. I'm just get "deer in
headlights" looks. I'm not using the correct words, somehow.

-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

Re: COBOL "problem" (not really), but sort of.

[Farley, Peter x23353]

READ xxx INTO yyy is COBOL shorthand for READ xxx followed by MOVE 
xxx-record-area to yyy.

COBOL MOVE's (even implied moves) are *supposed* to respect the value of the 
OCCURS DEPENDING ON variable value, so this *should* work with no programmer 
intervention, but I haven't actually done exactly this so I am not positive.

To be "safe", I would tell the programmer to set up a record-length variable 
for the COBOL FILE (so that after any READ he knows the exact length of the 
record that was read) and then use  SEPARATE READ and MOVE statements that look 
like this:

READ xxx
AT END (do endfile processing)
NOT AT END MOVE xxx-record-area (1 : record-length-variable) TO yyy (1 
: occurs-depending-on-variable)
END-READ

That will move the shorter of the two lengths into the yyy variable, up to but 
not past the value of the occurs-depending-on-variable.

Record length variables for varying-length files are set in the RECORD clause 
of the FILE SECTION FD file entry (RECORD VARYING DEPENDING ON 
record-length-variable).

There is no way in COBOL to set up a record-length-variable in the FILE SECTION 
for a fixed-length file.  For a fixed-length file, just set up a 
WORKING-STORAGE record-length-variable binary VALUE actual-fixed-record-length.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, September 11, 2013 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL "problem" (not really), but sort of.

A programmer came by today with a problem. He is sometimes getting a S0C4-4
abend in a COBOL program. This is a subroutine. One of the parameters
passed in is a data area, which can be of various lengths. It is defined
with an OCCURS DEPENDING ON with a data element within the area. I.e. the
first 05 level is PIC S9(5) COMP. The subroutine does a READ of a data set
into this area. This is where the abend occurs. The reason is because the
OCCURS DEPENDING ON maximum size is significantly larger than what the
caller is passing it. And the READ to the 01 is trying to pad the entire
possible 01 level with blanks.

The problem is how do I describe this to a COBOL programmer who just
doesn't "get it". He expects COBOL to _not_ pad the "non existent"
occurrences with blanks. And, if fact, to not even reference this area
wherein they would have resided, had they existed. I'm just get "deer in
headlights" looks. I'm not using the correct words, somehow.

-- 

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

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Thomas Berg]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Zelden
> Sent: Wednesday, September 11, 2013 6:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E, Shared Dasd, and COBOL V5
> 
> On Wed, 11 Sep 2013 16:46:49 +0200, Thomas Berg
>  wrote:
> 
> >Have you any experience about performance differences to vanilla PDS.
> >E g in IMS TP ?
> 
> No.  Performance is most likely better than it was (although I never
> measured it before and after way back then) and my client doesn't have
> the "huge" number of members / directories that have been known to cause
> performance issues and are addressed by PDSE V2 in z/OS 2.1.

Thanks!  BTW, with "huge", are we talking about >> 1 members ?



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)




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

Re: COBOL "problem" (not really), but sort of.

[John McKown]

I can try that. The programmer says that he intents to define the passed in
area in the calling program at the front of his WORKING-STORAGE so that the
area is larger. I.e. it is _planning_ on a buffer overflow and _hoping_
that it doesn't affect the calling program. I don't have authority to
disallow this. And we don't do any kind of peer review because we just
don't have the people left.


On Wed, Sep 11, 2013 at 12:09 PM, Thomas Berg wrote:

> I would say: the READ .. INTO .. statement doesn't look at the numerical
> value in the length field, it only looks at the max possible length as
> defined. And acts accordingly.
>
>
>
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of John McKown
> > Sent: Wednesday, September 11, 2013 7:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: COBOL "problem" (not really), but sort of.
> >
> > A programmer came by today with a problem. He is sometimes getting a
> > S0C4-4 abend in a COBOL program. This is a subroutine. One of the
> > parameters passed in is a data area, which can be of various lengths. It
> > is defined with an OCCURS DEPENDING ON with a data element within the
> > area. I.e. the first 05 level is PIC S9(5) COMP. The subroutine does a
> > READ of a data set into this area. This is where the abend occurs. The
> > reason is because the OCCURS DEPENDING ON maximum size is significantly
> > larger than what the caller is passing it. And the READ to the 01 is
> > trying to pad the entire possible 01 level with blanks.
> >
> > The problem is how do I describe this to a COBOL programmer who just
> > doesn't "get it". He expects COBOL to _not_ pad the "non existent"
> > occurrences with blanks. And, if fact, to not even reference this area
> > wherein they would have resided, had they existed. I'm just get "deer in
> > headlights" looks. I'm not using the correct words, somehow.
> >
> > --
> > As of next week, passwords will be entered in Morse code.
> >
> > 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
>



-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

Re: NTP server with System z for PCI-DSS compliance

[John McKown]

The "problem" is that z/OS _cannot_ allow the TOD clock (hardware clock) to
go "backwards". The way that STP addresses this is that the STP software
can "speed up" or "slow down" the TOD increment pulse (or whatever it's
called). This is the hardware portion of STP. And I think that hardware
addition is a major portion of the cost of getting STP.

If your application software can be written to use the z/OS software (TIME
macro et al.) timing interfaces, getting the _local_ time, then it is
possible to have a NTP "steer" this by adjusting the GMT to local offset
value in the CVT. This is basically doing a periodic SET CLOCK=hh.mm.ss
type command. I assume everybody can understand the problem because there
would now be no way to actually relate the TOD clock values to the current
"software clock" values.


On Wed, Sep 11, 2013 at 11:42 AM, R.S. wrote:

> W dniu 2013-09-11 11:17, Timothy Sipples pisze:
>
>> Radoslaw Skorupka writes:
>>
>>> Although PCI-DSS does not mention explicitly NTP, but this is the only
>>> solution for mainframe, which in turn requires STP enablement, which
>>> means $$$, which is quite unique among other platforms, because others
>>> can act as NTP client for free.
>>>
>> No, you cannot assume that.
>>
> Yes I can, unless you present other existing option.
>
>  [...] It depends on the definitions of words like "protected,"
>> "correct," "consistent," and "trusted." "Free" NTP might not be any/most
>> of
>> those things, particularly in certain non-mainframe virtualized
>> environments.
>>
> There are free time sources which can be considered as consistent and
> tursted - like German goverment-supported time (FM signal), polish GUM
> servers (official "measurement" authoririty - they provide official
> standards for kg, second, meter, etc.) or just GPS. I can prove it in any
> court.
>
>  By the way, I'm rather tired of the implicit and explicit criticisms that
>> Server Time Protocol (STP) has a separate charge.
>>
> So get rest.
>
>> So it does. So what?
>>
> Maybe some holidays?
>
>  If you need STP, include its cost in your budgeting, negotiate, and/or
>> make
>> whatever decisions you want to make, [...]
>>
> WRONG. I don't need STP. Vast majority of shops I know do not need STP (no
> sysplex there). However majority of them would be happy to have NTP. And
> ANY OTHER SYSTEM OR PLATFORM CAN BE NTP CLIENT FOR FREE.
> That's why people repeat: "MAINFRAME IS EXPENSIVE". "MAINFRAME IS COMPLEX".
> It is expensive to pay few dozens k$ for NTP. Note in the times of Sysplex
> Timer it was 2x50k = 100k$  (2x - for redundancy).
> It is quite complex to set up the NTP, although it's not rocket science.
> It generates a lot of HW messages, which cannot be supressed even if you
> don't care about it (stratum change for any of NTP servers).
> I'm rather tired of the continuous signals and proofs why the mainframe is
> expensive and complex and fading away.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
>  jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie jeste
>  adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie  01.01.2013 r. kapita  zak adowy BRE
> Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych.
>
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the mes

How to display JES2 fields from the PDDB

[Hansen, Dave L - Eagan, MN]

Dear Group,

   I am debugging a JES2 EXIT40.  I was asked what do the fields PDBDNODE, 
PDBDRMT and PDBUSER contain.  I am told PDBDRMT may not contain a non-zero 
value.  There is no command which will give me this information.  I am told I 
can set a slip trap on entry to the exit and take a dump at that point.

Q).  Is there a good book on taking a dump from an Exit?  Does anyone have an 
example of a slip trap to help me debug our PDDB (REG 2 is $PDDB, offset x'14' 
for 12 bytes is the routing info)?


   Thank you,  Dave

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

Re: FW: JES2 "Node" Question

[Ron Wells]

sounds like you have a destid parm in jes2parm...

ck your def's---both locations...you have any other exits inplace that 
mess with remote/dest id's??



From:   "Hansen, Dave L - Eagan, MN" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   09/11/2013 10:50 AM
Subject:FW: JES2 "Node" Question
Sent by:IBM Mainframe Discussion List 



I request for knowledge.

CROSS POSTED to JES2 and IBM.

From: Hansen, Dave L - Eagan, MN
Sent: Wednesday, September 11, 2013 10:45 AM
To: 'jes...@listserv.vt.edu'; 'i...@listserv.uark.edu'
Subject: JES2 "Node" Question

Dear Group,

   I have been working with IBM to Implement a JES2 EXIT 40.  I am doing 
this without too much JES knowledge.  I was asked to move output from one 
MVS spool to another.  We had a product (VPS) that would take the print 
off the MVS spool and send it to remote printers.  Now we don't run that 
software at our "west side" location.  I just want to change N1.U1234 to 
N2.U1234.  Then JES will ROUTE the output from N1 to N2.  However the 
change results in N1.U1234 being modified to N2.R1234.  I did some testing 
and things are not as I expected.

Q).  On the SDSF screen - With the EXIT in place, Why doesn't Node reflect 
my change to N2?  RMT is now 1234.  NODE is supposed to be the "JES Print 
Node".  I would expect the node to be the destination node.



   From SDSF I entered NODE.  It see N2, MN1 and OWNNODE.  So we are #2 
aka MN1.

Q).  Is there an advantage to using "N2" over "MN1"?  The terminology gets 
confusing.



I tried this just to confuse myself:
I ran three jobs to print output, but I put them on HOLD.  My OUTPUTS 
were:
   DEFAULT=Y,DEST=N4.U9889DP,CLASS=H
   DEFAULT=Y,DEST=N2.U9889DP,CLASS=H   *** OWNNODE ***
   DEFAULT=Y,DEST=N12.U9889DP,CLASS=H
I looked at SDSF "O" and saw:  RMT is Blank and NODE is "2" for all three. 
 DEST is LOCAL .  The output for N2.U9889DP has an extra piece with DEST 
U9889DP (The actual payload to print).

Q).  Why doesn't "4" or "12" show up under NODE?  I used "N4" and "N12".



  Perhaps we have something in JES setup to change something to "R"?  We 
are testing this on two separate JES2 systems.  They may not be the same, 
and I sure don't know what is "normal".   On one system I see SDSF output 
with RMT as 7298, NODE as BLANK, and DEST as U7298.

Q).  Why would this job have a BLANK NODE?  The systems are different and 
I bet the jobs we ran were different also.  I guess it all "depends".  I'm 
just not sure what it all depends on.



   The reason I ask is my assembler job is looking to match $OWNNODE to 
PDBDNODE.  I took out that line because I have no idea what these NODEs 
should be.  Right now I just change PDBDNODE regardless of what it was.



   Please send help,  Dave

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: DFSMShsm and backing up ZFS files

[Paul Gilmartin]

On Wed, 11 Sep 2013 07:24:23 -0700, Lizette Koehler wrote:
>
>z/OS V1R11.0 UNIX System Services Planning z/OS V1R11.0  GA22-7800-17
>
>Unlike other non-VSAM data sets that can be opened and closed repeatedly
>throughout the day, some file systems are often mounted for several days or
>weeks at a time, with the individual file members inside opened as needed.
>Normally, DFSMShsm's automatic backup (AUTOBACKUP) processes file systems at
>most once per mount, so a file system mounted for a week would only have one
>backup taken for that week. For some applications, that might not be
>frequent enough. Fortunately, DFSMShsmT provides some alternatives to ensure
>that backups are taken more frequently.
> 
One must beware of the terminology.  "mount" to UNIX means "OPEN"
to z/OS, I believe.  Read carefully.

But if one syncs the UNIX filesystem (does OMVS support sync?), takes
a flash copy of the container, and backs up from that, is integrity
guaranteed at least for UNIX files that were not open during the process?

UNIX users who plan to keep files open and writeable long-term might
well be counseled to take their own backups to .tar.Z files (Even to
Classic data sets) at times not conflicting with DASD backups.

Should simlar considerations apply to PDSEs which are chronically OPEN
(although more rarely updated than zFS).

-- gil

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

Re: FW: JES2 "Node" Question

[Ron Wells]

understand VPS---like many software packages...getting to $$$
we switched to JQP...did same thing...much cheaper.sna and ip 
supported...



From:   "Hansen, Dave L - Eagan, MN" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   09/11/2013 10:50 AM
Subject:FW: JES2 "Node" Question
Sent by:IBM Mainframe Discussion List 



I request for knowledge.

CROSS POSTED to JES2 and IBM.

From: Hansen, Dave L - Eagan, MN
Sent: Wednesday, September 11, 2013 10:45 AM
To: 'jes...@listserv.vt.edu'; 'i...@listserv.uark.edu'
Subject: JES2 "Node" Question

Dear Group,

   I have been working with IBM to Implement a JES2 EXIT 40.  I am doing 
this without too much JES knowledge.  I was asked to move output from one 
MVS spool to another.  We had a product (VPS) that would take the print 
off the MVS spool and send it to remote printers.  Now we don't run that 
software at our "west side" location.  I just want to change N1.U1234 to 
N2.U1234.  Then JES will ROUTE the output from N1 to N2.  However the 
change results in N1.U1234 being modified to N2.R1234.  I did some testing 
and things are not as I expected.

Q).  On the SDSF screen - With the EXIT in place, Why doesn't Node reflect 
my change to N2?  RMT is now 1234.  NODE is supposed to be the "JES Print 
Node".  I would expect the node to be the destination node.



   From SDSF I entered NODE.  It see N2, MN1 and OWNNODE.  So we are #2 
aka MN1.

Q).  Is there an advantage to using "N2" over "MN1"?  The terminology gets 
confusing.



I tried this just to confuse myself:
I ran three jobs to print output, but I put them on HOLD.  My OUTPUTS 
were:
   DEFAULT=Y,DEST=N4.U9889DP,CLASS=H
   DEFAULT=Y,DEST=N2.U9889DP,CLASS=H   *** OWNNODE ***
   DEFAULT=Y,DEST=N12.U9889DP,CLASS=H
I looked at SDSF "O" and saw:  RMT is Blank and NODE is "2" for all three. 
 DEST is LOCAL .  The output for N2.U9889DP has an extra piece with DEST 
U9889DP (The actual payload to print).

Q).  Why doesn't "4" or "12" show up under NODE?  I used "N4" and "N12".



  Perhaps we have something in JES setup to change something to "R"?  We 
are testing this on two separate JES2 systems.  They may not be the same, 
and I sure don't know what is "normal".   On one system I see SDSF output 
with RMT as 7298, NODE as BLANK, and DEST as U7298.

Q).  Why would this job have a BLANK NODE?  The systems are different and 
I bet the jobs we ran were different also.  I guess it all "depends".  I'm 
just not sure what it all depends on.



   The reason I ask is my assembler job is looking to match $OWNNODE to 
PDBDNODE.  I took out that line because I have no idea what these NODEs 
should be.  Right now I just change PDBDNODE regardless of what it was.



   Please send help,  Dave

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: FW: JES2 "Node" Question

[Ron Wells]

if your objective is to transfer sysout from one node to another
and the other node is defined todaythen transfer to other node s/b 
just a matter of putting that node and go

I do this between my test /prod and devl lpars... prod/devl share a 
spool...the test is seperate


 


From:   "Hansen, Dave L - Eagan, MN" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   09/11/2013 10:50 AM
Subject:FW: JES2 "Node" Question
Sent by:IBM Mainframe Discussion List 



I request for knowledge.

CROSS POSTED to JES2 and IBM.

From: Hansen, Dave L - Eagan, MN
Sent: Wednesday, September 11, 2013 10:45 AM
To: 'jes...@listserv.vt.edu'; 'i...@listserv.uark.edu'
Subject: JES2 "Node" Question

Dear Group,

   I have been working with IBM to Implement a JES2 EXIT 40.  I am doing 
this without too much JES knowledge.  I was asked to move output from one 
MVS spool to another.  We had a product (VPS) that would take the print 
off the MVS spool and send it to remote printers.  Now we don't run that 
software at our "west side" location.  I just want to change N1.U1234 to 
N2.U1234.  Then JES will ROUTE the output from N1 to N2.  However the 
change results in N1.U1234 being modified to N2.R1234.  I did some testing 
and things are not as I expected.

Q).  On the SDSF screen - With the EXIT in place, Why doesn't Node reflect 
my change to N2?  RMT is now 1234.  NODE is supposed to be the "JES Print 
Node".  I would expect the node to be the destination node.



   From SDSF I entered NODE.  It see N2, MN1 and OWNNODE.  So we are #2 
aka MN1.

Q).  Is there an advantage to using "N2" over "MN1"?  The terminology gets 
confusing.



I tried this just to confuse myself:
I ran three jobs to print output, but I put them on HOLD.  My OUTPUTS 
were:
   DEFAULT=Y,DEST=N4.U9889DP,CLASS=H
   DEFAULT=Y,DEST=N2.U9889DP,CLASS=H   *** OWNNODE ***
   DEFAULT=Y,DEST=N12.U9889DP,CLASS=H
I looked at SDSF "O" and saw:  RMT is Blank and NODE is "2" for all three. 
 DEST is LOCAL .  The output for N2.U9889DP has an extra piece with DEST 
U9889DP (The actual payload to print).

Q).  Why doesn't "4" or "12" show up under NODE?  I used "N4" and "N12".



  Perhaps we have something in JES setup to change something to "R"?  We 
are testing this on two separate JES2 systems.  They may not be the same, 
and I sure don't know what is "normal".   On one system I see SDSF output 
with RMT as 7298, NODE as BLANK, and DEST as U7298.

Q).  Why would this job have a BLANK NODE?  The systems are different and 
I bet the jobs we ran were different also.  I guess it all "depends".  I'm 
just not sure what it all depends on.



   The reason I ask is my assembler job is looking to match $OWNNODE to 
PDBDNODE.  I took out that line because I have no idea what these NODEs 
should be.  Right now I just change PDBDNODE regardless of what it was.



   Please send help,  Dave

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: Teletypewriter Model 33

[Paul Gilmartin]

On Wed, 11 Sep 2013 09:03:18 -0400, Shmuel Metz (Seymour J.) wrote:

> on 09/09/2013  at 09:32 PM, Paul Gilmartin said:
>
>> Why does DSN(*) exist at all? 
>
>To accomodate batch applications under TSO.
>
>>What you suggest is more like batch than interactive.
>
>EDIT is like batch? In what way?
>
>>It was a program which issued prompts to DD SYSTERM
>
>I don't know what "it" is, but EDIT did *NOT* issue prompts to DD
>SYSTERM. EDIT used standard TSO services for terminal I/O.
> 
Sometimes it appears that you deliberately over-prune quoted
material so you can refute something the previous poster
never said.  "It" was my program (or the user's), not EDIT.
And editing a file to supply as input to a program rather than
replying to prompts with a terminal makes the operation of that
program more batch-like than interactive, regardless that the
editor operated interactively.


On Wed, 11 Sep 2013 09:12:41 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>But how much IBM software in 1978 actually exploited it?
>
>Batch or interactive? IBM interactive software exploited lower case
>long before the date you asked about.
> 
The appropriate metaphor is that OS/360 et seq. support lower case
in about the same sense that the noose supports the hanged man.

>>TTY 33 ASR
>
>Did the 33 even support lower case? What did you see with, e.g., a
>2741?
>
33 by folding; I was never afflicted with a 2741.

>>Later, using CDC Kronos,
>
>Display code didn't have lower case. I believe that with NOS and
>NOS/BE CDC switched to ASCII, which did have LC.
>
In it later days, Kronos provided lower case as digraphs in Display
Code.  Cumbersome, but so is UTF-8 in similar respects.

-- gil

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

Re: IEE313I when varying a console online

[John McKown]

Is the address specified exist in the I/O configuration? D U,,,,1 gives
back valid information. If so, what is it's status? It needs to be OFFLINE
before it can be varied as a CONSOLE. And it needs to be specified in the
CONSOLxx member which was specified at IPL time.


On Wed, Sep 11, 2013 at 10:35 AM, גדי בן אבי  wrote:

> Hi,
>
> I am in the process of installing a 2074 for a client. I know it's
> ancient, and unsupported, but everything this client has is ancient and
> unsupported.
>
> I managed to get a working console session on the 2074.
> When I try to configure PCOM, I get the 2074 index message.
>
> When I try to vary the device (V xxx,console) i get:
> IEE313I UNIT REF. INVALID.
>
> What can the reason for this be?
> How do I fix it.
>
> The machine is a 2074 model 3
> The computer is a 9672-R14
> OS is OS/390 v2.8.
>
> Thanks
>
>
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג
> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את
> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון,
> ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no offer,
> agreement, concession or representation is binding on the company,
> unless accompanied by a duly signed separate document (or a scanned
> version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
As of next week, passwords will be entered in Morse code.

Maranatha! <><
John McKown

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Mark Zelden]

On Wed, 11 Sep 2013 16:46:49 +0200, Thomas Berg  wrote:

>Have you any experience about performance differences to vanilla PDS.  
>E g in IMS TP ? 
 
No.  Performance is most likely better than it was (although I never measured
it before and after way back then) and my client doesn't have the "huge" number 
of
members / directories that have been known to cause performance issues
and are addressed by PDSE V2 in z/OS 2.1.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEE313I when varying a console online

[Alan Field]

Is device xxx defined in the IOCDS. Is xxx defined in the CONSOLxx member.


- Original Message -
From: "גדי בן אבי" [gad...@malam.com]
Sent: 09/11/2013 06:35 PM ZE3
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEE313I when varying a console online



Hi,

I am in the process of installing a 2074 for a client. I know it's ancient, and 
unsupported, but everything this client has is ancient and unsupported.

I managed to get a working console session on the 2074.
When I try to configure PCOM, I get the 2074 index message.

When I try to vary the device (V xxx,console) i get:
IEE313I UNIT REF. INVALID.

What can the reason for this be?
How do I fix it.

The machine is a 2074 model 3
The computer is a 9672-R14
OS is OS/390 v2.8.

Thanks




לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

IEE313I when varying a console online

[גדי בן אבי]

Hi,

I am in the process of installing a 2074 for a client. I know it's ancient, and 
unsupported, but everything this client has is ancient and unsupported.

I managed to get a working console session on the 2074.
When I try to configure PCOM, I get the 2074 index message.

When I try to vary the device (V xxx,console) i get:
IEE313I UNIT REF. INVALID.

What can the reason for this be?
How do I fix it.

The machine is a 2074 model 3
The computer is a 9672-R14
OS is OS/390 v2.8.

Thanks




לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: DFSMShsm and backing up ZFS files

[Miklos Szigetvari]

Hi Jonathan

I have no experience with DFSMShsm, but we are using ADRDSSU to backup our
ZFS files, and during the backup there is a quiesce.
Our long running USS processes are  complaining as they have no access 
during this quiesce period.

So seems to me not the DFSMShsm but the data mover
makes the quiesce


On 11.09.2013 16:30, Jonathan Miller wrote:

Lizette,

Yes I saw that article.
If I read it correctly DFSMShsm should backup the ZFS files by doing a
quiesce.
Our files do not have a backup at all.   Is this because they are mounted
and
AUTOBACKUP can't get the quiesce possibly.
I am doing some more digging on my end to see what's up.
Is there anyone out there who is using DFSMShsm to backup there ZFS unix
files and it works with multiple copies after a dataset is changed?

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for the 
above addressees only.  If you
receive this message in error please delete or destroy this message and/or 
attachments.

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging
in the unauthorized use of this message.

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





--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research&  Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.szigetv...@isis-papyrus.com
Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---

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

z/OS, z/VM , z/VSE Training and number of delegates

[Terry Sambrooks]

Hi

The recent comments in the Trainer's Friend closure posting about courses
not being run because of too few delegates is interesting.

I know of one training provider who does runs courses for as few as 1
delegate. (It is always hoped that more delegates would sign up before the
actual course runs, but the provide advertises that a public course is not
cancelled if it has only one delegate.)

I continue to support this provider in my capacity as an itinerant
instructor.

That said I acknowledge that there are issues. The above is not viable if
there is an insistence on classroom delivery and either party has to travel
a great distance. Applications such as GoToMyMeeting and WebEx do help
eliminate the physical travel but do not completely negate the cost.
Obviously use of electronic delivery in any form also requires discipline on
the part of all the attendees and a commitment to the process and this may
sometimes be lacking.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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

Re: DFSMShsm and backing up ZFS files

[Jonathan Miller]

If I do the HBACKDS it works and that is through HSM.
So the autobackup should also work in theory.

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for the 
above addressees only.  If you 
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging 
in the unauthorized use of this message.

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

Re: SSI update

[Jon Perryman]

I'm also confused by your question. What makes you ask this question? What did 
you read or hear about that made you ask this question? Are you talking about 
the "subsystem interface" or is SSI in reference to something else?

Any time a program moves information to storage, it is overlaying storage. It's 
only a bad thing when it overlays the wrong storage. We use the term "storage 
overlay" to mean overlaying the wrong storage. Assembler macro IEFSSI and MVS 
command SETSSI add/update the SSCT which overlays information in an SSCT or the 
SSCT chain. If your program overlays the wrong storage, then it can cause 
abends.

Great care must be taken in programs that run from the SSI. The SSI runs all 
the time and in all address spaces. If something bad happens, you could be 
IPL'ing your system. 

Jon Perryman.. 




>
> From: mf db 

>Yes, My question can it cause any abend by overlaying storage ?
>
>On Wed, Sep 11, 2013 at 2:43 PM, Lizette Koehler 
>wrote:
>> Are you asking can it cause an abend by overlaying storage?
>>
>> -Original Message-
>>From: mf db 
>>
>> I am trying to understand if Dynamic SSI update can overlay the storage.
>> Could someone please shed some light on dynamic SSI update.

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

Re: Teletypewriter Model 33

[Anne & Lynn Wheeler]

l...@garlic.com (Anne & Lynn Wheeler) writes:
> How ASCII Came About
> http://www.bobbemer.com/ASCII.HTM
> HOW ASCII GOT ITS BACKSLASH
> http://www.bobbemer.com/BACSLASH.HTM

re:
http://www.garlic.com/~lynn/2013l.html#33  Teletypewriter Model 33

for other drift

Bob's history index
http://www.bobbemer.com/HISTORY.HTM

list this under "Stories in Waiting"

The Impact of Printers upon charter sets
http://www.bobbemer.com/BC.HTM

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: DFSMShsm and backing up ZFS files

[Jonathan Miller]

Lizette,

I do not have the zfs files in a SG with GBF.
I may have to do that to get this to work or just setup 
a DFDSS batch job and let it back them up.

thanks for all the responses, I'll pursue what Lizette recommended and see
if that helps.



Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for the 
above addressees only.  If you 
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging 
in the unauthorized use of this message.

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

Re: DFSMShsm and backing up ZFS files

[Jousma, David]

As someone else mentioned, what happens when you do a manual HBACK command on 
one of those ZFS filesystems?

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jonathan Miller
Sent: Wednesday, September 11, 2013 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSMShsm and backing up ZFS files

Lizette,

Yes I saw that article.
If I read it correctly DFSMShsm should backup the ZFS files by doing a quiesce.
Our files do not have a backup at all.   Is this because they are mounted 
and
AUTOBACKUP can't get the quiesce possibly.
I am doing some more digging on my end to see what's up.
Is there anyone out there who is using DFSMShsm to backup there ZFS unix files 
and it works with multiple copies after a dataset is changed?

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for the 
above addressees only.  If you receive this message in error please delete or 
destroy this message and/or attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging in the unauthorized use of this message.

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

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

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

Re: DFSMShsm and backing up ZFS files

[Lizette Koehler]

Jonathan,

To make sure I understand.

You have a storage group with GBF and the zFS files are in that Storage
Group?

When you do an (H)BACKDS or UNMOUNT/MOUNT there are no backups of that zFS
file?

If the file is mounted READ/WRITE the backup is occurring where that zFS
file is mounted?

Please note, in the article it states the zFS files are not backed up based
on change but based on TIME; unless I am misunderstanding the text.

Unlike other non-VSAM data sets that can be opened and closed repeatedly
throughout the day, some file systems are often mounted for several days or
weeks at a time, with the individual file members inside opened as needed.
Normally, DFSMShsm's automatic backup (AUTOBACKUP) processes file systems at
most once per mount, so a file system mounted for a week would only have one
backup taken for that week.

So unless you are always unmounting/mounting the zFS files, you need to
either use GPF in your Storage Group for the volumes that have zFS files.
Or create a process that issues manual (H)BACKDS more frequently.


After this, you may need to open an SR/ETR with IBM HSM to determine what is
not quite right with your setup

Lizette



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jonathan Miller
Sent: Wednesday, September 11, 2013 7:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSMShsm and backing up ZFS files

Lizette,

Yes I saw that article.
If I read it correctly DFSMShsm should backup the ZFS files by doing a
quiesce.
Our files do not have a backup at all.   Is this because they are mounted 
and
AUTOBACKUP can't get the quiesce possibly.
I am doing some more digging on my end to see what's up.
Is there anyone out there who is using DFSMShsm to backup there ZFS unix
files and it works with multiple copies after a dataset is changed?

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Thomas Berg]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Zelden
> Sent: Wednesday, September 11, 2013 3:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E, Shared Dasd, and COBOL V5
> 
> For what it's worth, my client has been using PDSE for all their
> production loadlibs, source libraries, proclibs, etc. (managed by
> Endevor) since sometime just after
> Y2K.   The initial reason I pushed for it was occasional JES2 PROC
> issues after weekly
> compress jobs would run.
> 
> The only problem I recall in all these years was related to "illegal"
> sharing between a prod / devl sysplex (via MIM) of a prod CICS loadlib
> that someone included in a devl region shortly after we starting using
> PDSEs for the Endevor controlled
> prod/qa/devl/test environments.   Because PDSEs had to be SMS controlled
> ("going back to some ancient OS/390 release" as Ed said in a recent
> post) and those sysplexes have different SMS pools and the DASD volumes
> are not online to the other plex, no other mistakes have ever happened.
> Actually, I'm a bit surprised myself after all these years that there
> hasn't been a problem
> every now and then due to sharing PDSE outside sysplex boundaries.

Have you any experience about performance differences to vanilla PDS. 
E g in IMS TP ?



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)

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

Re: DFSMShsm and backing up ZFS files

[Jonathan Miller]

Lizette,

Yes I saw that article.
If I read it correctly DFSMShsm should backup the ZFS files by doing a 
quiesce.
Our files do not have a backup at all.   Is this because they are mounted 
and
AUTOBACKUP can't get the quiesce possibly.
I am doing some more digging on my end to see what's up.
Is there anyone out there who is using DFSMShsm to backup there ZFS unix 
files and it works with multiple copies after a dataset is changed?

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for the 
above addressees only.  If you 
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging 
in the unauthorized use of this message.

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

Re: Teletypewriter Model 33

[Shmuel Metz (Seymour J.)]

In , on 09/10/2013
   at 02:29 AM, efinnell15  said:

>There was a 'Universal Train'. I don't remember the number. 

Probably UN on the 1403 and U11 on the 3211.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Teletypewriter Model 33

[Shmuel Metz (Seymour J.)]

In <029201ceae5d$2b0a7420$811f5c60$@mxg.com>, on 09/10/2013
   at 02:37 PM, Barry Merrill  said:

>I vaguely recall benchmarking the print time of several Print Trains
>in the early 70s, and my memory of specifics was weak, but I know I
>identified three or four specific IDs that were 2 to 3 times longer
>and I'm pretty sure they all had mixed case,

SN and TN would have been the slowest, then PN and QN, withn AN and HN
the fastest.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Teletypewriter Model 33

[Shmuel Metz (Seymour J.)]

In <6865411767021646.wa.paulgboulderaim@listserv.ua.edu>, on
09/10/2013
   at 01:00 AM, Paul Gilmartin  said:

>But how much IBM software in 1978 actually exploited it? 

Batch or interactive? IBM interactive software exploited lower case
long before the date you asked about.

>TTY 33 ASR

Did the 33 even support lower case? What did you see with, e.g., a
2741?

>Later, using CDC Kronos, 

Display code didn't have lower case. I believe that with NOS and
NOS/BE CDC switched to ASCII, which did have LC.

>and then IBM MVS, I wondered, why couldn't they do likewise: let 
>the output device fold if it chooses to; otherwise let it display 
>mixed case.

Then you were asking for an explanation of something that wasn't true.
All the way back to OS/360, TSO supported mixed case.

Now, if you had asked why IBM didn't impose a corporate standard that
all programs use mixed case in their column headers, that would have
been a reasonable question.


-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Teletypewriter Model 33

[Shmuel Metz (Seymour J.)]

In <1628372020520296.wa.paulgboulderaim@listserv.ua.edu>, on
09/09/2013
   at 09:32 PM, Paul Gilmartin  said:

> Why does DSN(*) exist at all? 

To accomodate batch applications under TSO.

>What you suggest is more like batch than interactive.

EDIT is like batch? In what way?

>It was a program which issued prompts to DD SYSTERM

I don't know what "it" is, but EDIT did *NOT* issue prompts to DD
SYSTERM. EDIT used standard TSO services for terminal I/O.

>Why isn't there an ASIS option on ALLOCATE?

Because you didn't submit a requirement with a compelling business
case. It's been several decades, so I doubt that it's that important
to you.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Teletypewriter Model 33

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2013l.html#20 Teletypewriter Model 33
http://www.garlic.com/~lynn/2013l.html#21 Teletypewriter Model 33
http://www.garlic.com/~lynn/2013l.html#22 Teletypewriter Model 33
http://www.garlic.com/~lynn/2013l.html#23 Teletypewriter Model 33
http://www.garlic.com/~lynn/2013l.html#24 Teletypewriter Model 33
http://www.garlic.com/~lynn/2013l.html#25 Teletypewriter Model 33

translate tables were needed for terminals. 2741 & 1052 weren't actually
"ebcdic" ... their code was tilt/rotate bits for the "golf" ball
... translate tables were needed to translate between ebcdic and
tilt/rotate codes. different typeballs could require different
tilt/rotate codes ... for instance apl typeball ... i've uploaded
couple images of 2741 typeball
http://www.garlic.com/~lynn/aplball.jpg
http://www.garlic.com/~lynn/aplball2.jpg

i previously mentioned the clone controller project getting temporarily
messed up because of ibm controller linescanner convention of leading
bit into low-order position resulting in bit-reversed bytes. ... TTY
used ascii (as opposed to 2741&1052 being typeball control codes).

somewhat related is ascii history (ibm 360 mainframe originally was
supposed to be ASCII machine)

EBCDIC and the P-BIT (The Biggest Computer Goof Ever)
http://www.bobbemer.com/P-BIT.HTM

Who Goofed?

The culprit was T. Vincent Learson. The only thing for his defense is
that he had no idea of what he had done. It was when he was an IBM Vice
President, prior to tenure as Chairman of the Board, those lofty
positions where you believe that, if you order it done, it actually will
be done. I've mentioned this fiasco elsewhere.

... snip ...

more ASCII history

How ASCII Came About
http://www.bobbemer.com/ASCII.HTM
HOW ASCII GOT ITS BACKSLASH
http://www.bobbemer.com/BACSLASH.HTM

other recent posts mentioning 360 "goof":
http://www.garlic.com/~lynn/2013.html#56 New HD
http://www.garlic.com/~lynn/2013b.html#72 One reason for monocase was Re: 
Dualcase vs monocase. Was: Article for the boss
http://www.garlic.com/~lynn/2013c.html#14 What Makes an Architecture Bizarre?
http://www.garlic.com/~lynn/2013e.html#61 32760?
http://www.garlic.com/~lynn/2013i.html#3 Ported Tools - Unix
http://www.garlic.com/~lynn/2013i.html#49 Internet Mainframe Forums Considered 
Harmful

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: SSI update

[Shmuel Metz (Seymour J.)]

In
,
on 09/11/2013
   at 01:02 PM, mf db  said:

>I am trying to understand if Dynamic SSI update can overlay the
>storage.

If you provide your own subsystem, it can overlay storage; it doesn't
matter whether you specify it in IEFSSNxx or in IEFSSI. Unless there
is a bug in it, IEFSSI doesn't overlay any storage that it shouldn't,
and a bug in your code is far more likely than a bug in something so
small and so heavily used.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: DFSMShsm and backing up ZFS files

[Lizette Koehler]

Jonathan,

Did you see this entry in the Unix Manual?

DFSMShsm

z/OS V1R11.0 UNIX System Services Planning z/OS V1R11.0  GA22-7800-17

Unlike other non-VSAM data sets that can be opened and closed repeatedly
throughout the day, some file systems are often mounted for several days or
weeks at a time, with the individual file members inside opened as needed.
Normally, DFSMShsm's automatic backup (AUTOBACKUP) processes file systems at
most once per mount, so a file system mounted for a week would only have one
backup taken for that week. For some applications, that might not be
frequent enough. Fortunately, DFSMShsmT provides some alternatives to ensure
that backups are taken more frequently.

An SMS-managed storage group can be defined with guaranteed backup
frequency (GBF). For example, if GBF=3 days, then if a backup has not been
taken for a particular data set in the last three days, a fresh backup is
taken, whether the file has been updated or not. Since this applies to all
data sets on a storage group, some customers have placed their file systems
into a unique storage group with a specification of GBF=1, so as not to
affect other types of data.

Backups once a day might not be frequent enough. DFSMShsm provides
commands to invoke backups to be taken, independent of the standard
autobackup cycle and window. The BACKVOL TOTAL command can be used to back
up all the files on a single DASD volume, a list of DASD volumes, a single
storage group, or a list of storage groups. This command can be invoked from
a job scheduling package such as OPC, or console automation package, such as
Netview.

If file systems are intermixed on the DASD volumes with other data set
types, you might want to back up the file systems individually. You can use
the DFSMShsm command BACKDS to back up a single data set, or a set of data
sets that match a particular mask filter. The DFSMShsm batch program
ARCINBAK can be used to back up a list of data sets that support JCL
backward reference and variable substitution. DFSMShsm also provides
ABACKUP, which identifies which file systems are part of a single aggregate
list, and backs these up as a single entity. You can invoke both the BACKDS
and ABACKUP commands from job scheduling or console automation software.

If the application was developed in-house, you can modify it to perform
the backups internally. It might be able to perform its own quiesce process,
or coordinate time stamps with its own transactional log. DFSMShsm provides
the ARCHBACK assembler macro interface.

If a file system is mounted for read/write to a single MVST image, it can be
only be backed up by DFSMShsm from the MVS image that has it mounted. For
automatic backup, you might need to designate host affinity by specifying a
system name associated with AUTOBACKUP for each storage group. For
command-initiated backups, you might need to ensure that the commands or
batch jobs are issued to the correct MVS image.

If the file system being dumped by DFSMShsm is currently mounted as
read/write, then this file system can only be dumped from the system on
which it is mounted. If the file system is mounted as read-only or is in a
sysplex (mounted read-only or read/write), then it can be dumped from any
system that has access to it.

If you use DFSMShsm, you must define a user ID for the DFSMShsm address
space. For DFSMShsm to access the file systems, it must run under a user ID
that is set up for access to a z/OS UNIX system. When you set this access
up:

The default group for the DFSMShsm user ID must have an OMVS segment
defined and a group ID associated with it.
The home directory should be the root file system.


Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jonathan Miller
Sent: Wednesday, September 11, 2013 6:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSMShsm and backing up ZFS files

Hi all,
After adding a new DFSMS MC that had AUTOBACKUP(YES) and doing an alter for
all the ZFS datasets to move them into this new MC.
I also changed the ACS routines in case a new one get created.  I was
hopeful this morning run would back up our ZFS files.
Didn't happen.  I had the INCREMENTALBACKUP(ORIGINAL).So I changed 
this back to INCREMENTALBACKUP(CHANGEDONLY) and put in the required patches
and adjusted the AUTOBACKUPSTART and still no backups.
Any other suggestions?  I really thought the AUTOBACKUP in MC was the issue,
but it appears it must be something else.

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for
the above addressees only.  If you receive this message in error please
delete or destroy this message and/or attachments.  

The sender of this message will fully cooperate in the civil and criminal
prosecution of any individual engaging in the unauthorized use of this
message.

--

IBM Systems Magazine, Sep/Oct 2013

[zMan]

Cover has picture of Pat Toole. I don't really care what the manager of
System z looks like, but OK, I can deal with that.

But then we get to the article, which repeats the same FULL PAGE picture.
And then we turn the page, and there's yet another picture.

Is someone at IBMSM in love with Toole?! I can't believe this is considered
good journalism. I'd much rather have seen more hardware pr0n, or even the
"balanced design" picture one more time...
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Mark Zelden]

On Wed, 11 Sep 2013 07:57:47 -0400, Shmuel Metz (Seymour J.) 
 wrote:

>In <0de6a9840123e547b061ac5b6765c026bd0...@exmb-05.ad.wsu.edu>, on
>09/10/2013
>   at 02:44 AM, "Gibney, Dave"  said:
>
>>Yes, PDS/E shared outside of Sysplex is a problem if the sharing
>>is not close to strictly read only. Specifically, address spaces
>>with the PDS/E open in LPAR A will not like it after you update
>>the PDS/E from LPAR B
>
>The same applies to two z/OS guests in the same LPAR but not the same
>sysplex.
>
>Also, aren't there sharing issues even for R/O Or am I thinking of
>zFS?
>

Neither.  zFS can safely be shared R/O outside sysplex / GRS 
boundaries.   BTW, with PDSESHARING(NORMAL), PDSE can
be shared R/W outside the sysplex, but the boundaries must still
be within the GRSplex.   However, they can't be shared R/W between
systems managed by MII (MIM) because the ENQs issued for  
SYSZIGW0 and SYSZIGW1 are issued with RNL=NO.  IIRC, this
wasn't always the case and IBM "broke this" for CA MIM
customers around DFSMS/MVS 1.5.  Thank you IBM. 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PDS/E, Shared Dasd, and COBOL V5

[Mark Zelden]

For what it's worth, my client has been using PDSE for all their production 
loadlibs,
source libraries, proclibs, etc. (managed by Endevor) since sometime just after
Y2K.   The initial reason I pushed for it was occasional JES2 PROC issues after 
weekly
compress jobs would run.   

The only problem I recall in all these years was related to "illegal" sharing 
between 
a prod / devl sysplex (via MIM) of a prod CICS loadlib that someone included in 
a 
devl region shortly after we starting using PDSEs for the Endevor controlled 
prod/qa/devl/test environments.   Because PDSEs had to be SMS controlled
("going back to some ancient OS/390 release" as Ed said in a recent post) and 
those
sysplexes have different SMS pools and the DASD volumes are not online 
to the other plex, no other mistakes have ever happened.  Actually, I'm
a bit surprised myself after all these years that there hasn't been a problem
every now and then due to sharing PDSE outside sysplex boundaries.   

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Teletypewriter Model 33

[Ian]

I think the 1403 will be best remembered for it's musical capabilities.
http://mail.computerhistory.org/pipermail/1401_software/2009-February/000289.html

Ian


On Tue, Sep 10, 2013 at 11:45 PM, Scott Ford  wrote:

> Gerhard,
> We used to print bills on a 1403 with a special OCR print train and high
> intensity black ribbon.
> So they would scan correctly then we collated them and microfilmed
> them...omg ...I used to have to be to work at 3am for that job...
>
> Scott ford
> www.identityforge.com
> from my IPAD
>
> 'Infinite wisdom through infinite means'
>
>
> On Sep 10, 2013, at 12:41 AM, Gerhard Postpischil 
> wrote:
>
> > On 9/9/2013 10:32 PM, Paul Gilmartin wrote:
> >> Merely that it was the first time I saw a computer (it was a PDP-10)
> >> writing messages and column headings in mixed case.  "Thermal"
> >> is irrelevant; merely an exclamation of recognition of the device.
> >
> > That may have been your first exposure to mixed case output, but IBM
> offered an SN and TN train for the 1403. I used an IBM type III program
> named FORMAT, that provided an escape character (cent sign by default), to
> produce mixed case output. It came in very handy for writing memos and
> documentation.
> >
> > Gerhard Postpischil
> > Bradford, Vermont
> >
> > --
> > 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
>



-- 
Ian
http://www.cicsworld.com

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

Re: DFSMShsm and backing up ZFS files

[Jonathan Miller]

Hi all,
After adding a new DFSMS MC that had AUTOBACKUP(YES) and doing an alter 
for all the ZFS datasets to move them into this new MC.
I also changed the ACS routines in case a new one get created.  I was 
hopeful this morning run would back up our ZFS files.
Didn't happen.  I had the INCREMENTALBACKUP(ORIGINAL).So I changed 
this back to INCREMENTALBACKUP(CHANGEDONLY) and put in the
required patches and adjusted the AUTOBACKUPSTART and still no backups.
Any other suggestions?  I really thought the AUTOBACKUP in MC was the 
issue, but it appears it must be something else.

Jonathan Miller
AES/PHEAA
IT-Tech Services
Systems Programmer
(717) 720-2763 (Desk)
(717) 554-3663 (Cell)
This message contains privileged and confidential information intended for the 
above addressees only.  If you 
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging 
in the unauthorized use of this message.

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Bob Shannon]

>Also, aren't there sharing issues even for R/O Or am I thinking of zFS?

We share PDSEs read-only with our guests under VM. Everything is fine as long 
as there are no changes to the library. If the library is changed, the guests 
won't know about it and the results are unpredictable (but probably not good).

Bob Shannon
Rocket Software

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

Re: PDS/E, Shared Dasd, and COBOL V5

[Shmuel Metz (Seymour J.)]

In <0de6a9840123e547b061ac5b6765c026bd0...@exmb-05.ad.wsu.edu>, on
09/10/2013
   at 02:44 AM, "Gibney, Dave"  said:

>Yes, PDS/E shared outside of Sysplex is a problem if the sharing 
>is not close to strictly read only. Specifically, address spaces 
>with the PDS/E open in LPAR A will not like it after you update 
>the PDS/E from LPAR B

The same applies to two z/OS guests in the same LPAR but not the same
sysplex. 

Also, aren't there sharing issues even for R/O Or am I thinking of
zFS?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: NTP server with System z for PCI-DSS compliance

[Shmuel Metz (Seymour J.)]

In
,
on 09/11/2013
   at 05:17 PM, Timothy Sipples  said:

>By the way, I'm rather tired of the implicit and explicit 
>criticisms that Server Time Protocol (STP) has a separate charge.

The criticism is *not* that STP has a separate charge, but rather that
the automated setting of the time *ON A SINGLE BOX* requires STP,
which is chargeable. I don't recall anybody complaining that
sub-millisecond synchronization between boxes should be free.

>do you really want IBM to implement lower quality time services on
>zEnterprise?

As a free *option*? In a heartbeat. As the *only* option? Nobody has
asked for that. What they have asked for is the ability for a single
box to use NTP without paying extra for it.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Currently dispatched TCB in SRB mode

[Binyamin Dissen]

On Tue, 10 Sep 2013 11:58:04 -0400 "Shmuel Metz (Seymour J.)"
 wrote:

:>In
:>,
:>on 09/10/2013
:>   at 07:34 AM, Peter Relson  said:

:>>True. But it does not need to. Disablement of "your" CPU is the 
:>>serialization that is required.

:>For accessing the PSA of a different CPU?

With disablement, you can guarantee that your processor will not be
interrupted between fetching the address and accessing it (one would presume
screwing with a PSA will require SIGPing the other CPUs).

:>>This presumes that you were enabled for both interrupt types before
:>>the  STNSM.
:>
:>Indeed.

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

Re: Dynamic CALL counts from LE?

[Binyamin Dissen]

On Tue, 10 Sep 2013 17:56:30 -0400 John Gilmore  wrote:

:>There are of course current usage counts maintained by the z/OS
:>contents supervisor, but they are NOT cumulative.  If I wanted to
:>collect such counts in the short term, i.e., to instrument some small
:>set of LOADs and DELETEs I guess that I could do so fairly readily in
:>a fashion that would be useful to me, but something robust enough for
:>production use in a COBOL shop would be a much bigger undertaking.

As COBOL does a LOAD and then direct calls (for RENT programs, which are
pretty much all COBOL programs nowadays), the count of LOADs and DELETEs would
be a futile waste of time.

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

Re: Dynamic CALL counts from LE?

[Binyamin Dissen]

Well,

The COBOL compiler compiles the dynamic call to a call to a COBOL service
routine passing the name of the module. That service routine looks up the
module in its tables and will do a direct call if found or load and add if not
found.

You can try to frontend that COBOL service routine.

On Tue, 10 Sep 2013 16:33:59 -0400 "Farley, Peter x23353"
 wrote:

:>A question was asked here whether the number of times a COBOL CALL was done 
to various subroutines in a batch job step could somehow be reported out of 
system-generated information.  We were informed by local SMF specialists that 
LINK/LOAD/XCTL/ATTACH/DETACH counts were not available from SMF records.
:>
:>It occurred to me to wonder if LE maintains any sort of "CALL" count 
information for DYNAMically invoked routines (i.e., COBOL DYNAM compiler 
option, or "CALL variable-name" with option NODYNAM).
:>
:>Does anyone here know if there any such information available through LE 
services?  Is there any way at all to get such information short of in-program 
call counters reported at EOJ by the programs themselves?
:>
:>Peter

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