Re: Question about the COBOL compiler

[John McKown]

On Thu, Aug 4, 2016 at 6:41 PM, Hardee, Chuck  wrote:

> Actually, my dynamic calls work just fine to the alias'ed entry points so
> it's not an issue.
> Bottom line, I' fine with my module's structure both in its primary entry
> point and its aliased entry point.
> All I am looking for is whether the COBOL compiler can do PUNCH statements
> like some of the assemblers and I believe it has been pointed out already
> that it doesn't support it.
> So, I'm going to have to move on to the compiling tool we use and modify
> it to support alternate link parm input.
>

​So making the first line in the program something like:

*PROCESS NAME(ALIAS)

Doesn't work?​


> Thanks for your comments.
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
>

-- 
Klein bottle for rent -- inquire within.

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: Adding Module to an empty APFed Library

[Charles Mills]

I think security professionals would argue against "leaving an APF library 
around."

APF is the keys to the kingdom.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Thursday, August 04, 2016 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

On Wed, Aug 3, 2016 at 7:17 PM, retired mainframer  
wrote:
> If an empty dataset is on the APF list, it already exists.  Why it exists and 
> why it is on the list are different questions.
>
> Adding a member to an existing empty dataset is NO different than adding a 
> member to an existing populated one.
>
> What is the additional exposure?
>
Say you are installing a new product that requires an APF product.
In order to test, you install the empty libraries on test AND production 
systems.
Then install on the test system and test.
For a while, you would have an empty library on the production system.

Or you have uninstalled the product and left the library there in case the 
product is needed.  (I.E. read an old file).

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

Re: Question about the COBOL compiler

[Hardee, Chuck]

After being informed about it last night, yes, it does work.
I was looking for something akin to previous assembler features to "PUNCH" or 
"WRITE" as a compiler directive.
Hadn't thought of scouring the manuals for ALIAS. I figured it would be more 
generic.

C-

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, August 05, 2016 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about the COBOL compiler

On Thu, Aug 4, 2016 at 6:41 PM, Hardee, Chuck  wrote:

> Actually, my dynamic calls work just fine to the alias'ed entry points so
> it's not an issue.
> Bottom line, I' fine with my module's structure both in its primary entry
> point and its aliased entry point.
> All I am looking for is whether the COBOL compiler can do PUNCH statements
> like some of the assemblers and I believe it has been pointed out already
> that it doesn't support it.
> So, I'm going to have to move on to the compiling tool we use and modify
> it to support alternate link parm input.
>

​So making the first line in the program something like:

*PROCESS NAME(ALIAS)

Doesn't work?​


> Thanks for your comments.
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
>

-- 
Klein bottle for rent -- inquire within.

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: Question about the COBOL compiler

[John McKown]

On Fri, Aug 5, 2016 at 6:52 AM, Hardee, Chuck  wrote:

> After being informed about it last night, yes, it does work.
> I was looking for something akin to previous assembler features to "PUNCH"
> or "WRITE" as a compiler directive.
> Hadn't thought of scouring the manuals for ALIAS. I figured it would be
> more generic.
>

​Given that COBOL is supposed to be "universal" to _any_ OS, machine
architecture, yada yada, I am guessing the official language will _never_
support putting arbitrary data into the compiler output stream.​ I guess
IBM could implement a extension. Perhaps based on something like the HLASM
REPRO instruction:

PROCESS REPRO
.. ARBITRARY OBJECT RECORD
PROCESS REPRO
... ANOTHER ARBITRARY OBJECT RECORD



>
> C-
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
>

-- 
Klein bottle for rent -- inquire within.

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: Adding Module to an empty APFed Library

[Richards, Robert B.]

Not necessarily. Around here, they are using RACF to lock down APF dataset 
updates. It takes a change request with 2-3 approvers to get RACF authority to 
update an APF dataset. 

SET PROG= you say?   Well, you can always do anything ONCE.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, August 05, 2016 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

I think security professionals would argue against "leaving an APF library 
around."

APF is the keys to the kingdom.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Thursday, August 04, 2016 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

On Wed, Aug 3, 2016 at 7:17 PM, retired mainframer  
wrote:
> If an empty dataset is on the APF list, it already exists.  Why it exists and 
> why it is on the list are different questions.
>
> Adding a member to an existing empty dataset is NO different than adding a 
> member to an existing populated one.
>
> What is the additional exposure?
>
Say you are installing a new product that requires an APF product.
In order to test, you install the empty libraries on test AND production 
systems.
Then install on the test system and test.
For a while, you would have an empty library on the production system.

Or you have uninstalled the product and left the library there in case the 
product is needed.  (I.E. read an old file).

--
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: Adding Module to an empty APFed Library

[Charles Mills]

As it should. 

Nonetheless, multiple lines of defense are good.

I mean, we could debate this all week. Is an empty or nonexistent APF dataset 
the end of the world? No. Is it inherently a threat? No. But is it a best 
practice? No.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Friday, August 05, 2016 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

Not necessarily. Around here, they are using RACF to lock down APF dataset 
updates. It takes a change request with 2-3 approvers to get RACF authority to 
update an APF dataset. 

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

Re: Adding Module to an empty APFed Library

[Richards, Robert B.]

On this post, we are in complete agreement!  :-) 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, August 05, 2016 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

As it should. 

Nonetheless, multiple lines of defense are good.

I mean, we could debate this all week. Is an empty or nonexistent APF dataset 
the end of the world? No. Is it inherently a threat? No. But is it a best 
practice? No.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Friday, August 05, 2016 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

Not necessarily. Around here, they are using RACF to lock down APF dataset 
updates. It takes a change request with 2-3 approvers to get RACF authority to 
update an APF dataset. 

--
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: Adding Module to an empty APFed Library

[Elardus Engelbrecht]

Richards, Robert B. wrote:

>Around here, they are using RACF to lock down APF dataset updates. It takes a 
>change request with 2-3 approvers to get RACF authority to update an APF 
>dataset.  

What do you do if you really need do that update work to fix a problem at 
around 02:00 in the morning? 

 
>SET PROG= you say?   Well, you can always do anything ONCE. 
 
If you're authorised in the first place, you can always sneak in a program with 
AC(1) which issues a custom SET PROG command or CSVAPF macro.

So, you need to audit all UPDATE and ALTER attempts to these keys to the 
kingdom plus check your FACILITY class profile CSVAPF. and 
CSVAPF.MVS.

Groete / Greetings
Elardus Engelbrecht

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

Re: Adding Module to an empty APFed Library

[R.S.]

W dniu 2016-08-05 o 13:50, Charles Mills pisze:

I think security professionals would argue against "leaving an APF library 
around."

APF is the keys to the kingdom.
Yes, but from security point of view there is no difference between 
empty and populated library on APF.
Multiple lines of defence may be good, but there is no additional line 
for non-empty libraries.


--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: Adding Module to an empty APFed Library

[Richards, Robert B.]

In a real emergency, wake up a few folks. 

Everything I do is audited. That custom SETPROG command, if discovered, would 
be a career limiting command. I prefer to keep my job. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, August 05, 2016 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Adding Module to an empty APFed Library

Richards, Robert B. wrote:

>Around here, they are using RACF to lock down APF dataset updates. It takes a 
>change request with 2-3 approvers to get RACF authority to update an APF 
>dataset.  

What do you do if you really need do that update work to fix a problem at 
around 02:00 in the morning? 

 
>SET PROG= you say?   Well, you can always do anything ONCE. 
 
