T24: Running routine under jShell

[Igor Micev]

Hi All,

I have a routine that have to be executed from jShell. It is a
'PROGRAM' type routine, in which is called another 'SUBROUTINE' type
routine which makes some OPFs to some Globus applications.

When i run the PROGRAM type routine the following error msg is being
shown:
** Error [ NOT_FILE_VAR ] **
Variable is not an opened file descriptor ,
Var F.PROTOCOL , Line 99 , Source PRO
Trap from an error message, error message name = NOT_FILE
Line 99 , Source PRO
jBASE debugger->

If i run the routine via Awaitig prompt (NetTerm), it works, but i
want to run it directly from jShell
PGM.FILES exist for both the routines.

Any idea?

Regards
Igor

[Jim Idle]

It, or a program it calls probably relies on the pre-initialization of
named common variables, which means that the program or something that
runs before it, will need to be called first.

Another likely possibility is that you need to run it from a different
environment, but the program is poorly written and does this:

OPEN "PROTOCOL" TO F.PROTOCOL ELSE NULL

....

READ X FROM F.PROTOCOL ....

But nobody does things like this, surely? ;-)

Jim

[Gayathri Ramakrishnan]

When ever you open a new session login into T24 and then try to run your program from jshell prompt.

2009/4/6 Igor Micev <igor...@gmail.com>

--
Regards
Gayathri

[Gayathri Ramakrishnan]

Hi Jim,

 

    Sorry .. .Jim.... I should have explained it in detail in my previous mail itself.

 

   Surely ... he might not have done a direct read on protocol. But as he had mentioned in his mail, his calling routine (T24 routine) may try to read the F.PROTOCOL and might have thrown this error.

 

Cheers,

Gayathri

 

2009/4/6 Jim Idle <ji...@temporal-wave.com>

--
Regards
Gayathri

[Saravanan Thangavelu]

hi,

OPF is an API which you can use only inside the T24. As jim said this OPF or F.READ that you are using needs some variables to intilzed (like your company mnemonic in this case)which will get intilzed only if you login in to T24.So Use jbase "OPEN" and "READ" statement , your problem will be solved.

Regards,
Saravanan.

--
Regards,
saravanan.T

[Igor Micev]

Hi

Yes, you are exact, I tried with OPEN and READ and it works.

Thanks to all

Regards

Igor

--
Igor Micev

[Praveen]

Hi Micev,

T24 programming standards refrains you from calling T24 API's outside
T24 environment. But still if you insist on calling T24 API's from
jsh, you can follow this(only if you wish)
you can initialize the Global COMMON variables and then invoke GLOBUS
API's. If you're working post T24 R07 release, replace the call to
GLOBUS.INITIALISE with T24.INITIALISE
*----------
SPFFile = 'F.SPF'
SPFFileHandler = ''
SPFFileID = 'SYSTEM'
SPFFileRec = ''
SPFReadErr = ''
CALL GLOBUS.INITIALISE
CALL OPF(SPFFile,SPFFileHandler)
CALL F.READ(SPFFile,SPFFileID,SPFFileRec,SPFFileHandler,SPFReadErr)
*---------

This is for INFORMATION PURPOSE ONLY and not for actual coding!

Thanks, Praveen.

On Apr 7, 8:51 pm, Igor Micev <igormi...@gmail.com> wrote:
> Hi

> Yes, you are exact, I tried with OPEN and READ and it works.Thanks to all

>
> Regards
> Igor
>
> On Tue, Apr 7, 2009 at 10:27 AM, Saravanan Thangavelu <
>
>
>
> trsaravananv...@gmail.com> wrote:
> > hi,
>
> > OPF is an API which you can use only inside the T24. As jim said this OPF
> > or F.READ that you are using needs some variables to intilzed (like your
> > company mnemonic in this case)which will get intilzed only if you login in
> > to T24.So Use jbase "OPEN" and "READ" statement , your problem will be
> > solved.
>
> > Regards,
> > Saravanan.
>
> > On Mon, Apr 6, 2009 at 7:39 PM, Gayathri Ramakrishnan <
> > gairamkr...@gmail.com> wrote:
>
> >> When ever you open a new session login into T24 and then try to run your
> >> program from jshell prompt.
>

