F.JOB.LIST.x files
Phuong Do Duc
Jim Idle
This is purely a T24 question and you should seek help from TEMENOS support I think.
However, I think that these are files related to the attempt to run COB on more than one process simultaneously and are how the program partitions each of the myriad poorly programmed tasks [cough!] into job lots.
Jim
Luis Lascano
Yes, Jim has said the reason why these files exist.
This makes multithreading COB work on a “sharing” processing-keys basis.
Each agent takes a Job List Number and process keys located inside. Once it finishes processing, deletes the key and goes to the next one.
So for instance if you have three agents then you should have three job list files.
There could be cases when some keys are left without being deleted and next COB job or Batch comes into scene, agent does not know what happened and tries to process those left keys associating them with the wrong job and fatal errors might appear.
For this reason is very important to be careful managing agents and these job lists.
These files are not deleted after COB finishes and will be there forever…
Regards,
Luis Lascano
Thesys Technologies
Tel +593 2 2433 963 GMT -05:00
Int tel: +1 305 767 2756 GMT -04:00
Mob +593 9 625 9757 GMT -05:00
Skype: llascano
Luis Lascano
Does anybody remember the way that UV used to keep the stack of commands keyed in on a UV session?
It was saved on a text like file under &ED& located on home directory. File name was associated with Session number.
When jBase came into scene, &ED& dissapeared ! and of course these nice audit – stack files…
But still we have that stack on jBase, no way to display anymore with .L but going up and down with cursor keys.
Well, my question is: how can I get the same info on jBase? How can I see these commands –on a list way- used from previous jBase sessions?
Thanks is advance for your help!
Luis Lascano
What could be this error message appearing on my jbase_error_trace file?
Trace message from pid 1405032 port 11003 at time 'Thu Nov 22 04:40:42 2007', Whoops: Called > 1000 times with signal 13
Trace message from pid 1405034 port 11002 at time 'Thu Nov 22 04:41:41 2007', Whoops: Called > 1000 times with signal 13
jdiag info:
AIX-/app_t24ofex/t24app/t24pre11/bnk/bnk.run: jdiag -v
jdiag - jBASE diagnostic '$Revision: 1.12 $'
System Information
==================
System : AIX t24ofex 2.5 00CB2FEB4C00OS Release : 5.2.0.0
UNIX User : t24pre11 (uid 253, euid 253)
Tty name : /dev/pts/3
jBASE User (JBCLOGNAME) : Not Set
Time : Thu Nov 22 21:53:19 2007
WARNING: License information can only be displayed by an administrative user
Environment
===========
JBCCONNECT : 'CONNECT*46*753698'
JBCPORTNO : Not Set
Connect Port : '46'
JBCRELEASEDIR : '/usr/jbc'
JBCGLOBALDIR : '/usr/jbc'
HOME : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run'
JEDIFILEPATH : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run'
JEDIFILENAME_MD : 'VOC'
JEDIFILENAME_SYSTEM : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/SYSTEM'
JBCBASETMP : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/workfile/tmp_3'
JBCNOINTERNAL : Not Set
JEDI_NOSHMEM : Not Set
RELEASE Information : Major 4.0 , Minor 7.2 , Patch 0385
Spooler dir (JBCSPOOLERDIR) : '/usr/jspooler'
Spooler directory '/usr/jspooler' OK
JBCEMULATE : 'prime'
Emulation Config file '/usr/jbc/config/Config_EMULATE' OK
JBCEMULATE Label 'prime' found in file '/usr/jbc/config/Config_EMULATE'
Executable search Path: /usr/vac/bin:/usr/jbc/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java14/jre/bin:/usr/java1
4/bin:/home/oracle9/product/9.2/bin:.:/usr/local/bin:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/globuspatchbin:/app_t24ofex/t24app/t24
pre11/bnk/bnk.run/globusbin:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/usrdbin:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/rdbin:/app_t24
ofex/t24app/t24pre11/bnk/bnk.run/bin:/usr/ccs/bin:/usr/ucb
Shared Object search path: LIBPATH=/usr/jbc/lib:/usr/ccs/lib:/usr/lib:/home/oracle9/product/9.2/lib32
Found : '/usr/jbc/lib/libjbase.so'
Found : '/usr/jbc/lib/libjbaseutil.so'
Found : '/usr/jbc/lib/libjcon.so'
Found : '/usr/jbc/lib/libjsub.so'
Found : '/usr/jbc/lib/libjlic.so'
Object path (JBCOBJECTLIST) : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/lib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/usrdlib:/app_t2
4ofex/t24app/t24pre11/bnk/bnk.run/gdgitlib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/globuspatchlib:/app_t24ofex/t24app/t24pre11/bnk/
bnk.run/gdusgaaplib:/usr/jbc/lib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/gdGR0100040lib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/gl
obuslib'
Program dir (JBCDEV_BIN) : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/bin'
Program Path '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/bin' is in your PATH
Subroutine dir (JBCDEV_LIB) : '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/lib'
Subroutine path '/app_t24ofex/t24app/t24pre11/bnk/bnk.run/lib' is in JBCOBJECTLIST
Full Environment
===============
_=/usr/jbc/bin/jdiag
MANPATH=/usr/jbc/man
JBCSPOOLERDIR=/usr/jspooler
LANG=en_US
JEDIFILENAME_SYSTEM=/app_t24ofex/t24app/t24pre11/bnk/bnk.run/SYSTEM
JEDI_SOB_NOCLOSE=1
LOGIN=t24pre11
SHLIB_PATH=/usr/jbc/lib:/usr/lib:/lib:/home/oracle9/product/9.2/lib32
JBASE_NO_SOB_SIZE_WARNING=1
PATH=/usr/vac/bin:/usr/jbc/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java14/jre/bin:/usr/java14/bin:/home
/oracle9/product/9.2/bin:.:/usr/local/bin:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/globuspatchbin:/app_t24ofex/t24app/t24pre11/bnk/b
nk.run/globusbin:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/usrdbin:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/rdbin:/app_t24ofex/t24app
/t24pre11/bnk/bnk.run/bin:/usr/ccs/bin:/usr/ucb
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
JBC_EXIT_ZEROREAD=1
ORACLE_LD_LIBRARY_PATH=/home/oracle9/product/9.2/lib
JBCGLOBALDIR=/usr/jbc
LC__FASTMSG=true
CGI_DIRECTORY=/var/docsearch/cgi-bin
EDITOR=vi
LOGNAME=t24pre11
JEDIFILEPATH=/app_t24ofex/t24app/t24pre11/bnk/bnk.run
MAIL=/usr/spool/mail/t24pre11
JBCLISTFILE=/app_t24ofex/t24app/t24pre11/bnk/bnk.run/&SAVEDLISTS&
HOSTNAME=t24ofex
JBCRELEASEDIR=/usr/jbc
LOCPATH=/usr/lib/nls/loc
ORACLE_SID=t24ofx
PS1=AIX-$PWD:
USER=t24pre11
DOCUMENT_SERVER_MACHINE_NAME=localhost
LDR_CNTRL=MAXDATA=0x40000000
ORACLE_SHLIB_PATH=/home/oracle9/product/9.2/lib
JBASE_INHIBIT_ZERO_USED=1
AUTHSTATE=compat
JBCDEV_LIB=/app_t24ofex/t24app/t24pre11/bnk/bnk.run/lib
TNS_ADMIN=/home/oracle9/product/9.2/network/admin
ORACLE_SHLIB=/home/oracle9/product/9.2/lib
JBCDEV_BIN=/app_t24ofex/t24app/t24pre11/bnk/bnk.run/bin
DEFAULT_BROWSER=netscape
PP_LPAR_KEY_FIX=1
DISPLAY=192.168.25.29:0
JEDIFILENAME_MD=VOC
SHELL=/usr/jbc/bin/jsh
ODMDIR=/etc/objrepos
DOCUMENT_SERVER_PORT=49213
JBCOBJECTLIST=/app_t24ofex/t24app/t24pre11/bnk/bnk.run/lib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/usrdlib:/app_t24ofex/t24
app/t24pre11/bnk/bnk.run/gdgitlib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/globuspatchlib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/g
dusgaaplib:/usr/jbc/lib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/gdGR0100040lib:/app_t24ofex/t24app/t24pre11/bnk/bnk.run/globuslib
HOME=/app_t24ofex/t24app/t24pre11/bnk/bnk.run
TERM=vt220
LD_LIBRARY_PATH=/usr/jbc/lib:/usr/ccs/lib:/usr/lib:/home/oracle9/product/9.2/lib32
MAILMSG=[YOU HAVE NEW MAIL]
ORACLE_HOME=/home/oracle9/product/9.2
ITECONFIGSRV=/etc/IMNSearch
PWD=/app_t24ofex/t24app/t24pre11/bnk/bnk.run
DOCUMENT_DIRECTORY=/usr/docsearch/html
JBC_EXIT_FAILEDREAD=1
JBCEMULATE=prime
TZ=EST5EDT,M3.2.0/02:00:00,M11.1.0/02:00:00
JEDIENABLEQ2Q=1
ITECONFIGCL=/etc/IMNSearch/clients
JBASE_WARNLEVEL=30
ITE_DOC_SEARCH_INSTANCE=search
JBCCONNECT=CONNECT*46*753698
JBCBASETMP=/app_t24ofex/t24app/t24pre11/bnk/bnk.run/workfile/tmp_3
A__z=! LOGNAME
LIBPATH=/usr/jbc/lib:/usr/ccs/lib:/usr/lib:/home/oracle9/product/9.2/lib32
NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat
AIX-/app_t24ofex/t24app/t24pre11/bnk/bnk.run:
Thanks in advance for your help on this !
John Fenlon
001 CT JUTIL_CTRL
002 JDIR
003 CD \JBASE30\TMP
004 EXIT
005 SORT PALLET BY 42
006 SORT PALLET BY 42
007 SORT PALLET BY 42
008 CT DICT PALLET
009 CT DICT PALET
010 LIST PALLET
011 PWD
012 CD
013 WHERE
001 EXIT
002 WHERE
001 WHERE
002 EWHERE
003 WHER
Jim Idle
J
This is obviously a mistake as it should really be preceded by GGC: TBD
However, Sig 13 is SIGPIPE, which means that something is writing to a PIPE and there are no readers on the end of the pipe. It should really hang up when it gets this signal and the message implies that this piece of code was written as a test/diagnostic in order to debug something and was left in there. You should try the strings command on jBASE libraries ;-).
I suspect that this is coming from one of the connection daemons, which has spawned a process that is writing output to a connection (one of the clients I guess), and that this client has gone away. It likely means that some of you users are just shutting down their connections rather than logging out and that the signal handler is then kicking in and dropping the process, which is what it should do, but I should only take one signal to do this. However, it is likely that there was no way to avoid all the signals as they will be raised as fast as possible on each write to the pipe. I think therefore that there is probably nothing much to worry about, but you might ask TEMENOS support to look in to this.
Jim
Jim Idle
...which of course can be edited and
changed and therefore is useless as an audit file. Beware of incurring lots of
system overhead to gather information which is vulnerable to being doctored. It
is a waste of effort!
Jim
When jBase came into scene, &ED& dissapeared ! and of course these nice audit – stack files...
But still we have that stack on jBase, no way to display anymore with .L but going up and down with cursor keys.
Well, my question is: how can I get the same info on jBase? How can I see these commands –on a list way- used from previous jBase sessions?
Thanks is advance for your help!
Regards,
Luis Lascano
Thesys Technologies
Tel +593 2 2433 963 GMT -05:00
Int tel: +1 305 767 2756 GMT -04:00
Mob +593 9 625 9757 GMT -05:00
Skype: llascano
<BR
x
file named "jutil_ctrl" found in the subdirectory named "tmp" found in
the "JBCRELEASEDIR" directory.
On Windows 3.x the path would be:
C:\JBASE3\tmp\jutil_ctrl jsh_k_15 <-- 15 is the port number
On Windows 4.x see:
C:\JBASE4\4.1\tmp\jutil_ctrl jutil_jsh_CONIN_-2 <--- 2 is the
port number
A trivial program that would allow you to see the stack for a
particular port is downloaded in the Google Files folder under the
name "SEE".
(I've tried to paste it in the message body but Google has a mind of
its own and reformats it in an unusable way)
The program should work as is on Windows and Linux.
Lucian
On Nov 22, 9:30 pm, "Luis Lascano" <luislasc...@gmail.com> wrote:
> Does anybody remember the way that UV used to keep the stack of commands
> keyed in on a UV session?
>
> It was saved on a text like file under &ED& located on home directory. File
> name was associated with Session number.
>
> When jBase came into scene, &ED& dissapeared ! and of course these nice
> But still we have that stack on jBase, no way to display anymore with .L but
> going up and down with cursor keys.
>
> Well, my question is: how can I get the same info on jBase? How can I see
Daniel Klein
sessions?"
http://jbase.com/knowledgebase/manuals/3.0/30manpages/man/sup12_JSHELL.htm
Dan
Luis Lascano
Thanks all for your help and programs, the CT JUTIL_CTRL is quite useful!
By viewing this file I have noted that it gets until row 50 and does not go further.
Is there any parameter where I can specify say 100 ?
Output from GET.PORT (thanks Lucian)
jsh t24dev ~ -->GET.PORT 79
[ 417 ] File POINTER-FILE]D created , type = J4
[ 417 ] File POINTER-FILE created , type = J4
File POINTER-FILE , Record 'jsh_k_79' Insert 16:46:42
Command->
0001 exit
0002 EBS.LOGIN
0003 WHERE
0004 LIST.TSA
0005 DELETE FBNK.JOB.LIST.4
0006 LIST FBNK.JOB.LIST.4
0007 LIST FBNK.JOB.LIST.3
0008 LIST FBNK.JOB.LIST.2
0009 SELECT F.BATCH WITH PROCESS.STATUS EQ 2 AND BATCH.STAGE EQ R998
0010 JED F.BATCH
Thanks again!
Luis
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of John Fenlon
Sent: Thursday, 22 November, 2007
10:11 PM
To: jB...@googlegroups.com
<BR
Greesh Dhir
Greesh
From: luisl...@gmail.com
To: jB...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Date: Thu, 22 Nov 2007 20:48:57 -0500
Luis Lascano
Greesh! long time!
Yes, I have seen something like that but don’t know how the logic is behind those cases.
Well we could talk more in detail but this is not the proper forum… Do you know a Globus/T24 forum around?
Take care,
Luis
</html
size=2 face=Tahoma>
Jim Idle
Well, does this seriously need any discussion or are things being made up to...? Has anyone got anything to ask here? Cannot one infer the logic behind this in 2 milliseconds? Yeah – I know, stupid question and everyone will hate this comment, but... ah what the hell – one reaps ones self-made rewards. I really wouldn’t mind if I hadn’t sent something saying “try not to talk about absolutely T24 specific stuff...”
Jim
From: Luis Lascano
[mailto:luisl...@gmail.com]
Sent: Friday, November 23, 2007
6:05 PM
To: jB...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Greesh! long time!
Yes, I have seen something like that but don’t know how the logic is behind those cases.
Well we could talk more in detail but this is not the proper forum... Do you know a Globus/T24 forum around?
Take care,
Luis
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of Greesh Dhir
Sent: Friday, 23 November, 2007
6:38 PM
To: jb...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Luis is right, however I would go
further to say that you can have multiple agents processing the same
JOB.LIST.x.
Greesh
From: luisl...@gmail.com
To: jB...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Date: Thu, 22 Nov 2007 20:48:57 -0500
Yes, Jim has said the reason why these files exist.
This makes multithreading COB work on a “sharing” processing-keys basis.
Each agent takes a Job List Number and process keys located inside. Once it finishes processing, deletes the key and goes to the next one.
So for instance if you have three agents then you should have three job list files.
There could be cases when some keys are left without being deleted and next COB job or Batch comes into scene, agent does not know what happened and tries to process those left keys associating them with the wrong job and fatal errors might appear.
For this reason is very important to be careful managing agents and these job lists.
These files are not deleted after COB finishes and will be there forever...
</html
size=2 face=Tahoma>
Phuong Do Duc
Well, does this seriously need any discussion or are things being made up to...? Has anyone got anything to ask here? Cannot one infer the logic behind this in 2 milliseconds? Yeah – I know, stupid question and everyone will hate this comment, but... ah what the hell – one reaps ones self-made rewards. I really wouldn't mind if I hadn't sent something saying "try not to talk about absolutely T24 specific stuff..."
Jim
From: Luis Lascano [mailto: luisl...@gmail.com]
Sent: Friday, November 23, 2007 6:05 PM
To: jB...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Greesh! long time!
Yes, I have seen something like that but don't know how the logic is behind those cases.
Well we could talk more in detail but this is not the proper forum... Do you know a Globus/T24 forum around?
Take care,
Luis
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of Greesh Dhir
Sent: Friday, 23 November, 2007 6:38 PM
To: jb...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Luis is right, however I would go further to say that you can have multiple agents processing the same JOB.LIST.x .
Greesh
From: luisl...@gmail.com
To: jB...@googlegroups.com
Subject: RE: F.JOB.LIST.x files
Date: Thu, 22 Nov 2007 20:48:57 -0500
Yes, Jim has said the reason why these files exist.
This makes multithreading COB work on a "sharing" processing-keys basis.
Each agent takes a Job List Number and process keys located inside. Once it finishes processing, deletes the key and goes to the next one.
So for instance if you have three agents then you should have three job list files.
There could be cases when some keys are left without being deleted and next COB job or Batch comes into scene, agent does not know what happened and tries to process those left keys associating them with the wrong job and fatal errors might appear.
For this reason is very important to be careful managing agents and these job lists.
These files are not deleted after COB finishes and will be there forever...
</html
size=2 face=Tahoma>
x
> to Jim Idle: I think Nobody understand you, what do you mean?
He already pointed you in the right direction "This is purely a T24
unrelated to jBASE should be directed to the right forum.
See Google groups:
globus-t24
globus_tips
TEMENOS-GLOBUS
Lucian