If you're authorised in the first place, you can always sneak in a program with 
AC(1) which issues a custom SET PROG command or CSVAPF macro.

So, you need to audit all UPDATE and ALTER attempts to these keys to the 
kingdom plus check your FACILITY class profile CSVAPF. and 
CSVAPF.MVS.

Groete / Greetings
Elardus Engelbrecht

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

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

Another COBOL question

[Hardee, Chuck]

Thanks to everyone that responded to my previous question about generating link 
statements from the compiler.
The answer was to use the NAME(ALIAS) PROCESS statement.

I now am looking for some further insight.

I have a program that has a main program and an alternate entry point (ENTRY).
The alternate entry point is an LE error handler.
The main program issues a SET  TO ENTRY "modname" in order to load an 
assembled  parameter file.
If the load is successful, then the program can extract the information it 
needs from the load module and go on its merry way.

The source program successfully compiles and builds a single executable with 
the main program name and an alias for the ENTRY statement.

By inserting displays into the program I can say that the main program appears 
to be working fine up to the SET statement.

It issues a SET  TO ENTRY "error handler entry point name" and then issues 
a call to CEEHDLR to register the error handle routine.
It then issues the SET  TO ENTRY "modname" and here's where the problem 
comes in.
If the module is found, the SET is successful and the program does its thing.
If the module is NOT found, it abends with a CEE0374C with CONDITION=CEE3501S. 
The reported condition is the condition that the error handler is supposed to 
trap and handle.

If I split the code out into 2 separately compiled programs, all works as 
desired.
Unfortunately, 2 programs is not an option for me unless someone can point me 
to the IBM statement that declares what I am trying to do is not possible or 
not supported.

Has anyone ever written a single COBOL program which contains an ENTRY 
statement for an internal language environment error handler?
If so, can you share with me what you did to make it work?

I have gone thru the LE manuals and found several COBOL examples where there 
are program "boxes" with flow of control indicated but none of them appear to 
be ENTRY type points of code within a single program. Furthermore, I can't find 
anything in the LE manuals that say that using an ENTRY to gain access to an 
error handler routine isn't allowed, at least not in clear enough terminology 
that I can see.

There is, however, a warning that an error handler should be issued in a COBOL 
nested environment.
Unfortunately, it doesn't describe a COBOL nested environment.

Thanks in advance,
Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com  | 
www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


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

Re: Question about the COBOL compiler

[Don Poitras]

Just a heads-up for those that have used PUNCH to do this kind of thing for
years in assembly. It's not supported for 64-bit XPLINK (or any time that the
GOFF option is used.) See:

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/punch.htm

In article 
<985915eee6984740ae93f8495c624c6c23b8e10...@jscpcwexmaa1.bsg.ad.adp.com> you 
wrote:
> Unlike HLASM and predecessors, there is no "PUNCH" command to output 
> arbitrary "cards" to the object output from COBOL.

> About all I can think of is to go ahead and submit the compile/link job that 
> the panels produce, then cancel the job before it completes, then use SJ from 
> SDSF to edit the JCL to add the ALIAS statement to the LKED SYSIN DD.

> Nothing automated, but it will get the job done.

> HTH

> Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Hardee, Chuck
> Sent: Thursday, August 04, 2016 5:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question about the COBOL compiler

> Compiler version: PP 5655-G53 IBM Enterprise COBOL for z/OS  3.4.1 V3R2

> What I need is this:

> INCLUDE OBJLIB(PROGRAMA)
> ALIAS ENTRYB(NTRYPTB)
> NAME PROGRMA(R)

> Our compile panels generate the INCLUDE and NAME statements.
> However, I need to have the ALIAS in there as well.

> Our panels don't allow for additional statements like ALIAS and I don't want 
> to dig into them and add the support for them.
> I suspect few, if any, other than me in this special usage, will ever need 
> something like this.

> As to dynamic or static, not really relevant, but for the record, all of our 
> programs are, by standard and policy, compiled with DYNAM enabled.

> C-

> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology

> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  | www.thermofisher.com

> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of 
> this e-mail or the information herein by anyone other than the intended 
> recipient, or an employee or agent of a system responsible for delivering the 
> message to the intended recipient, is prohibited. If you are not the intended 
> recipient, please inform the sender and delete all copies.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Woodger
> Sent: Thursday, August 04, 2016 5:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question about the COBOL compiler

> Somewhat (when you have a "batch compile - a compile of a load of separate 
> programs in one hit). But not really, there was a bit of recent discussion of 
> this here, a topic by Frank Swarbrick.

> Which compiler are you using? You want to CALL dynamically, or statically?

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

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

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

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Another COBOL question

[John McKown]

On Fri, Aug 5, 2016 at 9:18 AM, Hardee, Chuck  wrote:

> Thanks to everyone that responded to my previous question about generating
> link statements from the compiler.
> The answer was to use the NAME(ALIAS) PROCESS statement.
>
> I now am looking for some further insight.
>
> I have a program that has a main program and an alternate entry point
> (ENTRY).
> The alternate entry point is an LE error handler.
> The main program issues a SET  TO ENTRY "modname" in order to load an
> assembled  parameter file.
> If the load is successful, then the program can extract the information it
> needs from the load module and go on its merry way.
>
> The source program successfully compiles and builds a single executable
> with the main program name and an alias for the ENTRY statement.
>
> By inserting displays into the program I can say that the main program
> appears to be working fine up to the SET statement.
>
> It issues a SET  TO ENTRY "error handler entry point name" and then
> issues a call to CEEHDLR to register the error handle routine.
> It then issues the SET  TO ENTRY "modname" and here's where the
> problem comes in.
> If the module is found, the SET is successful and the program does its
> thing.
> If the module is NOT found, it abends with a CEE0374C with
> CONDITION=CEE3501S. The reported condition is the condition that the error
> handler is supposed to trap and handle.
>
> If I split the code out into 2 separately compiled programs, all works as
> desired.
> Unfortunately, 2 programs is not an option for me unless someone can point
> me to the IBM statement that declares what I am trying to do is not
> possible or not supported.
>
> Has anyone ever written a single COBOL program which contains an ENTRY
> statement for an internal language environment error handler?
>

​No, but I have a couple of programs which are my tests of using CEEHDLR. I
could try merging them together. Actually, they are based on some sample
code I got from IBM & Andy Robertson.​



> If so, can you share with me what you did to make it work?
>
> I have gone thru the LE manuals and found several COBOL examples where
> there are program "boxes" with flow of control indicated but none of them
> appear to be ENTRY type points of code within a single program.
> Furthermore, I can't find anything in the LE manuals that say that using an
> ENTRY to gain access to an error handler routine isn't allowed, at least
> not in clear enough terminology that I can see.
>
> There is, however, a warning that an error handler should be issued in a
> COBOL nested environment.
>

Did you leave out the "not" in the above? ​Looking at:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clchdlr.htm
it says the exact OPPOSITE


   - COBOL consideration—You should not call CEEHDLR from a nested COBOL
   program.

​



> Unfortunately, it doesn't describe a COBOL nested environment.
>


​COBOL Language Reference  Chapter 10
http://publibfp.boulder.ibm.com/epubs/pdf/igy6lr10.pdf​