> >> 2009/4/6 Igor Micev <igormi...@gmail.com>

[Jim Idle]

Praveen wrote:
> Hi Micev,
>
> T24 programming standards refrains you from calling T24 API's outside
> T24 environment. But still if you insist on calling T24 API's from
> jsh, you can follow this(only if you wish)
> you can initialize the Global COMMON variables and then invoke GLOBUS
> API's. If you're working post T24 R07 release, replace the call to
> GLOBUS.INITIALISE with T24.INITIALISE
> *----------
> SPFFile = 'F.SPF'
> SPFFileHandler = ''
> SPFFileID = 'SYSTEM'
> SPFFileRec = ''
> SPFReadErr = ''
> CALL GLOBUS.INITIALISE
> CALL OPF(SPFFile,SPFFileHandler)
> CALL F.READ(SPFFile,SPFFileID,SPFFileRec,SPFFileHandler,SPFReadErr)
> *---------
>

I hate to think of the performance overhead of calling a subroutine
every time you want to do a single READ :-(

Jim

[Igor Micev]

Hi Jim,

It is not just a single READ. I have filled local tables with some
meta data about the locally developed routines in the system. My idea
is to just type RTN.INFO, and the name of a routine and to obtain
information about that routine.

Fortunately it works, and by the way I also tried another successful
way by using VOC file, as also Gayathri said in this discussion.
I want to make my utility like for example jshow -c Object.Name,
I haven't tried such thing till now, but also don't know how, and
haven't meet something similar in the references.

So now the question is how to make my routine RTN.INFO to be executed
from jshell in the following way:
RTN.INFO -[options] [rtn_names]

Kind regards
Igor

[Richard W]

Hi,

does anyone knows why temenos is still using the f.read f.readu
f.write etc.
In the past it was using for i/o etc and transaction mechanism but now
with jbase we don't need it anymore.
But temenos coding standards are still saying that we need it.
Sometimes we have a memory error in a loop for more than 25000
records.
using normal read solves it.

Thanks

On Apr 8, 4:45 am, Jim Idle <j...@temporal-wave.com> wrote:

> Jim- Hide quoted text -
>
> - Show quoted text -

[Mike Preece]

I missed this earlier. Was it a serious concern - or a wind up? How
expensive is a subroutine call?

[Jim Idle]

A subroutine is a C function call and as such is fairly inexpensive in and of itself. However, when a subroutine is called:

The system must initialize the call heap with any local (C level) variables (not too expensive if there are relatively few storage locations, which jBASE tries to minimize,
jBASE must initialize any local jBC variables to the value required for the emulation and allocate the storage in some cases such as when the default is ""
jBASE must tear down any jBC variables that were local to the subroutine.

If all variables used in the subroutine are COMMON, then the overhead is/can be greatly reduced. But if the subroutine is called a million times in a batch program, and if this is compounded with a subroutine call for everything, such as getting the next element from a list and so on, then the overhead of calling subroutines vs using the native language constructs is enormous in relative terms. Obviously, a READ statement goes pretty much straight to the runtime and while subroutines are call-by-reference (so at least you don't need to copy the READ buffer to return the value), a call to the runtime is always going to be better than a call to a subroutine.

On the upside, calling subroutines in jBASE is much less of an overhead than it is in say UniVerse, so overall programs using this behavior will be lots better under jBASE.

Also, we should remember that some of the reasons for calling T24 subroutines are to do with security and best practices as well as providing more of an API than just reading a file (at least I believe so for most things), so the overhead involved may be somewhat necessary.

Jim

[Igor Micev]

Hi all,

Thanks.

The discussion is more than enough. I finished my solution.

Regards

--
Igor Micev

[Mike Preece]

I'd just like to wrap this up, so that no one is under any
miscromprehension...

Jim: I hate to think of the performance overhead of calling

asubroutine every time you want to do a single READ :-(

Q: Was it a serious concern - or a wind up?

Jim: techno babble without conviction...

Jim: (On another subject, and used back at ya): This could not be more
incorrect.

>
Jim: (On another subject, and used right back at ya): I am sorry but
this is utter rubbish.

Jim... Please observe additional posting guidelines... no posting when
pissed.

[Jim Idle]

Mike Preece wrote:

I'd just like to wrap this up, so that no one is under any
miscromprehension...

Jim: I hate to think of the performance overhead of calling
asubroutine every time you want to do a single READ :-(

Q: Was it a serious concern - or a wind up?

Jim: techno babble without conviction...
  

I do not write things without conviction. If you cannot understand the explanation then either defer to them or shut up, don't write vaguely insulting emails for which you have neither the technical nor grammatical skills.

Jim: (On another subject, and used back at ya): This could not be more
incorrect.
  

What are you talking about?

Jim: (On another subject, and used right back at ya): I am sorry but
this is utter rubbish.
  

I assure you it is not.

Jim... Please observe additional posting guidelines... no posting when
pissed.
  

Shurely shome mishtake? I that that this was meant to be directed at yourself right?

Jim

[Mike Preece]

Calling a subroutine does not have a major performance hit. Having all
of your IO going through the same IO subroutines has tremendous
benefits that outweigh that negligible cost in terms of performance
degradation. In other words, you could not have been more wrong.. etc.
And as for the "vaguely insulting" jibe - pots and kettles.

On Apr 18, 5:20 pm, Jim Idle <j...@temporal-wave.com> wrote:
> Mike Preece wrote:I'd just like to wrap this up, so that no one is under any miscromprehension... Jim: I hate to think of the performance overhead of calling asubroutine every time you want to do a single READ :-( Q: Was it a serious concern - or a wind up? Jim: techno babble without conviction...I do not write things without conviction. If you cannot understand the explanation then either defer to them or shut up, don't write vaguely insulting emails for which you have neither the technical nor grammatical skills.Jim: (On another subject, and used back at ya): This could not be more incorrect.What are you talking about?Jim: (On another subject, and used right back at ya): I am sorry but this is utter rubbish.I assure you it is not.Jim... Please observe additional posting guidelines... no posting when pissed.Shurely shome mishtake? I that that this was meant to be directed at yourself right?
> Jim

[Jim Idle]

Mike Preece wrote:
> Calling a subroutine does not have a major performance hit.

In my techno-babble-without-conviction, I explained what hits you can
potentially see. Calling a subroutine, as I explained in my
techno-babble-without-conviction has relatively little overhead, but the
initialization of the things in the subroutine DO have overhead and it
adds up quickly. Your general statement doesn't make much sense as
calling a subroutine that just does the READ is pointless; ipso facto
there will be overhead.

> Having all
> of your IO going through the same IO subroutines has tremendous
> benefits that outweigh that negligible cost in terms of performance
> degradation.

In my techno-babble-without-conviction I explained and acknowledged the
reasons for using such techniques already. However, it seesm you were
too ddunk to read it.

> In other words, you could not have been more wrong..

Look man, I wrote the compiler that lays down the code to call
subroutines - give me some credit for knowing something about the
overheads of calling a subroutine.

> etc.
> And as for the "vaguely insulting" jibe - pots and kettles.
>

Except I still seem to have plenty of work (and at one point I was going
to ask you about some), whereas you are seem to be begging for work on
my list, then slagging me off on the same list for reasons. That seems
like a wise idea Mike, I suggest you invade Russia this winter.

Jim

[Mike Preece]

[Jim Idle]

I am devastated by your wit and repartee. Do you do this for a living?

Jim