Re: How to recreate DEFINE CLUSTER for a given VSAM file

[Victor Gil]

Thanks to everyone responded.

I was able to recreate the DEFINE using FileMaster.

-Victor-

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

How to recreate DEFINE CLUSTER for a given VSAM file

[Victor Gil]

Is there an easy way to rebuild the DEFINE CLUSTER for IDCAMS for an existing 
VSAM file?

TIA!
-Victor-

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

Re: Easiest way to share incore data between batch jobs

[Victor Gil]

I'd like to thank everyone responded to this quest. Very educational!

It looks like the team has decided to cache this file locally, i.e. in each and 
every address space accessing data, so nothing exciting is going to transpire 
this time around.

Ah, well, back to the daily routine...

Thanks again!
-Victor-

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

Re: Easiest way to share incore data between batch jobs

[Victor Gil]

Thanks Denis, an interesting approach!

Will have to do some reading as this is my "terra incognita"...

-Victor-

-
How about using Unix System Services shared memory and optionally semaphores?
 
If found this, but it uses C.
http://www.infodd.com/images/infodd/downloads/I33.pdf
 
You can also do it from COBOL with the BPX1Mxx calls (like GT for get or AT for 
Attach), it can run unauthorized in keys 2, 8 and 9.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r1.bpxb100/mgt.htm
 
Hope that helps.
Denis.

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

Re: Easiest way to share incore data between batch jobs

[Victor Gil]

ITschak,

Really like this idea, could you please elaborate a bit - how would a 
problem-state program load data in common area? It needs to be store-protected 
to prevent overlays, so that would require the loader to be APF authorization, 
no?

-Victor- 

--
If your interest is sharing, CICS can store a complete vsam file in
dataspace using a standard IO routines (GET, PUT, POINT etc.). It is few
CICS parameters away and involves no code change. I am not sure that EXCI
will save you CPU or elapse. BTW, there are few products that store data in
storage and/or dataspaces (Matrix from Expanse comes to mind).
Another alternative is to store the dataset in a common area (nay be above
the bar), and store the start and end addresses in single name-token pair.
you just need a loaded program and a search one. this fits for a none
updated file.

HTH
ITschak

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

Easiest way to share incore data between batch jobs

[Victor Gil]

A co-worker suggested to save CPU by having one job to cache a VSAM file [which 
is frequently looked up by multiple jobs] and introduce a new "look up" API to 
"connect" to that job and locate a particular record with a given key.

I am a bit outdated in current systems services, so my first suggestion was to 
use EXCI into a CICS region or call a DB2 stored procedure which would act as a 
"server", but the question is - is there an easier way to accomplish this in 
pure batch?  I am familiar with the cross-memory access but this would require 
heavy assembler coding, APF authorization, etc. all of which we are trying to 
avoid.

TIA!
-Victor-

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

Re: How does COBOL detect a recursive call?

[Victor Gil]

Chuck,

Just another weird suggestion which may [or may not] work in your case - why 
can't the very SAME entry point also serve as the error handler?

I mean, it is being called with a parameter list, so by parsing the input 
parameters can't it determine the exact reason for call?

And if it's for the error handling - just take another path?

HTH,
-Victor-


==
The wherefores of using a main program and an ENTRY versus 2 programs is a 
political battle I am not prepared or willing to fight. 
When initially assigned this project I was hoping that my Systems status within 
the company would grant me some carte blanche in how I engineered the solution 
but, alas, I was mistaken. 
 
Suffice it to say, until/unless I find a technical problem to warrant the 
multiple program construct, or even the multiple programs per member construct, 
I am stuck with using the COBOL language verbs as they have been engineered. 
If, and when, they fail to function, I will have the ammunition I need to push 
for one of the other programming constructs. 
 
I do appreciate all of your narratives of what was occurring. 
 
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: COBOL 2014 dynamic capacity tables

[Victor Gil]

If the "update a table row" logic has no imbedded CICS commands it won't be 
interrupted by CICS, so the updater will have no competition, thus no 
serialization is required [I am talking about "regular" CICS tasks, dispatched 
on QTCB, not those fancy running on "open TCBs"].
However, it is required during the table re-allocation as the logic does need 
to call CICS for memory re-allocation [which may or may not cause the task to 
get re-dispatched].

Anyway, looks like you have already coded the required service.

-Victor- 

---
Because your average COBOL programmer, in my experience, knows "bupkis" abound 
dynamic memory allocation.  Perhaps I am wrong, but as far as I know I am the 
only one in our shop who ever uses it.  As for your concern about serializing 
storage between multiple concurrent tasks, I don't know of situations that 
would require this.  This is intended for use within a single run-unit.  But 
even if a table was shared between multiple tasks (within a CICS region I can 
only imagine) you have this concern with our without "dynamic tables".  You'd 
have to serialize updates in either case, so I don't see why dynamic capacity 
tables would cause any additional heartache.


Frank

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

[Victor Gil]

I am not sure why would you want the compiler to handle such a general case of 
maintaining a dynamic-size table, while this can be easily programmed by using 
the "Get heap storage" calls [LE function CEEGTST] and even encapsulated in a 
callable service.