Nested programs A nested program is a program that is contained in another
program. Contained programs can reference some of the resources of the
programs that contain them. If program B is contained in program A, it is
directly contained if there is no program contained in program A that also
contains program B. Program B is indirectly contained in program A if there
exists a program contained in program A that also contains program B. For
more information about nested programs, see Nested programs in the
Enterprise COBOL Programming Guide.



E.g. (very shortened)

IDENTIFICATION DIVISION.
PROGRAM-ID. EXTPROG.
...
IDENTIFICATION DIVISION.
PROGRAM-ID. INTPROG.
...
END PROGRAM INTPROG
END PROGRAM EXTPROG.

​INTPROG is nested within EXTPROG and is not visible outside of it.​ More
at http://publibfp.boulder.ibm.com/epubs/pdf/igy6pg10.pdf on page 479.



>
> Thanks in advance,
> Chuck
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  |
> www.thermofisher.com
>
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of
> this e-mail or the information herein by anyone other than the intended
> recipient, or an employee or agent of a system responsible for delivering
> the message to the intended recipient, is prohibited. If you are not the
> intended recipient, please inform the sender and delete all copies.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

---

Re: Another COBOL question

[Farley, Peter x23353]

COBOL nested programs are structured like this:

 Id division.
 Program-id. Outer-program.
   Procedure division.
 Call "Inner-1".
 Stop run.
 Id division.
   Program-id. Inner-1
   ...
 Call Inner-1a.
 Stop run.
   Id division.
   Program-id. Inner-1a.
   ...
   End Inner-1a.
   End Inner-1.
 End Outer-program.

See section "2.1.1 Nested programs" in the COBOL Language Reference manual.

Basically I think it is telling you to make the error handler a nested separate 
routine with its own ID DIVISION and PROGRAM-ID instead of making it an ENTRY.

Don't forget to check out the COMMON and INITIAL attributes on the PROGRAM-ID 
paragraph as well.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hardee, Chuck
Sent: Friday, August 05, 2016 10:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Another COBOL question

Thanks to everyone that responded to my previous question about generating link 
statements from the compiler.
The answer was to use the NAME(ALIAS) PROCESS statement.

I now am looking for some further insight.



There is, however, a warning that an error handler should be issued in a COBOL 
nested environment.
Unfortunately, it doesn't describe a COBOL nested environment.

Thanks in advance,
Chuck
--

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: COBOL 2014 dynamic capacity tables

[Frank Swarbrick]

That's good to know.  I searched the internet and found a page about 
implementing dynamic arrays in C and he was using "double", but 1.5 also sounds 
reasonable.  I wonder if perhaps there should be some sort of ratcheting down 
as the number of rows gets very large.


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, August 4, 2016 8:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 2014 dynamic capacity tables

On 4/08/2016 2:52 AM, Frank Swarbrick wrote:
> Even in the case where it does increase the actual allocated capacity, it 
> does not do it "one row at a time".  Rather, it doubles the current physical 
> capacity and "reallocates" (using CEECZST) the storage to the new value.  
> This may or may not actually cause LE storage control to reallocate out of a 
> different area (copying the existing data from the old allocated area).  If 
> there is enough room already it does nothing except increase the amount 
> reserved for your allocation.  And even then, LE has already allocated a 
> probably larger area prior to this from actual OS storage, depending on the 
> values in the HEAP runtime option.

Almost all the dynamic array implementations that I'm aware of, C++
std::vector, Java ArrayList, Python lists, Lua tables, use a growth
factor of 1.5. Apparently it's a golden ratio.

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

Another COBOL question

[Bill Woodger]

I've already posted that for a dynamic CALL you are supposed to CANCEL the 
"main" program before using the ENTRY program.

If there is nothing in the ENTRY program which relies on WORKING-STORAGE or 
LOCAL-STORAGE in the "main" program, you may ordinarily "get away with it", 
even though the lack of relationship would usually obviate the use of the ENTRY.

I think you meant that the the LE handler *can't* be in a contained/nested 
program. Because it can't.

What that all means exactly for your handler, I don't know. I'd never have 
thought to try to make the handler an ENTRY.

The SET ... ENTRY will cause the handler (ALIAS) to be loaded as an entirely 
separate executable. I can't say that that wouldn't or shouldn't work, but it 
doesn't seem to.

I think the abend you are getting is from LE attempting to locate/use the 
handler.

I don't know if the nested/contained not working is a hint that the ENTRY won't 
work either.

IBM do not recommend using an ENTRY full-stop.

I'd use the two-program approach. It may be interesting to establish exactly 
why it doesn't work with the ENTRY, but only interesting, not so useful 
generally.

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

Question about the COBOL compiler

[Bill Woodger]

The NAME compiler option (can be used from PARM, from CBL/PROCESS source 
statement) does generate binder/linkage-editor control statements.

I don't think that it would be at all a good idea to have "arbitrary" 
binder/linkage-editor inserted by a programmer. There's too much that could be 
done, deliberately or by accident.

On Friday, 5 August 2016 14:21:21 UTC+2, John McKown  wrote:
> ​Given that COBOL is supposed to be "universal" to _any_ OS, machine
> architecture, yada yada, I am guessing the official language will _never_
> support putting arbitrary data into the compiler output stream.​ I guess
> IBM could implement a extension. Perhaps based on something like the HLASM
> REPRO instruction:
> 
> PROCESS REPRO
> .. ARBITRARY OBJECT RECORD
> PROCESS REPRO
> ... ANOTHER ARBITRARY OBJECT RECORD
> 

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

COBOL 2014 dynamic capacity tables

[Bill Woodger]

Yes, good to know. I realised when I was writing my earlier comment that there 
is not much downside to defining "extra" storage, it is what we do already with 
a static table :-)

However, I'd still go horses-for-courses. Make the increment for the unboaded 
table a size which relates to the data and its usage. It'd avoid 50 unbounded 
tables sucking up all the storage available when only 2/3 of the storage was 
expected to be used.

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

Re: Question about the COBOL compiler

[Frank Swarbrick]

Hmm, I recently converted a bunch of assembler subroutines to be re-entrant and 
I put the following as the first line of each module:

PUNCH ' SETOPT PARM(REUS=RENT)'

All of them are assembled with the GOFF option and I've not run in to any 
problems.

Perhaps its not an issue as long as all of the "punches" are done prior to any 
actual assembler code??


Frank


From: IBM Mainframe Discussion List  on behalf of Don 
Poitras 
Sent: Friday, August 5, 2016 8:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about the COBOL compiler

Just a heads-up for those that have used PUNCH to do this kind of thing for
years in assembly. It's not supported for 64-bit XPLINK (or any time that the
GOFF option is used.) See:

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/punch.htm
PUNCH instruction - 
IBM
www.ibm.com
The PUNCH instruction creates a record containing a source or other statement, 
or an object record, to be written to the object file. >>-+-+--PUNCH-- ...



In article 
<985915eee6984740ae93f8495c624c6c23b8e10...@jscpcwexmaa1.bsg.ad.adp.com> you 
wrote:
> Unlike HLASM and predecessors, there is no "PUNCH" command to output 
> arbitrary "cards" to the object output from COBOL.

> About all I can think of is to go ahead and submit the compile/link job that 
> the panels produce, then cancel the job before it completes, then use SJ from 
> SDSF to edit the JCL to add the ALIAS statement to the LKED SYSIN DD.

> Nothing automated, but it will get the job done.

> HTH

> Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Hardee, Chuck
> Sent: Thursday, August 04, 2016 5:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question about the COBOL compiler

