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 sugge
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-
--
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/down
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 ag
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.
, 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
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: I
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
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-
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-
---
sks 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...@
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 estab
DETACH macro from within this exit.
Sam
On Thu, Oct 16, 2014 at 11:00 AM, 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 e
That's a great idea! Thanks a bunch!
The JS can actually attach both the ORIGINAL and the SERVICE tasks, thus easily
fixing the issue at once
===
In the OP's case, he does not get control in order to issue the DETACH - the
DETACH is issued by the system when the JS
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
: How to quietly terminate not detached subtask
On 16 October 2014 14:00, Victor Gil 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 DB
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 b
But &SYSPARM can be passed to Assembler from any JES:
//
//* SUBSTITUTE VARIABLES BY ASSEMBLING 'PUNCH &SYSPARM' in
x.TEST.SOURCE(PARMTODD)
//
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'
(((*
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 par
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-SUCCESSF
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
*
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-
=
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 R
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 ca
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?
Than
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 tra
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
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
th
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
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
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
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 manageme
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 requir
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 fo
35 matches
Mail list logo