We do this kind of dynamic table management all the time, under CICS [i.e. 
using EXEC CICS GETMAIN/FREEMAIN calls] and the main problem here  is how to 
safely re-size a table which has reached its allocated capacity. This shouldn't 
be an issue in batch where the storage is owned by a single task because it can 
just wait for the call to come back while the subroutine allocates a new larger 
size table and populates it from the old one.

So if you ask the compiler to perform such a function it would have to know how 
to serialize storage access between multiple concurrent tasks and, moreover, 
let the in-flight transactions to keep accessing the old table while the new 
one is being allocated and populated.  Pretty difficult for a general case.

-Victor-

--
Last year I submitted an RFE 
(https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=73693) 
that Enterprise COBOL be enhanced to support dynamic capacity tables as defined 
in the COBOL 2014 ISO standard.  It was declined: "Thank you for bringing this 
RFE to our attention. But we believe that if implemented, it will be really 
slow and error prone.Some clients may have restrictions on using this. This 
is not in our multi-year strategy. Hence, we'll have to reject this RFE."


Since the year has passed I have resubmitted the RFE, now with the following 
comments that I hope might address IBM's concerns:


"This RFE was declined based on concerns about performance.I would like to 
submit the following possibilities for consideration:

Would IBM be more amenable to a partial implementation? while you did not 
indicate in the declined RFE what performance issues you foresee,I can 
hazzard some guesses.One is the requirement in the standard is 8.5.1.6.3.2 
Implicit changes in capacity: "When a data item in a dynamic-capacity table is 
referenced as a receiving item and the value of the subscript exceeds the 
current capacity of the table, a new element is automatically created and the 
capacity of the table is increased to the value given by the subscript. If this 
new capacity is more than one greater than the previous
capacity, new intermediate occurrences are implicitly created."I believe 
this would require a runtime check in each of these cases to see if the 
subscript is greater than the current capacity, and if so to increase the 
current capacity.

The current capacity can also be increased explicitly.8.5.1.6.3.3 states 
"If the OCCURS clause specifies a CAPACITY phrase, the capacity of the 
dynamic-capacity table may be increased or decreased explicitly by means of the 
dynamic-capacity-table format SET statement."The "implicit changes" was one 
of the arguments I've seen against implementation of dynamic capacity tables, 
with the concern that one might have a bug that set a subscript to an incorrect 
and possibly very large value, which would cause the table to be increased to 
that value "improperly".

So why not eliminate that requirement as part of the implementation?I can't 
see any problem with a simple "SET tbl-capacity UP BY 1" when intentionally 
adding a new row to the table.


One other feature I can see that could be bypassed, at least initially, would 
be the behavior of the MOVE of a group containing a dynamic capacity table.
Because a d.c. table would most likely not be "physically contiguous" with the 
rest of the items in the table, a MOVE of the entire group would at the very 
least be "less efficient".So how about a restriction that you can't do a 
group MOVE where the group contains one or more dynamic capacity tables?I 
don't see too many uses cases where this would cause an issue, and if we can 
get implementation of the most important features, that is better than nothing 
at all?"


I still believe this would be one of the most useful enhancements that COBOL 
could have.  Please vote if you agree.  (There is also a similar SHARE 
requirement.)


My resubmitted RFE: 
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=92391

Share Requirement: http://www.share.org/index.php?mo=is=vi=67=23


Frank Swarbrick

Principal Analyst, Mainframe Applications

FirstBank -- Lakewood, CO USA

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

Re: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Victor Gil]

No, subtract 8-16 bytes from the area address to get to the header...

I guess my usage of the words "top" and "ABOVE" could be misleading - this is 
how we were drawing memory maps back in the 70s, so that they grow DOWN from 
the staring location


On Fri, 22 Jul 2016 08:53:54 -0500, Victor Gil wrote:

>I am guessing the length may be stored somewhere in the vicinity of the area 
>top address, say within 8-16 bytes ABOVE it.
> 
So to get to it you just add the length of the area to the address of the area?

>At least this is how CICS handles GETMAIN requests which also don't require 
>length on the FREEMAINs.
>
>Of course, if the convention is not documented it may change at any time ...

-- gil

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

Re: OS ENQ from COBOL

[Victor Gil]

There is a weird way to embed subroutines in machine instructions right into 
Cobol code by:

a) defining them [fully assembled] as a WORKING-STORAGE literal
b) setting address of a PROCEDURE-POINTER to address of that literal
c) calling the PROCEDURE-POINTER

And no, I don't recommend you actually use this approach, unless really 
desperate.

-Victor-  


Hello Listers,

First off, does anyone know of an IBM COBOL related list? If so, could you 
point me in that direction.

Now, to my question.

I can code an assembler solution, or even a hybrid COBOL/Assembler solution, 
but what I would truly love would be a COBOL only solution.
My need is to be able to determine if a QNAME/RNAME combination is held by 
another address space in the system.
Stated another way, is there any way to use an "ENQ 
(QNAME,RNAME,S,SYSTEM),REQ=TEST" from a COBOL program using COBOL only 
procedural statements?

As I said, I can code an assembler program to issue the ENQ, but because I may 
not always be the one supporting the code, I need to keep it in a language most 
of our shop knows.

In another direction, is there an LE service routine that could issue the ENQ 
TEST?