> Compiler version: PP 5655-G53 IBM Enterprise COBOL for z/OS  3.4.1 V3R2

> What I need is this:

> INCLUDE OBJLIB(PROGRAMA)
> ALIAS ENTRYB(NTRYPTB)
> NAME PROGRMA(R)

> Our compile panels generate the INCLUDE and NAME statements.
> However, I need to have the ALIAS in there as well.

> Our panels don't allow for additional statements like ALIAS and I don't want 
> to dig into them and add the support for them.
> I suspect few, if any, other than me in this special usage, will ever need 
> something like this.

> As to dynamic or static, not really relevant, but for the record, all of our 
> programs are, by standard and policy, compiled with DYNAM enabled.

> C-

> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology

> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com  | 
> www.thermofisher.com

> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of 
> this e-mail or the information herein by anyone other than the intended 
> recipient, or an employee or agent of a system responsible for delivering the 
> message to the intended recipient, is prohibited. If you are not the intended 
> recipient, please inform the sender and delete all copies.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Woodger
> Sent: Thursday, August 04, 2016 5:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Question about the COBOL compiler

> Somewhat (when you have a "batch compile - a compile of a load of separate 
> programs in one hit). But not really, there was a bit of recent discussion of 
> this here, a topic by Frank Swarbrick.

> Which compiler are you using? You want to CALL dynamically, or statically?

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

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

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

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

Re: COBOL 2014 dynamic capacity tables

[Mike Schwab]

Define a file with a record containing the maximum array size for each table.
Open file, read record, set sizes to 10% over maximum, Close file.
Process main file.
If any maximum array size exceeded, Set new maximum, Open file for
output, Write record, Close file.

On Fri, Aug 5, 2016 at 10:25 AM, Bill Woodger  wrote:
> Yes, good to know. I realised when I was writing my earlier comment that 
> there is not much downside to defining "extra" storage, it is what we do 
> already with a static table :-)
>
> However, I'd still go horses-for-courses. Make the increment for the unboaded 
> table a size which relates to the data and its usage. It'd avoid 50 unbounded 
> tables sucking up all the storage available when only 2/3 of the storage was 
> expected to be used.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Another COBOL question

[Frank Swarbrick]

To the OP, why is it so important that ENTRY be used?  Would two (non-nested) 
programs in the same source member be enough?  i.e. a single source member 
containing two programs like this?


PROCESS NAME

ID DIVISION.

PROGRAM-ID. MAINPROG.

END PROGRAM MAINPROG.

PROCESS NAME

ID DIVISION.

PROGRAM-ID. CONDHDLR.

END PROGRAM CONDHDLR.


Personally, I think that COBOL should have a "package" structure like PL/I has 
had for a while...



From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Another COBOL question

I've already posted that for a dynamic CALL you are supposed to CANCEL the 
"main" program before using the ENTRY program.

If there is nothing in the ENTRY program which relies on WORKING-STORAGE or 
LOCAL-STORAGE in the "main" program, you may ordinarily "get away with it", 
even though the lack of relationship would usually obviate the use of the ENTRY.

I think you meant that the the LE handler *can't* be in a contained/nested 
program. Because it can't.

What that all means exactly for your handler, I don't know. I'd never have 
thought to try to make the handler an ENTRY.

The SET ... ENTRY will cause the handler (ALIAS) to be loaded as an entirely 
separate executable. I can't say that that wouldn't or shouldn't work, but it 
doesn't seem to.

I think the abend you are getting is from LE attempting to locate/use the 
handler.

I don't know if the nested/contained not working is a hint that the ENTRY won't 
work either.

IBM do not recommend using an ENTRY full-stop.

I'd use the two-program approach. It may be interesting to establish exactly 
why it doesn't work with the ENTRY, but only interesting, not so useful 
generally.

--
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: Adding Module to an empty APFed Library

[Elardus Engelbrecht]

Richards, Robert B. wrote:

>In a real emergency, wake up a few folks.  

Good! Now I can go zz  ;-)


>Everything I do is audited. That custom SETPROG command, if discovered, would 
>be a career limiting command. I prefer to keep my job.  
 
Excellent! I also don't like those custom SETPROG things and similar stunts. 
Too dangerous to meddle with clients, auditors and management... Everything is 
audited and sent over to management every day automagically.

I also want to stay where I'm working. Pay, location, benefits, etc. are all 
good, so I want to keep all these goodies where possible... 

... unless I win a big lottery ... then I'm outta here. ;-D

PS: This is where mainframe is better - better auditing and controls. But to 
educate auditors, that is another story...

Robert, please keep up with your good postings, I really appreciate them.

Groete / Greetings 
Elardus Engelbrecht 

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

PDSEGEN Update

[Lionel Dyck]

For those working with, or experimenting, with PDSE Version 2 Member
Generations there is nothing better than PDSEGEN (at least for the price).

 

