working storage values

Have vendor started task that runs constantly while listening on port
1205.  This started task has a loadlib with user written cobol
programs.  This started task also has a control file (jcl ddname)
with a record.  For performance reasons, I only want to read the
record one time only.  How should I code the cobol program  so that
the working storage values are retained between calls.

I can't statically link the vendor program with my program.....

"yoqi99" <yoqi99@gmail.com> wrote in message
news:18bff75d-832d-4089-a301-1b5162d5eed4@a35g2000prf.googlegroups.com...
> Have vendor started task that runs constantly while listening on port
> 1205.  This started task has a loadlib with user written cobol
> programs.  This started task also has a control file (jcl ddname)
> with a record.  For performance reasons, I only want to read the
> record one time only.  How should I code the cobol program  so that
> the working storage values are retained between calls.
>
> I can't statically link the vendor program with my program.....

Unless my COBOL has completely deserted me (it's been about six years)....

Option A, straight answer:
Don't CANCEL the called module from the calling program until done with it
AND
Don't use the INITIAL option in the PROGRAM-ID of the called module

Option B, the pragmatic  answer
Don't waste your time thinking about retaining values for one dinky record.
Just read the damn thing when you need it.

Option C, the creative answer.
Code the calling program to pass a group-item containing all the info to be
retained acrosss multiple calls; pass BY REFERENCE. On the first call, read
your record and fill that group item with the necessary info; maintain as
necessary whilst the called module executes.

On subsequent calls, use the values in the passed group-item instead of
re-reading the file.

That is, let the calling program retain the called module's 'static' working
storage instead of trying to do so in the called module.

This option also has the advantage of not being dependent on the INITIAL
clause or any compile-time options, and will also work 'as is' if you do
someday go to static linking.

MCM

On Dec 12, 8:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> Option A, straight answer:
> Don't CANCEL the called module from the calling program until done with it
> AND
> Don't use the INITIAL option in the PROGRAM-ID of the called module
>
Calling the vendor program that calls the user-written program
terminates, thereby losing the values in working storage.  This
is not an option.


> Option B, the pragmatic  answer
> Don't waste your time thinking about retaining values for one dinky record
.
> Just read the damn thing when you need it.
>
I'm not wasting my time retaining values....Reading the record adds
1/10 of a second to the execution time.  In a high-volume web
environment, with limited port connections, this translates to longer
response times.

> Option C, the creative answer.
> Code the calling program to pass a group-item containing all the info to b
e
> retained acrosss multiple calls; pass BY REFERENCE. On the first call, rea
d
> your record and fill that group item with the necessary info; maintain as
> necessary whilst the called module executes.
>
> On subsequent calls, use the values in the passed group-item instead of
> re-reading the file.
>
> That is, let the calling program retain the called module's 'static' worki
ng
> storage instead of trying to do so in the called module.
>
> This option also has the advantage of not being dependent on the INITIAL
> clause or any compile-time options, and will also work 'as is' if you do
> someday go to static linking.
>
> MCM
I thought about calling a separate program that reads the record and
retaining the values in a client singleton program, but this would be
problematic if the the started job ends and restarted with new values
in the file.  From the web perspective, the singleton program would
have to be reloaded everytime the started job ends....

"yoqi99" <yoqi99@gmail.com> wrote in message
news:145804c2-faeb-4437-aa27-40f37d1169e5@y5g2000hsf.googlegroups.com...
> On Dec 12, 8:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote: 
> Calling the vendor program that calls the user-written program
> terminates, thereby losing the values in working storage.  This
> is not an option.
>
> 
> I'm not wasting my time retaining values....Reading the record adds
> 1/10 of a second to the execution time.  In a high-volume web
> environment, with limited port connections, this translates to longer
> response times.
> 
> I thought about calling a separate program that reads the record and
> retaining the values in a client singleton program, but this would be
> problematic if the the started job ends and restarted with new values
> in the file.  From the web perspective, the singleton program would
> have to be reloaded everytime the started job ends....


Well, since you found fault with all three good-faith no-cost suggestions
provided as best I could from the sketchy and incomplete "conditions", good
luck finding someone who will actually participate in Option D (The Final
Option):

OPTION D
Engage a professional to solve this problem.

MCM

On Dec 12, 9:47 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> "yoqi99" <yoq...@gmail.com> wrote in message
>
> news:145804c2-faeb-4437-aa27-40f37d1169e5@y5g2000hsf.googlegroups.com...
>
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> Well, since you found fault with all three good-faith no-cost suggestions
> provided as best I could from the sketchy and incomplete "conditions", goo
d
> luck finding someone who will actually participate in Option D (The Final
> Option):
>
> OPTION D
> Engage a professional to solve this problem.
>
> MCM

ok, thanks dad.  next time i will do everything you suggest.
plonk....

I don't really understand your application structure.

The rules of (Standard) COBOL *require* that the Working-Storage values be
retained between calls to the same subprogram *UNLESS* special things are do
ne.

If your user program is a subprogram (called by the Vendor "main" program) a
nd
the subprogram is "losing" WS values, then the Vendor main program MUST be d
oing
something "special".  It might be doing a CANCEL (if it is written in COBOL)
.
However, if the vendor main program is NOT a COBOL program (and I am correct
that you are on MVS - because of some of the terms you are using), then it i
s
possible that the main program is NOT "calling" your user program but is doi
ng
an "ATTACH" or something else that "refreshes" your subprogram.  This is
something that you need to find out from the vendor.

There is one solution that MIGHT work for you.  If you place the values that
 you
want to keep into an EXTERNAL 01-level in your user-written program, then th
ese
values should be kept - even if the program is CANCELLED by a high-level
program.  However, if the higher-level program isn't COBOL, then this may or
 may
not work.

--
Bill Klein
wmklein <at> ix.netcom.com
"yoqi99" <yoqi99@gmail.com> wrote in message
news:145804c2-faeb-4437-aa27-40f37d1169e5@y5g2000hsf.googlegroups.com...
> On Dec 12, 8:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote: 
> Calling the vendor program that calls the user-written program
> terminates, thereby losing the values in working storage.  This
> is not an option.
>
> 
> I'm not wasting my time retaining values....Reading the record adds
> 1/10 of a second to the execution time.  In a high-volume web
> environment, with limited port connections, this translates to longer
> response times.
> 
> I thought about calling a separate program that reads the record and
> retaining the values in a client singleton program, but this would be
> problematic if the the started job ends and restarted with new values
> in the file.  From the web perspective, the singleton program would
> have to be reloaded everytime the started job ends....

<listmazter@gmail.com> wrote in message
news:258ae2a6-31d7-4909-92b0-0d52479a6e60@e23g2000prf.googlegroups.com...
> On Dec 12, 9:47 am, "Michael Mattias" <mmatt...@talsystems.com> wrote: 
with 
to 
call, 
maintain as 
of 
INITIAL 
do 
suggestions 
good 
Final 
>
> ok, thanks dad.  next time i will do everything you suggest.
> plonk....

It seems you might also benefit from a second professional
to help you deal with your personal issues!

What you provided was very sketchy. No mention of the
compiler, OS, or platform; though IBM is suggested by
mention of 'jcl ddname'. Also, it seems retention of
working-storage values is not required, only the retention
of data from one record.

Off-hand, I might suggest that, since EXTERNAL data
belongs to the run unit, a COBOL program might read
the file placing the data in an EXTERNAL data-item,
then calling the vendor program. When the vendor
program calls the user progam, the user program gets
the data from the EXTERNAL data-item. But I am
uncertain what you intend by "vendor started task" and,
if you do not have access to the JCL, this method
probably can not be implemented.

On Dec 13, 2:47 am, yoqi99 <yoq...@gmail.com> wrote:
> Have vendor started task that runs constantly while listening on port
> 1205.  This started task has a loadlib with user written cobol
> programs.  This started task also has a control file (jcl ddname)
> with a record.  For performance reasons, I only want to read the
> record one time only.  How should I code the cobol program  so that
> the working storage values are retained between calls.
>
> I can't statically link the vendor program with my program.....

If the vendor program CALLs your user written program and does not
CANCEL it then the Working-Storage will be retained intact between
CALLs.  You only need to set a flag that indicates that the record has
already been read:

Working-Storage Section.
01  Already-Read   PIC X VALUE "N".
01  Record-Data ...

Procedure Division.

If ( Already-Read NOT = "Y" )
read ..
MOVE "Y" TO Already-Read
END-IF

do whatever with data ..

If the vendor program CANCELs or restarts then you will reread the
record.

I already sent one message saying that we need to know more about the
"structure" of your application and the vendor program that calls your
user-written application.

One thing that I thought of was that *if* (as I assume) you are on an IBM
mainframe, then it is possible that not only is your vendor "main" program N
OT
written in COBOL, but it is also possible that it is NOT an "LE-conforming"
Assembler driver.  This would certainly (help) explain why your application
subprograms are ACTING as if they were "main" programs.  In this case, EXTER
NAL
wouldn't help (nor would anything else that I can think of - except writing 
the
data out into "system" storage of some sort or another.).  You really do nee
d to
find out from the vendor whether the program is or is not LE-conforming (not
just LE "tolerant).

If the vendor program is NOT LE-conforming, then you could still "solve" you
r
problem by creating an LE-conforming (COBOL, Assembler, or whatever) and hav
e
that driver call the vendor program (once - to get it started).  In that cas
e,
your COBOL WS items would be retained. However, depending upon how the vendo
r
program is designed, this MIGHT cause either performance or storage issues.

--
Bill Klein
wmklein <at> ix.netcom.com
"yoqi99" <yoqi99@gmail.com> wrote in message
news:18bff75d-832d-4089-a301-1b5162d5eed4@a35g2000prf.googlegroups.com...
> Have vendor started task that runs constantly while listening on port
> 1205.  This started task has a loadlib with user written cobol
> programs.  This started task also has a control file (jcl ddname)
> with a record.  For performance reasons, I only want to read the
> record one time only.  How should I code the cobol program  so that
> the working storage values are retained between calls.
>
> I can't statically link the vendor program with my program.....

In article <966198db-204f-4634-9c2b-8d21439f6586@o42g2000hsc.googlegroups.co
m>,
Richard  <riplin@azonic.co.nz> wrote:
>On Dec 13, 2:47 am, yoqi99 <yoq...@gmail.com> wrote: 
>
>If the vendor program CALLs your user written program and does not
>CANCEL it then the Working-Storage will be retained intact between
>CALLs.  You only need to set a flag that indicates that the record has
>already been read:
>
>     Working-Storage Section.
>     01  Already-Read   PIC X VALUE "N".
>     01  Record-Data ...
>
>     Procedure Division.
>
>         If ( Already-Read NOT = "Y" )
>              read ..
>              MOVE "Y" TO Already-Read
>         END-IF
>
>         do whatever with data ..

Hmmmmm... leaving aside the matter of style (any good, true, decent and
sane programmer worthy of the pittance of a salary paid for those hard-won
skills would, of course, make Already-Read an 88) I read this and thought
that lo, there is nothing new under the sun.

IF EIBCALEN = 0
PERFORM 0000-HOUSEKEEPING  THRU 0000-HSK-EX
ELSE
PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.

DD