Thanks to All,
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

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

Re: AW: Re: Interface to query length of storage allocated with CEEGTST LE service

[Victor Gil]

I am guessing the length may be stored somewhere in the vicinity of the area 
top address, say within 8-16 bytes ABOVE it.

At least this is how CICS handles GETMAIN requests which also don't require 
length on the FREEMAINs.

Of course, if the convention is not documented it may change at any time ...

-Victor-

=
> I very much doubt it.


Yeah, me too. But I thought I might be missing something and better ask. 


>I'm curious; what will you do with this info if it is available? 
 

I'm asking because I have been asked by our middle war guys. Our applications 
are required to use our own middle ware service routines for certain functions 
instead of HLL or LE or CICS services directly. (This is not part of the 
discussion.)


They wanted to know if there is a possibility to retrieve the length somehow 
instead of remembering it somewhere in own data structures. (I don't know more 
details about the why and what for.)


Thanks for the hint regarding LE possibly rounding up. Since I do not know 
details what they intend to do, I cannot say if this rouding is important for 
them. But I'll pass it on.




Thanks


-- 
Peter Hunkeler

 


--
Peter Hunkeler 

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

Re: Considering Enterprise COBOL 5.2 "exit" enhancements

[Victor Gil]

Yes, thanks for catching the wrong END-PERFORM, I meant to suggest this -  

PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) = 0

END-PERFORM

As far as updating parameters passed to functions - there is no real functional 
difference between passing parameters to functions vs called subroutines as 
they are both just entry names to be resolved by either the compiler or the 
linker.

And we all know that subroutines can update passed parameters [e.g. COMMAREA on 
a CICS LINK].

-Victor-

=
Indeed, Victor, you are quite correct!  And as soon as Enterprise COBOL 
supports user-written functions I will start using them!


FWIW, I don't think your code would work as-in even then, because END-PERFORM 
is only for inline performs, but you are doing an "out of line" perform.  You'd 
really have to use one of the following:


PERFORM PROCESS-MY-RECORD
UNTIL GET-NEXT-REC(NEXT-RECORD) = 0


PERFORM UNTIL GET-NEXT-REC(NEXT-RECORD) = 0

PERFORM PROCESS-MY-RECORD
END-PERFORM


The first option, even if it works, looks (to me) "a bit weird", because 
structurally it looks like PROCESS-MY-RECORD is done prior to GET-NEXT-REC(), 
so I would stick with the second option; even if its a bit more verbose.


Now that I think about it, though, I'm not sure if this would work.  The above 
assumes that function GET-NEXT-REC not only returns a result, where 0 means 
"end of file", but it also assumes that the parameter is passed by reference 
and can be updated by the function.  Are we sure the COBOL standard allows for 
that?  I'll look at some point, but not right this.


Frank

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

Re: Considering Enterprise COBOL 5.2 "exit" enhancements

[Victor Gil]

Frank,

It should be quite easy to achieve what you want by introducing user-written 
FUNCTIONs, callable by name [i.e. NOT via CALL "xyz" verb]  

Consider the below code:   

PERFORM PROCESS-MY-RECORD
UNTIL GET-NEXT-REC(NEXT-RECORD) = 0
END-PERFORM

Here GET-NEXT-REC is a FUNCTION name which returns the number of gotten records 
on a subsequent read attempt [either 0 or 1] and when successful also populates 
a passed area with the just read record.

This is how I was coding this type of logic in the old PL/I for DOS.

Unfortunately, with all new features Cobol still does not allow for such syntax 
[unless I missed the enhancement].
 
-Victor-

==
Hi, it's me.


My general thoughts are:

- This type of syntax is supported in a host of other programming languages. 
(see below for examples)

- Is it really confusing?  For me its more confusing doing all the things that 
I've done up to this point because COBOL (prior to the 2002 standard) did not 
allow me to do what I really wanted.

- I also think the elimination of procedure division SECTIONS and the 
"performing" of multiple paragraphs (PERFORM...THRU) by using these new 
features can be quite a benefit, rather than an issue.  Now will some people 
use/misuse these constructs within the context of sections and PERFORM THRU.  
Certainly.  But any programming language syntax can be misused.  That doesn't 
mean they should be eliminated (well, except for the ALTER statement, perhaps!).

- In the end, to me these new language features *enhance* structured 
programming.


https://www.rosettacode.org/wiki/Loops/Break

