Dinamyc PL/I routines with parametre problems in Language Environment 
Author Message
 Dinamyc PL/I routines with parametre problems in Language Environment

 Sorry by low english level, I try to explain clearly :

 In a COBOL program dynamically LOADED from a PL/I main program, we're
calling statically another PL/I routine that calls dynamically another
PL/I routine that finally calls
dynamically the last PL/I routine. It pass files as parameters and when
the last routine called
try to read one of them it seems that attributes for file has been
missed. Messages is :

    IBM0809S ONCODE=1009  An invalid file operation was attempted on
file F1261E

In PLIDUMP we can see attributes for the others files but not for F1261E
so It seems really
has miss attributes.

 Same job executed without Language environment end ok. I think may be
this is because routine reading file not from a PL/I normal procedure.
It's reading it from a PL/I internal function and MAY BE this is not
supported in a ILC application executing below language environment.

 Anyone has experienced something similar

 Note : PL/I dynamic calls are supported by ASSM routines. This is
because FETCH and
 release PL/I commands has undesired restrictions.



Tue, 16 Oct 2001 03:00:00 GMT  
 Dinamyc PL/I routines with parametre problems in Language Environment
Apart from being totally baffled by the explanation, are you trying to:
1. open a file in one subtask
2. process it in a lower subtask
If so, there are restrictions on what you can do on MVS (aka OS/390) here.

You will need to use static calls, or restrict your I/O suitably.

Please review the manual on ILC under LE for more details on the first.
For the second, review the MVS documentation.

Quote:

> Sorry by low english level, I try to explain clearly :

> In a COBOL program dynamically LOADED from a PL/I main program, we're
>calling statically another PL/I routine that calls dynamically another
>PL/I routine that finally calls
>dynamically the last PL/I routine. It pass files as parameters and when
>the last routine called
>try to read one of them it seems that attributes for file has been
>missed. Messages is :

>    IBM0809S ONCODE=1009  An invalid file operation was attempted on
>file F1261E

>In PLIDUMP we can see attributes for the others files but not for F1261E
>so It seems really
>has miss attributes.

> Same job executed without Language environment end ok. I think may be
>this is because routine reading file not from a PL/I normal procedure.
>It's reading it from a PL/I internal function and MAY BE this is not
>supported in a ILC application executing below language environment.

> Anyone has experienced something similar

> Note : PL/I dynamic calls are supported by ASSM routines. This is
>because FETCH and
> release PL/I commands has undesired restrictions.



Thu, 18 Oct 2001 03:00:00 GMT  
 Dinamyc PL/I routines with parametre problems in Language Environment
On Fri, 30 Apr 1999 08:36:20, Josep =?iso-8859-1?Q?Llu=EDs?=

Quote:

>  In a COBOL program dynamically LOADED from a PL/I main program,
> we're calling statically another PL/I routine
> that calls dynamically another PL/I routine
> that finally calls dynamically the last PL/I routine.
> It pass files as parameters.

This should work correctly, as long as COBOL receives the address
of the FILE parameter, and passes that address to the next routine.
If COBOL "copies" the value of the argument,
and passes the copy to the subroutine, you could have a problem.

Can you construct a simpler "test" program:

  PL/I "main" which declares and passes the FILE,
  calling COBOL subprogram which receives the argument,
  calling PL/I subroutine which receives the FILE parameter, and uses
the FILE

and make sure that this works correctly?



Fri, 19 Oct 2001 03:00:00 GMT  
 Dinamyc PL/I routines with parametre problems in Language Environment

 Well. First I want to acknowledge your useful responses. Also I've to
acknowledge my poor explanation, may be because english level or because the
difficult to explain clearly the "scenario". Now I try to explain me better.

 In our installation we normal develop in PL/I V2.3. Now we're  in a
integration process with another company and we've to adapt some external
COBOL applications, batch jobs, in  order to run in a common environment.

 These cobol programs have to call common PL/I routines to add information
in common databases and do common critical procedures. To resolve these
calls we've develop a PL/I interface, whose are declared with the
OPTION(COBOL) ,for each common PL/I routine. These interfaces only receives
control of cobol program and call the common PL/I routine (common to all
applications independent of HLL used). These interfaces are link edited in
the cobol programs and only must be updated when the common routines changes
number of parameters received or his length. When common PL/I routines
receives files as parameters, PL/I interface (link edited in cobol program),
declares and pass them.

 The only problem that this way presents is that PL/I environment is created
and terminated each time you call it. In PL/I manuals says that one way to
resolve this performance problem is to execute your pass below a main PL/I
program. To do this we've develop a single shoot PL/I program that receives
cobol program name to execute and call an assembler interface that
initializes the cobol environment (by IGZERRE module) and calls (with BASSM)
the COBOL program.

  We've test this complicated and, may be redundant method, and we've
experience general problems with pass memory regions size. Be notice that a
single COBOL program can call various PL/I interfaces and each PL/I common
routine called  can call others too.   Also notice that consecutive calls
from PL/I common routines to others PL/I routines are supported by an
assembler interface that bypass problem of fetched PL/I routines.  This
method is tested enough and is operative since more than six years but ever
below PL/I batch tasks.
All modules are link edited in AMODE=24 and is not possible to migrate to
AMODE=31 now. This migration is difficult for us because it must be doing in
a predetermined order to be sure that no modules with AMODE=24 will be
called by AMODE=31 modules.

 We've open an incident in IBM support service because we don't understand
causes of region failure at all. In our standard batch we also have strong
chains of dynamic calls and few jobs has experience region size problems.
Probably anything escapes us but with older PL/I and COBOL versions IBM had
similar problems reported.

 To resolve this last inconvenient we've decided to run below the Language
Environment runtime library as STEPLIB in
our batch programs. Our PL/I and COBOL levels have LE compliance. This
resolve region problems because better performance of LE modules (IBM says,
I suppose ...).

  In this point developers are repeating tests and They haven't found
general problems. Only one. They've a call to an
interface that declares a file and when they try to read (in PL/I common
routine) error below is done :

        IBM0809S ONCODE=1009  An invalid file operation was attempted on
file F1261E

  It seems at any place of execution FCB is override previously at interface
call (we've tried to read in the interface that
has file declaration). Curiously without LE this runs but fails because
region size problem. Also curiously with LE but without the single shoot
PL/I program that begin pass execution this runs successfully. This first
program now not seem necessary because we're executing  below the LE runtime
environment and is LE which has cure of initialize and finish PL/I and COBOL
environments.
 In this moment all is running in real environment and no problems has
found. Last job with file problem is running without PL/I shoot program.

   I don't know if now you understand me but I hope.

   Thank you very much and sorry by time you've expend in me to help



Sun, 21 Oct 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. LINKing to Language-Environment conforming routine

2. Dynamic Link in PL/I and Language Environment

3. PL/I, Language Environment and (CHECK):

4. PL/I control blocks under Language Environment

5. Derivation of PL/I (was Usenet group for PL/M language)

6. Derivation of PL/I (was Usenet group for PL/M language)

7. PL/I in the LE/370 Environment

8. PL/I in the LE/370 Environment

9. PL/I in the LE/370 Environment

10. Screen handling routines for ada environment

11. Benchmark w/o using PL/I routine

12. Language Environment Enabled Assembler Programs

 

 
Powered by phpBB® Forum Software