PDSEGEN is an ISPF dialog that works makes working with Member Generations
easy and intuitive. Included with PDSEGEN is the ability to Backup all
member and generations, retaining all ISPF statistics, to a normal PDS that
can be processed by any software that works with a PDS (e.g. IEBCOPY, TSO
Transmit, etc.). There is a Restore capability to restore the backup PDS to
a PDSE with all members and generations in tact. Another tool included is
the ability to Copy PDSE members with their generations.  In addition to
those you can Browse and View any member or generation, Edit the base member
(edit is prevented on non-0 generations until JCL and dynamic allocation
enable access to them at which point PDSEGEN can be changed to allow Edit on
non-0 generations. The capability is also provided to compare 2 generations
(non-0 to 0 and non-0 to non-0). And more.

 

I've just posted version 3.8 to www.lbdsoftware.com
  and it has the following updates:

 

  Version 3.8   August 05, 2016


 - ASM changes


   PDSEGDEL   - Added as a REXX function to delete members and


member generations (not to be used for non member


generation enabled datasets)


 - Exec changes


   $RECV  - Updated to properly handle the source dataset name


   PDSEGEN- Update locate routine when member not located


  - update reName newname to mbr


  - correction for null tso prefix users


  - use PDSEGEL to delete members/generations if the


generations are enabled


- used in the rename routine as well


  - LMMDEL will be used for non-generation enabled


datasets


  - fix bug in rename and recover thx to Bill Fleury


   PDSEGENC   - correction for null tso prefix users


 - Misc changes


   $RECV  - Correction for received dsn


   $INSTALL   - Added


 - Panel changes


   PDSEGH0- Correction for abbreviation comment


  - Add Delete to the Rename tutorial panel


   PDSEGHR- Add some more info to restrictions


   PDSEGHRN   - Add Delete to the Rename tutorial panel


   PDSEGHT- Add tip on use of delete 


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

Re: Question about the COBOL compiler

[Frank Swarbrick]

Bill, how come we always end up on the opposite ends of things!


Firstly, its not clear to me what harmful things this would allow.


In any case, as with NAME, Enterprise COBOL should at least allow source code 
setting of some basic binder directives, such as INCLUDE and some (or all) of 
the SETOPT PARM directives.  For instance, when the DLL compile option is used, 
shouldn't COBOL insert "SETOPT PARM(DYNAM=DLL)", since that is absolutely 
required for a DLL to be properly liked?  And how about "SETOPT 
PARM(CASE=MIXED)" if PGMNAME(LONGMIXED) is specified?  There should also be an 
option to include "SETOPT PARM(REUS=RENT)".


Perhaps SETOPT and INCLUDE are really the only ones necessary, because if you 
needed to "include" other types of directives you could place them in a member 
and, well, INCLUDE them.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question about the COBOL compiler

The NAME compiler option (can be used from PARM, from CBL/PROCESS source 
statement) does generate binder/linkage-editor control statements.

I don't think that it would be at all a good idea to have "arbitrary" 
binder/linkage-editor inserted by a programmer. There's too much that could be 
done, deliberately or by accident.

On Friday, 5 August 2016 14:21:21 UTC+2, John McKown  wrote:
> Given that COBOL is supposed to be "universal" to _any_ OS, machine
> architecture, yada yada, I am guessing the official language will _never_
> support putting arbitrary data into the compiler output stream. I guess
> IBM could implement a extension. Perhaps based on something like the HLASM
> REPRO instruction:
>
> PROCESS REPRO
> .. ARBITRARY OBJECT RECORD
> PROCESS REPRO
> ... ANOTHER ARBITRARY OBJECT RECORD
>

--
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: Question about the COBOL compiler

[Frank Swarbrick]

It is worth noting that there was a recent RFE submitted (Feb 2016) that asked 
for an option to include binder control statements in CBL/PROCESS directives:  
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=83968.

Unfortunately it was declined.  "This would require interaction between the 
compiler and binder. As a result, this may impose some design issues between 
the compiler and binder interface.  In addition, most people won't want this 
flexibility. There could be some security related issues. Hence, rejecting."

I am of the believe that both reasons for declining the RFE are spurious.  The 
first one is barely, I believe, even correct.  All they need to do (I believe!) 
is insert the control statements either before or after (as appropriate) the 
generated object module.  And as pointed out, they already do this for "PROCESS 
NAME"!

As for the latter, perhaps Bill Woodger got to them?  I am curious where they 
got their information about what "most people" won't want.

Grrr!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Friday, August 5, 2016 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about the COBOL compiler

Bill, how come we always end up on the opposite ends of things!


Firstly, its not clear to me what harmful things this would allow.


In any case, as with NAME, Enterprise COBOL should at least allow source code 
setting of some basic binder directives, such as INCLUDE and some (or all) of 
the SETOPT PARM directives.  For instance, when the DLL compile option is used, 
shouldn't COBOL insert "SETOPT PARM(DYNAM=DLL)", since that is absolutely 
required for a DLL to be properly liked?  And how about "SETOPT 
PARM(CASE=MIXED)" if PGMNAME(LONGMIXED) is specified?  There should also be an 
option to include "SETOPT PARM(REUS=RENT)".


Perhaps SETOPT and INCLUDE are really the only ones necessary, because if you 
needed to "include" other types of directives you could place them in a member 
and, well, INCLUDE them.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question about the COBOL compiler

The NAME compiler option (can be used from PARM, from CBL/PROCESS source 
statement) does generate binder/linkage-editor control statements.

I don't think that it would be at all a good idea to have "arbitrary" 
binder/linkage-editor inserted by a programmer. There's too much that could be 
done, deliberately or by accident.

On Friday, 5 August 2016 14:21:21 UTC+2, John McKown  wrote:
> Given that COBOL is supposed to be "universal" to _any_ OS, machine
> architecture, yada yada, I am guessing the official language will _never_
> support putting arbitrary data into the compiler output stream. I guess
> IBM could implement a extension. Perhaps based on something like the HLASM
> REPRO instruction:
>
> PROCESS REPRO
> .. ARBITRARY OBJECT RECORD
> PROCESS REPRO
> ... ANOTHER ARBITRARY OBJECT RECORD
>

--
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: Another COBOL question

[John McKown]

On Fri, Aug 5, 2016 at 9:18 AM, Hardee, Chuck  wrote:

> ​
>
>
> Has anyone ever written a single COBOL program which contains an ENTRY
> statement for an internal language environment error handler?
> If so, can you share with me what you did to make it work?
>

​The code below seems to work (it is also available on github at
https://gist.github.com/JohnArchieMckown/d4af397cb47017fac8b4c972daca1864)​.
I just did some minor merging of two separate programs (invoker & handler)
into one. I did not "clean up" much of anything to make it nicer / neater.
I wasn't going to post this, but I've been castigate on some forum with
comments like "not putting code in-line results in more work for others to
read and the other site may go away leaving things hanging".

​===

000100 PROCESS LIB,QUOTE,NAME(ALIAS)0001
000200* 0002
000300*   * 0003
000400*  IBM Language Environment for OS/390 & VM * 0004
000500*   * 0005
000600*  Licensed Materials - Property of IBM * 0006
000700*   * 0007
000800*  5647-A01 5688-198* 0008
000900*  (C) Copyright IBM Corp. 1991, 1997   * 0009
001000*  All Rights Reserved  * 0010
001100*   * 0011
001200*  US Government Users Restricted Rights - Use, * 0012
001300*  duplication or disclosure restricted by GSA  * 0013
001400*  ADP Schedule Contract with IBM Corp. * 0014
001500*   * 0015
001600* 0016
001700*Module/File Name: IGZTHDLR   0017
001800***   0018
001900**   **   0019
002000** CBLHDLR - Call CEEHDLR to register a user **   0020
002100**   condition handler   **   0021
002200**   **   0022
002300***   0023
002400 IDENTIFICATION DIVISION. 0024
002500 PROGRAM-ID. CBLHDLR2.0025
002600 DATA DIVISION.   0026
002700 WORKING-STORAGE SECTION. 0027
002800 01  ROUTINE  PROCEDURE-POINTER.  0028
002900 01  WS-TOKEN   PIC S9(9) BINARY. 0029
003000 01  SEV PIC S9(4) BINARY.0030
003100 01  MSGNO   PIC S9(4) BINARY.0031
003200 01  CASEPIC S9(4) BINARY.0032
003300 01  SEV2PIC S9(4) BINARY.0033
003400 01  CNTRL   PIC S9(4) BINARY.0034
003500 01  FACID   PIC X(3).0035
003600 01  ISINFO  PIC S9(9) BINARY.0036
003700 01  QDATA   PIC S9(9) BINARY.0037
003800 01  RECOVERY-AREA   EXTERNAL.0038
003900 05 RECOVERY-POINT   POINTER. 0039
004000 05 ERROR-INDICATOR  PIC X .  0040
004100 88 ERROR-OCCURRED   VALUE IS HIGH-VALUES.0041
004200 88 NO-ERROR-OCCURREDVALUE IS LOW-VALUES. 0042
004300  0043
004400 01  FC-HANDLER.  0044
004500 02  Condition-Token-Value.   0045
004600 COPY  CEEIGZCT.  0046
004700 03  Case-1-Condition-ID. 0047
004800 04  SeverityPIC S9(4) BINARY.0048
004900 04  Msg-No  PIC S9(4) BINARY.0049
005000 03  Case-2-Condition-ID  0050
005100   REDEFINES Case-1-Condition-ID. 0051
005200 04  Class-Code  PIC S9(4) BINARY.0052
005300  

Re: Another COBOL question

[John McKown]

On Fri, Aug 5, 2016 at 10:57 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> To the OP, why is it so important that ENTRY be used?  Would two
> (non-nested) programs in the same source member be enough?  i.e. a single
> source member containing two programs like this?
>
> PROCESS NAME
> ID DIVISION.
> PROGRAM-ID. MAINPROG.
> END PROGRAM MAINPROG.
> PROCESS NAME
> ID DIVISION.
> PROGRAM-ID. CONDHDLR.
> END PROGRAM CONDHDLR.
>
>
> Personally, I think that COBOL should have a "package" structure like PL/I
> has had for a while...
>

​I'm going to take a wild guess that the "problem" with two programs, which
link into to separate program object in the library, is that it would
violate shop standards. I.e. "Only one program per source member.​" Most
likely along with the rule that the PDS (or file name) must exactly match
the name of the program (in the PROGRAM-ID.) and the name under which it is
bound/linked to "tracking purposes". There are a lot of "rules" of this
nature to make managing a large environment easier and require less
intelligence, work, and creativity. Creativity is for artsy people. We are
engineers! (last statements are a bit tongue-in-cheek - and it's very
difficult to talk doing that!)



>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Bill Woodger 
> Sent: Friday, August 5, 2016 9:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Another COBOL question
>
> I've already posted that for a dynamic CALL you are supposed to CANCEL the
> "main" program before using the ENTRY program.
>
> If there is nothing in the ENTRY program which relies on WORKING-STORAGE
> or LOCAL-STORAGE in the "main" program, you may ordinarily "get away with
> it", even though the lack of relationship would usually obviate the use of
> the ENTRY.
>
> I think you meant that the the LE handler *can't* be in a contained/nested
> program. Because it can't.
>
> What that all means exactly for your handler, I don't know. I'd never have
> thought to try to make the handler an ENTRY.
>
> The SET ... ENTRY will cause the handler (ALIAS) to be loaded as an
> entirely separate executable. I can't say that that wouldn't or shouldn't
> work, but it doesn't seem to.
>
> I think the abend you are getting is from LE attempting to locate/use the
> handler.
>
> I don't know if the nested/contained not working is a hint that the ENTRY
> won't work either.
>
> IBM do not recommend using an ENTRY full-stop.
>
> I'd use the two-program approach. It may be interesting to establish
> exactly why it doesn't work with the ENTRY, but only interesting, not so
> useful generally.
>
> --
> 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
>



-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

Another COBOL question

[Bill Woodger]

I like Frank's example, prefer it over the ENTRY.

If the ENTRY works, but it's use is not documented, I'd raise it with IBM. Once 
they acknowledge (or deny) that it works, you are safe against some future 
change (or you know you have to change it now).

I think any site that doesn't allow Frank's example won't allow ENTRY either. 
There was mention of "copying up the line". I think in olden days, IEBCOPY 
would "loose" the ALIAS, I seem to remember having to re-ALIAS things.

Frank, one PROCESS NAME is enough (can also be supplied on the PARM (or a CBL).

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

Question about the COBOL compiler

[Bill Woodger]

If you don't know what harmful things there are, consult the 
Binder/Linkage-editor manual. Like compiling this program and linking it as 
another, for a simple one.

It is rare that IBM ask me anything (although it did happen once, if IBM can be 
thought of as one person who works for IBM).

Even if you no longer want arbitrary, but limited binder/linke-editor control 
cards...

Most people won't want the flexibility because they will have distinct was to 
process distinct types of programs. You don't have a program you want to use as 
a DLL, then poke it through a CICS process, and hope to be able to tidy it up 
at the end. You have a "this is how you do a DLL" process.

Note, it is possible to prevent the use of CBL/PROCESS cards, and possible to 
"nail-in" compiler installation options (by option). 

For many sites, reliable compiler output gives them far more flexibility, 
perhaps?

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

Re: Question about the COBOL compiler

[Frank Swarbrick]

I have just posted to the IBM COBOL Cafe a topic named "COBOL user exit to 
allow binder control statements in COBOL source member".  Check it out if you 
are interested.

https://www.ibm.com/developerworks/community/forums/html/topic?id=bc790c2a-e635-4621-b7b1-61a6b00c5898&ps=25

Frank


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Friday, August 5, 2016 10:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about the COBOL compiler

It is worth noting that there was a recent RFE submitted (Feb 2016) that asked 
for an option to include binder control statements in CBL/PROCESS directives:  
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=83968.

Unfortunately it was declined.  "This would require interaction between the 
compiler and binder. As a result, this may impose some design issues between 
the compiler and binder interface.  In addition, most people won't want this 
flexibility. There could be some security related issues. Hence, rejecting."

I am of the believe that both reasons for declining the RFE are spurious.  The 
first one is barely, I believe, even correct.  All they need to do (I believe!) 
is insert the control statements either before or after (as appropriate) the 
generated object module.  And as pointed out, they already do this for "PROCESS 
NAME"!

As for the latter, perhaps Bill Woodger got to them?  I am curious where they 
got their information about what "most people" won't want.

Grrr!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Friday, August 5, 2016 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about the COBOL compiler

Bill, how come we always end up on the opposite ends of things!


Firstly, its not clear to me what harmful things this would allow.


In any case, as with NAME, Enterprise COBOL should at least allow source code 
setting of some basic binder directives, such as INCLUDE and some (or all) of 
the SETOPT PARM directives.  For instance, when the DLL compile option is used, 
shouldn't COBOL insert "SETOPT PARM(DYNAM=DLL)", since that is absolutely 
required for a DLL to be properly liked?  And how about "SETOPT 
PARM(CASE=MIXED)" if PGMNAME(LONGMIXED) is specified?  There should also be an 
option to include "SETOPT PARM(REUS=RENT)".


Perhaps SETOPT and INCLUDE are really the only ones necessary, because if you 
needed to "include" other types of directives you could place them in a member 
and, well, INCLUDE them.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question about the COBOL compiler

The NAME compiler option (can be used from PARM, from CBL/PROCESS source 
statement) does generate binder/linkage-editor control statements.

I don't think that it would be at all a good idea to have "arbitrary" 
binder/linkage-editor inserted by a programmer. There's too much that could be 
done, deliberately or by accident.

On Friday, 5 August 2016 14:21:21 UTC+2, John McKown  wrote:
> Given that COBOL is supposed to be "universal" to _any_ OS, machine
> architecture, yada yada, I am guessing the official language will _never_
> support putting arbitrary data into the compiler output stream. I guess
> IBM could implement a extension. Perhaps based on something like the HLASM
> REPRO instruction:
>
> PROCESS REPRO
> .. ARBITRARY OBJECT RECORD
> PROCESS REPRO
> ... ANOTHER ARBITRARY OBJECT RECORD
>

--
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: Another COBOL question

[Frank Swarbrick]

Bill, I'm not sure that your comment about a single PROCESS NAME is true.  I 
just tried it with only one and the second program was compiled with the 
default of NONAME.  You are correct that "Invocation parameters" (PARM options) 
are "global" to all source code within a single compile.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Another COBOL question

I like Frank's example, prefer it over the ENTRY.

If the ENTRY works, but it's use is not documented, I'd raise it with IBM. Once 
they acknowledge (or deny) that it works, you are safe against some future 
change (or you know you have to change it now).

I think any site that doesn't allow Frank's example won't allow ENTRY either. 
There was mention of "copying up the line". I think in olden days, IEBCOPY 
would "loose" the ALIAS, I seem to remember having to re-ALIAS things.

Frank, one PROCESS NAME is enough (can also be supplied on the PARM (or a CBL).

--
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: Question about the COBOL compiler

[Frank Swarbrick]

I am personally annoyed that we even have to have two separate compile procs; 
one for batch and one for CICS.  I would like to be able to just have PROCESS 
CICS on a CICS program and have the necessary program binder statements 
generated automatically.  It would probably have to generate proper INCLUDE 
statements to statically link the CICS 'stubs', etc.

If I want to build a DLL I include PROCESS DLL.  Etc.


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question about the COBOL compiler

If you don't know what harmful things there are, consult the 
Binder/Linkage-editor manual. Like compiling this program and linking it as 
another, for a simple one.

It is rare that IBM ask me anything (although it did happen once, if IBM can be 
thought of as one person who works for IBM).

Even if you no longer want arbitrary, but limited binder/linke-editor control 
cards...

Most people won't want the flexibility because they will have distinct was to 
process distinct types of programs. You don't have a program you want to use as 
a DLL, then poke it through a CICS process, and hope to be able to tidy it up 
at the end. You have a "this is how you do a DLL" process.

Note, it is possible to prevent the use of CBL/PROCESS cards, and possible to 
"nail-in" compiler installation options (by option).

For many sites, reliable compiler output gives them far more flexibility, 
perhaps?

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

Another COBOL question

[Bill Woodger]

Interesting about the NAME. All the options should apply to all of the source. 
Also, a loose PROCESS card like that doesn't seem to be documented (at least in 
the obvious place).

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

Re: Another COBOL question

[Frank Swarbrick]

I'm not sure I would agree that PROCESS options should apply to all of the 
source.  I might, for example, want the first program to have PROCESS NODYNAM 
so it will do a static call of the second program.  But I might want the second 
program to have PROCESS DYNAM.


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 5, 2016 11:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Another COBOL question

Interesting about the NAME. All the options should apply to all of the source. 
Also, a loose PROCESS card like that doesn't seem to be documented (at least in 
the obvious place).

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

ibm afp print driver for windows 10

[Tim Brown]

Not sure if this is proper forum, looking for IBM AFP Print Driver that 
supports Windows 10
The last one I had worked on Windows 7.

Tim Brown
Central Hudson Gas & Electric

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

Re: ibm afp print driver for windows 10

[Nims,Alva John (Al)]

You might try the AFP list:
mailto:af...@listserv.uga.edu

or https://listserv.uga.edu/cgi-bin/wa?A0=AFP-L

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tim Brown
Sent: Friday, August 05, 2016 2:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ibm afp print driver for windows 10

Not sure if this is proper forum, looking for IBM AFP Print Driver that 
supports Windows 10 The last one I had worked on Windows 7.

Tim Brown
Central Hudson Gas & Electric

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

SYNCSORT S0C4 - What am I doing wrong please?

[Farley, Peter x23353]

Hi All,

I have managed to get Syncsort to abend S0C4 with what I thought would be a 
simple copy-select-reformat operation using the PARSE operand on an OUTREC 
statement.

If anyone can tell me if my control cards are causing the issue I would 
appreciate it.  This is my first time trying to use the PARSE operand.

If not I will have to contact Syncsort Support on Monday (I have to go through 
z/OS systems folk to get support and this isn't a production issue so I can't 
justify using the on-call list).

My JCL and control cards are below.  The SORTIN file is RECFM=FBA,LRECL=133:

//REFORMAT EXEC PGM=SORT,PARM='EQUALS,MSDDD=SORTLIST'
//SORTLIST  DD SYSOUT=*
//SYSUDUMP  DD SYSOUT=*
//SORTINDD DISP=SHR,DSN=&SYSUID..INPUT.FILE
//SORTOUT   DD DISP=(NEW,CATLG,CATLG),
// DSN=&SYSUID..OUTPUT.FILE,
// UNIT=SYSDA,SPACE=(CYL,(5,5),RLSE),
// DSORG=PS,RECFM=FB,LRECL=080,BLKSIZE=0
//SYSIN DD *
 OPTION COPY
 INCLUDE COND=(1,1,CH,EQ,C' ',AND,33,6,CH,EQ,C'(NONE)')
 OUTREC PARSE=(%00,STARTAFT=BLANKS,ENDAT=BLANKS,FIXLEN=8),
BUILD=(%00,72X)
//*

SORTLIST output is as follows (masked):

SYNCSORT FOR Z/OS  2.1.2.0NU.S. PATENTS: 4210961, 5117495   (C) 2014 
SYNCSORT INC.   DATE=2016/218   TIME=18.28.57
   MY COMPANY   z/OS   2.1.0
SYNCSORT LICENSED FOR CPU SERIAL NUMBER X, MODEL  XXX 
LICENSE/PRODUCT EXPIRATION DATE: 01 JUN 2017
SYSIN :
 OPTION COPY
 INCLUDE COND=(1,1,CH,EQ,C' ',AND,33,6,CH,EQ,C'(NONE)')

TIA for any help you can provide.

Peter


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: SYNCSORT S0C4 - What am I doing wrong please?

[Sri h Kolusu]

Peter,

The syntax for Parse looks a bit off. I am not sure about the syntax of 
parse for syncsort but that is not a valid DFSORT syntax.

Try these control cards and see if it works. The changes are highlighted 
in blue

//SYSINDD * 
   OPTION COPY 
   INCLUDE COND=(1,1,CH,EQ,C' ',AND,33,6,CH,EQ,C'(NONE)') 
   OUTREC PARSE=(%00=(STARTAFT=BLANKS,ENDAT=BLANKS,FIXLEN=8)),
  BUILD=(%00,72X) 
//* 


Thanks,

Kolusu




From:   "Farley, Peter x23353" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/05/2016 03:47 PM
Subject:SYNCSORT S0C4 - What am I doing wrong please?
Sent by:IBM Mainframe Discussion List 



Hi All,

I have managed to get Syncsort to abend S0C4 with what I thought would be 
a simple copy-select-reformat operation using the PARSE operand on an 
OUTREC statement.

If anyone can tell me if my control cards are causing the issue I would 
appreciate it.  This is my first time trying to use the PARSE operand.

If not I will have to contact Syncsort Support on Monday (I have to go 
through z/OS systems folk to get support and this isn't a production issue 
so I can't justify using the on-call list).

My JCL and control cards are below.  The SORTIN file is 
RECFM=FBA,LRECL=133:

//REFORMAT EXEC PGM=SORT,PARM='EQUALS,MSDDD=SORTLIST'
//SORTLIST  DD SYSOUT=*
//SYSUDUMP  DD SYSOUT=*
//SORTINDD DISP=SHR,DSN=&SYSUID..INPUT.FILE
//SORTOUT   DD DISP=(NEW,CATLG,CATLG),
// DSN=&SYSUID..OUTPUT.FILE,
// UNIT=SYSDA,SPACE=(CYL,(5,5),RLSE),
// DSORG=PS,RECFM=FB,LRECL=080,BLKSIZE=0
//SYSIN DD *
 OPTION COPY
 INCLUDE COND=(1,1,CH,EQ,C' ',AND,33,6,CH,EQ,C'(NONE)')
 OUTREC PARSE=(%00,STARTAFT=BLANKS,ENDAT=BLANKS,FIXLEN=8),
BUILD=(%00,72X)
//*

SORTLIST output is as follows (masked):

SYNCSORT FOR Z/OS  2.1.2.0NU.S. PATENTS: 4210961, 5117495   (C) 2014 
SYNCSORT INC.   DATE=2016/218   TIME=18.28.57
   MY COMPANY   z/OS   2.1.0
SYNCSORT LICENSED FOR CPU SERIAL NUMBER X, MODEL  XXX 
LICENSE/PRODUCT EXPIRATION DATE: 01 JUN 2017
SYSIN :
 OPTION COPY
 INCLUDE COND=(1,1,CH,EQ,C' ',AND,33,6,CH,EQ,C'(NONE)')

TIA for any help you can provide.

Peter


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

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






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

Re: ibm afp print driver for windows 10

[Roger Bolan]

On this page: http://www-01.ibm.com/support/docview.wss?uid=nas8N1018815
I found this:

> The Ricoh Production Print Solutions AFP Printer Driver for Windows is
> available on the InfoPrint Solutions web site at:
>
> *http://www.infoprint.com/internet/dcfdata.nsf/vwWeb/P4000384*
> 
>
> This version of the AFP printer driver contains a supports the following
> operating systems:
>
> Windows 7, Windows 8.1, Windows Server 2008, Windows Server 2012, Windows
> Vista, Windows XP
>

but no mention yet of Windows 10.

Regards,
--Roger

On Fri, Aug 5, 2016 at 12:42 PM, Tim Brown  wrote:

> Not sure if this is proper forum, looking for IBM AFP Print Driver that
> supports Windows 10
> The last one I had worked on Windows 7.
>
> Tim Brown
> Central Hudson Gas & Electric
>
> --
> 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: SYNCSORT S0C4 - What am I doing wrong please?

[Farley, Peter x23353]

Thank you Sri, that PARSE syntax was the problem.  I can execute the reformat 
successfully now.

I'll report the S0C4 as an issue to Syncsort, incorrect syntax should certainly 
not result in abends.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Friday, August 05, 2016 7:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT S0C4 - What am I doing wrong please?

Peter,

The syntax for Parse looks a bit off. I am not sure about the syntax of parse 
for syncsort but that is not a valid DFSORT syntax.

Try these control cards and see if it works. The changes are highlighted in blue

//SYSINDD * 
   OPTION COPY 
   INCLUDE COND=(1,1,CH,EQ,C' ',AND,33,6,CH,EQ,C'(NONE)') 
   OUTREC PARSE=(%00=(STARTAFT=BLANKS,ENDAT=BLANKS,FIXLEN=8)),
  BUILD=(%00,72X)
//* 


Thanks,

Kolusu
--

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

Some confusion about SVC99, DALRTDDN and existing allocations.

[Thomas David Rivers]

Trying to write a program that lets the system do a DYNALLOC (SVC99)
and hands me back the system-assigned DD name to use in the DCB for
an OPEN via the DALRTDDN text-unit in the SVC99.

In this case; I'm actually trying to point to a PDS and will be reading 
a member.


This is well and good; works great if I don't have that PDS allocated to
another DD; DYNALLOC hands me a wonderful SYS DD name which
I plop down in the DCB, do the OPEN and a FIND and read the member.

However...

If I'm under TSO; and I allocate another DD to point to my PDS, with,
say:

 ALLOC DA(MYDD) DS(MY.PDS) SHR

then when my program does the DYNALLOC (SVC99) the DD name I get
back in the DALRTDDN area is 'MYDD' (not the expected SYSn.)

Furthermore; the return code (R15) from DYNALLOC is 0, and the values
of S99EERR and S99EINFO in the S99RBX are zero as well; and I've verified
that the S99RBX is correctly being addressed from the S99RB.

My program then proceeds to do an OPEN with that DD; which works fine 
(RC=0.)


It then proceeds to do a FIND which returns with a return-code (R15) of 8
and reason-code (R0) of 8.

The Text-Units I'm using on the DYNALLOC are:

  DALRTDDN (X'0055')
  DALDSNAM (X'0002')
  DALSTATS   (X'0004')  with a value of X'08'  (SHR)
  DALNDISP   (X'0005')  with a value of X'02'   (CATALOG)
  DALRLSE (X'000D')


My questions are:

 Why would DYNALLOC hand me back a DD name from a different allocation
in the DALRTDDN area, instead of making up a new one?

 Furthermore, why would DYNALLOC hand me a DD name that can't work
and give me a return code 0, with all the fields in the S99RB _and_ S99RBX
also indicating 0?  DYNALLOC clearly thinks this is a find DD name to use;
so why can't it use it?

 Could my superfluous specification fo CATALOG and RELEASE be causing
the problems?

  - Many thanks for any helpful pointers -
 - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: Some confusion about SVC99, DALRTDDN and existing allocations.

[Webster, Chris]

Dave,

You may need to ask for a new allocation.  Reuse rules are tangled and do not 
always work as expected - don't remember all the details off hand but the doc 
does provide some info.

s99rbptr->s99flg11 |= S99NOCNV;

Not assembler but I think you understand it. :-)

Not sure I would use release TU unless requested.

...chris.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas David Rivers
Sent: Friday, August 05, 2016 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Some confusion about SVC99, DALRTDDN and existing allocations.

Trying to write a program that lets the system do a DYNALLOC (SVC99) and hands 
me back the system-assigned DD name to use in the DCB for an OPEN via the 
DALRTDDN text-unit in the SVC99.

In this case; I'm actually trying to point to a PDS and will be reading a 
member.

This is well and good; works great if I don't have that PDS allocated to 
another DD; DYNALLOC hands me a wonderful SYS DD name which I plop down in 
the DCB, do the OPEN and a FIND and read the member.

However...

If I'm under TSO; and I allocate another DD to point to my PDS, with,
say:

  ALLOC DA(MYDD) DS(MY.PDS) SHR

then when my program does the DYNALLOC (SVC99) the DD name I get back in the 
DALRTDDN area is 'MYDD' (not the expected SYSn.)

Furthermore; the return code (R15) from DYNALLOC is 0, and the values of 
S99EERR and S99EINFO in the S99RBX are zero as well; and I've verified that the 
S99RBX is correctly being addressed from the S99RB.

My program then proceeds to do an OPEN with that DD; which works fine
(RC=0.)

It then proceeds to do a FIND which returns with a return-code (R15) of 8 and 
reason-code (R0) of 8.

The Text-Units I'm using on the DYNALLOC are:

   DALRTDDN (X'0055')
   DALDSNAM (X'0002')
   DALSTATS   (X'0004')  with a value of X'08'  (SHR)
   DALNDISP   (X'0005')  with a value of X'02'   (CATALOG)
   DALRLSE (X'000D')


My questions are:

  Why would DYNALLOC hand me back a DD name from a different allocation  in the 
DALRTDDN area, instead of making up a new one?

  Furthermore, why would DYNALLOC hand me a DD name that can't work  and give 
me a return code 0, with all the fields in the S99RB _and_ S99RBX  also 
indicating 0?  DYNALLOC clearly thinks this is a find DD name to use;  so why 
can't it use it?

  Could my superfluous specification fo CATALOG and RELEASE be causing  the 
problems?

   - Many thanks for any helpful pointers -
  - Dave Rivers -

-- 
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dignus.com&d=CwICAw&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=RI5WP1BN1KW_B4HrO2twbFFOhk97OdY6xsy0TwKReZE&m=MIgzZ5NoP2xi4t6540GWs1kHIWIyp-BeTF8NRQoy-F0&s=aVBulGqJ6LS1pS1t6CqRsWrojlUuyILA2Oz_xmkCVHk&e=
 

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