break: C and its followers (C++, Java, C#), Delphi, JavaScript, Ruby, Python

leave: PL/I and REXX

last: Perl

exit: Ada

EXIT PERFORM: COBOL

https://www.rosettacode.org/wiki/Loops/Continue
continue: C and its followers (C++, Java, C#), Delphi, JavaScript, Python
iterate: PL/I and REXX
next: Perl, Ruby
[not supported]: Ada
EXIT PERFORM CYCLE: COBOL


I can't find a Rosetta Code page for early exit/return from a 
procedure/function, but I believe the following are true:

return: C and its followers (C++, Java, C#), Delphi, JavaScript, Ruby, Python, 
PL/I, Rexx, Perl

EXIT PARAGRAPH / EXIT SECTION: COBOL


Should COBOL have added new keywords instead of co-opting/enhancing EXIT?  I 
don't think so.  Really, EXIT as COBOL defines it should never have existed.  
If they wanted a word to represent the end of a procedure they should have used 
the work END!  (And they did in the 85 standard support END PROGRAM, so why not 
END PARAGRAPH (too wordy, but...) and END SECTION.  Oh well!)


One of my favorite examples of the use of EXIT PERFORM is the "elimination" of 
"priming reads".  It's bugged me for 20 years (my COBOL lifetime).  To me, the 
following is ideal


PERFORM UNTIL EXIT *> Not currently part of the COBOL standard!!!  :-(

READ MY-FILE INTO MY-RECORD

AT END

EXIT PERFORM

NOT AT END

PERFORM PROCESS-MY-RECORD

END-READ

END-PERFORM


Here you have a read/process loop until such time as the read "fails", 
whereupon you exit/terminate the loop.

Unfortunately "PERFORM UNTIL EXIT" is not part of the COBOL standard (though it 
is supported as an extension by some implementations), so you have to come up 
with a dummy field that will "never be true" (in which case the compiler can 
optimize away the check), or your code can "check it twice" (once after the 
read and once at the top of the loop), which is redundant.


Those are my thoughts for now.  I have plenty more if anyone is interested.

:-)

Frank

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

Re: Verify record cound against the file trailer [by SORT?]

[Victor Gil]

Awesome, Kolusu, thanks a lot!!! 

---
It is quite simple to verify the number of records and validate it against 
the trailer record and if the record count match the return code is 0 and 
if the count is off then the return code is set to 4.

I assumed that the trailer record is not counted as part of the record 
count. If it is indeed counted then simply remove the ",START=0" on the 
INREC statement.

Use the following JCL

//STEP0100 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD * 
A 
B 
C 
D 
RECS=5 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  INREC OVERLAY=(81:SEQNUM,5,ZD,START=0) 

  OUTFIL NULLOFL=RC4, 
  INCLUDE=(1,5,CH,EQ,C'RECS=',AND, 
   (06,5,ZD,EQ,81,5,ZD)) 
//* 

The above job will end with RC=4 as there are only 4 records but the 
trailer says 5 records.

Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation

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

Verify record cound against the file trailer [by SORT?]

[Victor Gil]

I am posting this for a co-worker - some of his flat files have trailing 
records stating the total record counter, e.g.:

RECS=00567

The question is - what utility [I am guessing SORT should suffice] can he use 
to verify the trailer counter against the actual number of records in the file?

Thanks in advance!
-Victor-

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

Re: Convert a Parm into a control card

[Victor Gil]

If Cobol code is an acceptable option the below program should do what you want.

It's rather easy to enhance it to split the input parm into multiple lines, 
say, using the "JPx" delimiters, just like in the SORT sample.

HTH,
-Victor- 

000100 IDENTIFICATION DIVISION. 
000200 PROGRAM-ID.  PARM2DD.
000400**
000500* COPY INPUT PARM='...' TO OUTPARM DD 
000600**
000700 ENVIRONMENT DIVISION.
000800 CONFIGURATION SECTION.   
000900 INPUT-OUTPUT SECTION.
001000 FILE-CONTROL.
001100 SELECT OUTPUT-FILEASSIGN TO OUTPARM. 
001200 DATA DIVISION.   
001300 FILE SECTION.
001400 FD  OUTPUT-FILE  
001500 BLOCK CONTAINS 0 RECORDS 
001600 RECORDING MODE IS F. 
001700 01  OUTPUT-FILE-RECORD   PIC X(80).  
001800  
001900 WORKING-STORAGE SECTION. 
002100**
002200 LINKAGE SECTION. 
002400 01  PARM-FROM-EXEC.  
002500 05  PARM-LENGTH  PIC S9(04) COMP.
002600 05  PARM-VALUE.  
002700 10  PARM-VALUE-CHAR  PIC X OCCURS 80 TIMES   
002800DEPENDING ON PARM-LENGTH. 
002900**
003000 PROCEDURE DIVISION USING PARM-FROM-EXEC. 
003100  
003200 OPEN OUTPUT OUTPUT-FILE. 
003300  
003400 MOVE PARM-VALUE   TO OUTPUT-FILE-RECORD. 
003500 DISPLAY OUTPUT-FILE-RECORD  UPON CONSOLE.
003600 WRITE   OUTPUT-FILE-RECORD.  
003700  
003800 CLOSE   OUTPUT-FILE. 
003900 GOBACK.  


---
Hello friends!
I have a teammate working on a z/OS 1.12 system and is trying to make a
proc fairly foolproof for his user. He wants to know the easiest way to
convert a SET statement or JCL Parm into a control card.

This proc needs a DSN and a couple other values as part of a SYSIN for the
program, and since we can't use symbolics in pre-z/OS 2.1, I would like a
way using standard IBM utilities to take a PARM symbolic and create an
output file that I can use as input to the program. The parm input would
only be one line, and not longer than 50 chars.

Does anyone have any good ideas? Sort? Gener?

Thank you and best regards,
*Billy Ashton*

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

Re: Convert a Parm into a control card

[Victor Gil]

Tom,

This particular DISPLAY is not really needed for the program to function, it's 
merely a leftover from the initial testing, but "yes", we do have such DISPLAYs 
in the batch jobs and I have never heard of any rules to limit its usage. We 
may run _thousands_ jobs at a time, so I guess we also have some smart 
auto-filtering which protects the consoles but still allows to see displays in 
the JES log.

-Victor-  
 
-
On Wed, 3 Feb 2016 08:59:31 -0600, Victor Gil wrote:

>If Cobol code is an acceptable option the below program should do what you 
>want.

(snip)

>003500 DISPLAY OUTPUT-FILE-RECORD  UPON CONSOLE.

Really? Do people still use DISPLAY ... UPON CONSOLE in 2016?

Even in 1970 there were standards where I worked that didn't allow it except 
for very 
special cases that really required operator intervention. And we only had three 
regions 
on our MVT system. Today even a tiny shop typically has dozens of batch jobs 
running.

-- 
Tom Marchant

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

Re: How to quietly terminate not detached subtask

[Victor Gil]

Well, I have no experience with forking an address space, but how would the two 
communicate?  Usually, there is some sort of common shared storage which does 
require APF authorization to establish and cleanup.
 

Thanks! This would be a totally different ball game as it brings an extra 
layer of communication between the address spaces. This would also require  
extra authorization which wouldn't fly well with the management  

Yes, it requires extra communication. But it solves your problem in a clean way 
:)

I'm not sure in what sense you mean extra authorization. It does not require 
any form of system authorization (APF, supervisor state, system key), though it 
might require that the user ID that the main address space is running under has 
an OMVS identity (UNIX UID and GID) defined. But the ID may already be set up 
that way.

-- 
Walt

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

Re: How to quietly terminate not detached subtask

[Victor Gil]

Thanks! This would be a totally different ball game as it brings an extra layer 
of communication between the address spaces. This would also require  extra 
authorization which wouldn't fly well with the management  

===
Working on a general purpose callable subroutine to connect to a remote DB2 
subsystem and return values back to the caller.

Since the caller may [and WILL] have established its own DB2 connection to a 
local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, 
the subroutine must run under a different TCB.

You might consider going a bit further, and using fork() and execmvs() to 
create a new address space running your new code. That will isolate it quite 
well from the original task. And since you will not get control to signal it to 
terminate, it might do so after some period of time without hearing from you, 
say 5 minutes or whatever value you consider reasonable. 

-- 
Walt

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

Re: How to quietly terminate not detached subtask

[Victor Gil]

Not reasonable at all! 

Quoting from the DB2 manual [watch the wrap]

http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_sql_connect.dita

Successful Connection:
If the CONNECT statement is successful:
•   All open cursors are closed, all prepared statements are destroyed, and 
all locks are released from the previous application server.
•   The application process is disconnected from its previous application 
server, if any, and connected to the identified application server.
•   The actual name of the application server (not an alias) is placed in 
the CURRENT SERVER special register.
•   Information about the application server is placed in the SQLERRP field 
of the SQLCA. If the application server is an IBM® product, the information has 
the form pppvvrrm,
...

==
Sounds very reasonable. I would certainly think so.

I am way less than a DB2 expert but I don't think any cursor type information 
is maintained in any sort of magic control block. Even a single simple COBOL 
program can be doing multiple logically independent things at the same time.

There is a list where the people who actually are DB2 experts hang out: 

http://www.idug.org/p/fo/et/topic=19 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Friday, October 17, 2014 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to quietly terminate not detached subtask

On 16 October 2014 14:00, Victor Gil victor@broadridge.com wrote:
 Working on a general purpose callable subroutine to connect to a remote DB2 
 subsystem and return values back to the caller.

 Since the caller may [and WILL] have established its own DB2 connection to a 
 local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, 
 the subroutine must run under a different TCB.

I've been pondering these task matters, but it strikes me that this may be 
entirely the wrong approach. I don't know DB2, but I'd be a little surprised if 
it keeps track of connection attributes (cursors, locks, etc.) only at the TCB 
level, and doesn't have any mechanism to maintain independent connections at a 
lower level. Surely there is some kind of object or control block or the like 
that can be instantiated more than once in an MVS task that can represent these 
things. Is it not possible, e.g, for a server to handle multiple users each 
with their own connection to DB2 using a single TCB?

Tony H.

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

How to quietly terminate not detached subtask

[Victor Gil]

Hi everyone,

Working on a general purpose callable subroutine to connect to a remote DB2 
subsystem and return values back to the caller.

Since the caller may [and WILL] have established its own DB2 connection to a 
local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, 
the subroutine must run under a different TCB.

I have no problems attaching a subtask on a first call and connecting from it 
to a remote subsystem, but I cannot force the caller [because this would mean 
massive change to the existing source code] to also call me with the 
end-of-job request, so that I can properly detach the subtask.

And if it is not detached the main task will surely get abended. [By the way - 
can't this get trapped by an ESTAE(X) and converted into RC=0?] 

Given the above scenario - does anyone have a suggestion on how to quietly 
terminate both tasks without the detach?  Or maybe a suggestion on ANOTHER way 
of implementing the required functionality?

Many thanks in advance!
-Victor Gil-

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

Re: How to quietly terminate not detached subtask

[Victor Gil]

The 1st task is NOT my code, but it would CALL my service which would attach a 
subtask. This one will be totally under my control
===
Is the 1st task, the one with the existing DB2 connection, your task?  
Do you have control of it, or is your code running on a tcb that is not 
your code?
On 10/16/2014 1:00 PM, Victor Gil wrote:
 Hi everyone,

 Working on a general purpose callable subroutine to connect to a remote DB2 
 subsystem and return values back to the caller.

 Since the caller may [and WILL] have established its own DB2 connection to a 
 local DB2 subsystem, possibly with some cursors open and DB2 locks acquired, 
 the subroutine must run under a different TCB.

 I have no problems attaching a subtask on a first call and connecting from it 
 to a remote subsystem, but I cannot force the caller [because this would mean 
 massive change to the existing source code] to also call me with the 
 end-of-job request, so that I can properly detach the subtask.

 And if it is not detached the main task will surely get abended. [By the way 
 - can't this get trapped by an ESTAE(X) and converted into RC=0?]

 Given the above scenario - does anyone have a suggestion on how to quietly 
 terminate both tasks without the detach?  Or maybe a suggestion on ANOTHER 
 way of implementing the required functionality?

 Many thanks in advance!
 -Victor Gil-

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

Re: How to quietly terminate not detached subtask

[Victor Gil]

Thanks, but the EXTR handles termination of the SUBTASK being attached, not the 
MAIN task   

Hi Victor - Look at the EXTR parameter in the ATTACH(X) documentation.
This end-of-task exist gets control on normal and abnormal end-of-task.

You can issue the DETACH macro from within this exit.

Sam

On Thu, Oct 16, 2014 at 11:00 AM, Victor Gil victor@broadridge.com
wrote:

 Hi everyone,

 Working on a general purpose callable subroutine to connect to a remote
 DB2 subsystem and return values back to the caller.

 Since the caller may [and WILL] have established its own DB2 connection to
 a local DB2 subsystem, possibly with some cursors open and DB2 locks
 acquired, the subroutine must run under a different TCB.

 I have no problems attaching a subtask on a first call and connecting from
 it to a remote subsystem, but I cannot force the caller [because this would
 mean massive change to the existing source code] to also call me with the
 end-of-job request, so that I can properly detach the subtask.

 And if it is not detached the main task will surely get abended. [By the
 way - can't this get trapped by an ESTAE(X) and converted into RC=0?]

 Given the above scenario - does anyone have a suggestion on how to quietly
 terminate both tasks without the detach?  Or maybe a suggestion on ANOTHER
 way of implementing the required functionality?

 Many thanks in advance!
 -Victor Gil-

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

Re: AS400 iSeries connecting to z/OS

[Victor Gil]

Thanks to everyone responded.

The question was posted on behalf of our AS400 team so I don't know the 
specifics and will follow up as soon as I get them.

[Although RPG has been mentioned as one of the development languages]

Thanks again!
-Victor-

---
We may need to enable batch jobs running on AS400 to SYNCHRONOUSLY
access data residing on the mainframe [say, on DB2 or on a VSAM
file].

We might need a bit more information here. What is the runtime for these
batch jobs? (There's more than one choice on IBM i.) Are these RPG
programs? COBOL? Java, e.g. WebSphere Application Server batch programs on
IBM i? Are these in house batch programs that you wrote, with source code
that you maintain? Or vendor-supplied programs that access data a certain
way (e.g. DB2 for IBM i)? Or some of each?

If you could elaborate just a bit on what batch jobs means here, that'd
be great. The answer(s) depend in part of what sort of batch jobs are
involved.


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

AS400 iSeries connecting to z/OS

[Victor Gil]

Gents,

We may need to enable batch jobs running on AS400 to SYNCHRONOUSLY access data 
residing on the mainframe [say, on DB2 or on a VSAM file].

Is anyone doing this and if yes what would be the recommended methods?

TIA!
-Victor-

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

Re: SYSIN in PROC -- technique

[Victor Gil]

But SYSPARM can be passed to Assembler from any JES:

//
//* SUBSTITUTE VARIABLES BY ASSEMBLING 'PUNCH SYSPARM' in 
x.TEST.SOURCE(PARMTODD)  
//
// SET PPP=your variable string
//ASM   EXEC PGM=ASMA90,PARM=('SYSPARM(PPP)')
//SYSIN  DD  DSN=x.TEST.SOURCE(PARMTODD),DISP=SHR 
//SYSUT1DD  SPACE=(4096,(2,2)),UNIT=VIO
//SYSLIB DD  DSN=SYS1.MACLIB,DISP=SHR   
//SYSPRINT DD  SYSOUT=*   
//SYSLIN DD  UNIT=VIO,DISP=(,PASS),SPACE=(TRK,(1,1)),
//  DCB=(BLKSIZE=80,LRECL=80,RECFM=FB)  
//...
//*next Step SYSIN
SYSINDD DISP=(OLD,DELETE),DSN=*.ASM.SYSLIN 


HTH,
-Victor-

===
Be aware, use of system symbols in JCL is supported in JES2 in z/OS 2.1, NOT 
JES3.

Sean M. Smith
OSS Program Products


SNIPPED

From:   Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@listserv.ua.edu, 
Date:   08/04/2013 03:09 PM
Subject:SYSIN in PROC -- technique
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu

I just discovered I can do such as:

//SOURCE   PROC
//CEXEC  PGM=ASMA90
//SYSIN DD   *  For caller to override.
//  DD   *  Main body of code
 MACRO
TESTIT   CSECT
 ...
 END
// PEND

... and the caller can (optionally) provide an overriding prelude SYSIN 
containing various ACONTROL and SETC instructions to govern the rest of the 
processing.  Could be very useful for storing tailorable SYSIN in a PROCLIB.

Will be even better with symbol substitution in 2.1.

-- gil

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

Re: Is there a reverse bits hardware instruction?

[Victor Gil]

Here's a single DC instruction I've posted May 2003 [search for what's your 
most difficult assembler concept]

BYTE_FLIP DS 0CL256
TDC 256AL1*-T)/001)-((*-T)/002)*2)*X'80'
   (((*-T)/002)-((*-T)/004)*2)*X'40'
   (((*-T)/004)-((*-T)/008)*2)*X'20'
   (((*-T)/008)-((*-T)/016)*2)*X'10'
   (((*-T)/016)-((*-T)/032)*2)*X'08'
   (((*-T)/032)-((*-T)/064)*2)*X'04'
   (((*-T)/064)-((*-T)/128)*2)*X'02'
   (((*-T)/128)-((*-T)/256)*2)*X'01')  

HTH,
-Victor-

---
The macro at the end of my reply will generate a reverse translate table. I
tested it enough to see that it looked right but it has nothing to do with
my original point. I've found this discussion interesting and it has given
me reason to play with something other than the complex process I'm working
on now. My original point, as was taken by Charles, was that I prefer
automatic processes to generate anything but the simplest translate tables.
I prefer to do it in a program and copy it from a dump into a program
because the table is static. I don't need to generate it every time I
assemble.

In regards to TROO, the original problem was stated as translating a 64 bit
register. A STG, TR for 8 bytes, followed by a LRVG will more than suffice.
Though, I find your argument about the use of a TRTRE to simulate a FROGR
interesting.  It brings the whole bit reversal into perspective. I'm not a
big fan of translate instructions (I use them often enough), particularly
those that require facilities and facility enhancements,  unless you're
translating long strings and are willing to test the facility bits. I'm
sure that the translation and parsing facilities exist on most customer's
boxes by now but I emphasize most.  When I awakened this morning, I wrote
an algorithm to do a load reverse bytes and bits using FLOGR to drive the
process. I'm going to give the idea of a FROGR simulation more thought and
continue this exercise later.

MACRO
LABEL  REVTABLE ,
* Construct reverse bits translate table
LCLA I,J,K,L,M,N,O
LCLC X
LABEL  DS   0DLIKE EM DOUBLE WORD ALIGNED
I  SETA 0 STARTING VALUE
.TABLOOP ANOP  LOOP UNTIL TABLE IS DONE
K  SETA 1 NEED SIXTEEN ENTRIES PER LINE
X  SETC   'AL1('
AGO.X16LP
.X16NXT ANOP
X  SETC   'X'.'J'.','
.X16LP  ANOP   16 ENTRY LOOP
J  SETA 0 STARTING RESULT
L  SETA 1 STARTING ADDEND
M  SETA 1 8 BITS PER BYTE
N  SETA 128   STARTING COMPARAND X'80'
O  SETA ICOPY CURRENT BYTE TO REVERSE
.BYTELP ANOP
AIF  (O LT N).BYTEFT LESS THAN CURRENT - 0
O  SETA O-N
J  SETA J+L
.BYTEFT ANOP
L  SETA L*2   NEXT ADDEND
N  SETA N/2   NEXT COMPARAND
M  SETA M+1   NEED EIGHT BITS
AIF  (M LE 8).BYTELP
I  SETA I+1
K  SETA K+1
AIF  (K LE 16).X16NXT
X  SETC 'X'.'J'.')'
DC   X
AIF  (I LT 256).TABLOOP
MEND

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

Re: Q re attaching COBOL program

[Victor Gil]

Because these programs connect to DB2 using *different* front ends for 
call-attachment facility [not to mention different DB2 plans and different ways 
the plan names are determined during run time].  So, each program essentially 
needs its own DB2 connection.

-Victor-


===
I'm just curious.  Why do you need to ATTACH the program 
if it is not to run asynchronously?

-- 
Tom Marchant

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

Re: Q re attaching COBOL program

[Victor Gil]

Answering my own question [for the archives] - LE expects a COBOL MAIN entry 
[subtasked or not] to be invoked via the EXEC PARM=... convention.

So, in the Assembler middleman I had to take the original pointer in R1 and 
save it as the only passing parm in an EXEC_PARMS area, then Attach with R1 
pointing to A(EXEC_PARMS).  The opposite conversion into the CALL pgm USING 
parms format is taking place in the COBOL MAIN stub.  Unfortunately, the 
COBOL stub needs to know the NUMBER of such parameters to be able to issue a 
respective CALL, so for now I am settling just for one such parm.

-Victor-

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

Re: Q re attaching COBOL program

[Victor Gil]

Joe, thanks for the post.

When a caller calls COB#SYNC it indeed passes 2 parms, but the first one is 
just a name of the program to attach, so it's internal to COB#SYNC logic.

The second parm is the one actually passed to the subtask on the ATTACH, so it 
does match the PROCEDURE USING on the callee.  As was explained in a prior post 
such parm has to conform to the EXEC PARM='...' convention.

-Victor-  


Hello:  When a COBOL CALL or ENTRY is compiled, each item in the USING is used 
to create code to process a parameter list of full words equal in number to the 
number of items in that USING clause.  So the CALL parameter list will have two 
full words.  The ENTRY code will only process one full word.  

So, the CALL to COB#SYNC builds two fullwords of addresses, but the PROCEDURE 
DIVISION USING is only going to load one BLL cell.  The BLL cell for item 
TPTAPI-COMMAREA will be loaded with the address of the caller's item WS-TPTAPI. 
 The second item WS-TPTAPI-COMMAREA is not addressible by the subroutine 
(unless the second item is contiguous in storage to WS-TPTAPI and the 
TPTAPI-COMMAREA item describes both areas, a somewhat unorthodox way of passing 
parameters).

I would have coded two items in the subroutines ENTRY USING clause. 

CALL-TPTAPI.   
 
DISPLAY WS-TPTAPI-COMMAREA   
CALL COB#SYNC  USING WS-TPTAPI 
   WS-TPTAPI-COMMAREA.   
  -  -  -  -  -  -  -  -  -  -  -  -  -  2 Line(s) no
DISPLAY WS-TPTAPI-COMMAREA.  


The subroutine's PROCEDURE USING:

PROCEDURE DIVISION USING TPTAPI-COMMAREA. 

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

Q re attaching COBOL program

[Victor Gil]

We have a need to call a COBOL subroutine by attaching it as a subtask, so the 
call is done through an Assembler stub that issues the Attach, Waits on the 
termination ECB and Detaches the subtask.

The subroutine gets the parms, does what it's job and returns back with an RC 
field which is a part of the passed structure.

However, the caller *does not* see this RC!

Is the LE making a local copy of the parms? And if yes - how to workaround this 
issue?

TIA,
-Victor-  

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

Re: Q re attaching COBOL program

[Victor Gil]

As I said, the subroutine response via a field in the passed comarea.
The commarea is just ONE parm and the resopnse field is part of the commarea, 
not the RETURN REGISTER

03  TPTAPI-RETURN-PARAMETERS.   
05  TPTAPI-RETURN-CODE   PIC  X(02).
88  TPTAPI-SUCCESSFULVALUE '00'.
88  TPTAPI-WARNING   VALUE '04'.
88  TPTAPI-INVALID-PARM  VALUE '08'.


-Victor-

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

Re: Q re attaching COBOL program

[Victor Gil]

Well, if you're anxious to see the code, here it is -

COB#SYNC ATENTRY 'Run ASYNC task from COBOL',TRACE=NO
*   
 ST   R1,R1_ON_ENTRY
*   
 LA   R4,DYN_PCT
   USING MTCT_TASK,R4   
 LR5,0(,R1)  -- FIRST PARM = PROGRAM NAME  
 MVC  MTCT_TASK_PROG,0(R5) 
-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  - 10 Line(s) not Displayed 
 MVC  DYN_ATCH(L_ATCH_LST),ATCH_LST 
 XC   MTCT_TASK_TECB,MTCT_TASK_TECB 
 LA   R2,MTCT_TASK_TECB 
 LA   R15,DYN_ATCH  
 LA   R1,4(0,R1)  PASS THE REST OF PARMS
*   
 ATTACH EPLOC=MTCT_TASK_PROG,  X
   ECB=(R2),   X
   SZERO=NO,   X
   SF=(E,(R15)) 
*   
 LTR  R15,R15 DID ATTACH WORK?  
 BZ   ATTACHEDYES - 
   LOG$MSG 'Unable to Attach . Abending...',MTCT_TASK_PROG  
 DC  H'0'   
*   
ATTACHED DC 0H  
 STR1,MTCT_TASK_TCB   SAVE TCB  
 UNPK  DWORK(9),MTCT_TASK_TCB(5)
 MVZ   DWORK,ZONE_ZERO  
 TRDWORK,HEXTAB 
LOG$MSG 'Prog  Attached. TCB=',X
   MTCT_TASK_PROG,DWORK 
*   
 LA   R2,MTCT_TASK_TECB 
 WAIT 1,ECB=(R2)
*   
LOG$MSG 'Prog  terminated',MTCT_TASK_PROG   
*   
DETACH  MTCT_TASK_TCB   
*   
 B   COB#SYNC_EXIT   


The call in COBOL caller follows. Notice that the commarea gets displayed 
before and after the call [this is how we know that the response is NOT passed 
back] 

CALL-TPTAPI. 
 
DISPLAY WS-TPTAPI-COMMAREA   
CALL COB#SYNC  USING WS-TPTAPI 
   WS-TPTAPI-COMMAREA.   
  -  -  -  -  -  -  -  -  -  -  -  -  -  2 Line(s) no
DISPLAY WS-TPTAPI-COMMAREA.  


The subroutine's PROCEDURE USING:

PROCEDURE DIVISION USING TPTAPI-COMMAREA.

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