What i usually do in these sort of circumstances is a 'set set.out' and
then compare that to a set done while a normal telnet user. There may be
something missing in a profile file
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
Another thought - have you checked the group of the redback user, maybe it
is a permissions thing , i presume uname gathers its info from /sys and
there may be some restriction somewhere.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
One 'simple' thing to try...
I'd ask them to first check the ulimit settings from the UNIX shell before they
enter (ie., what is the default). For all the values not set already to
unlimited. Retry and see if that makes any difference.
Only other thing I can suggest: create a Korn Shell VOC
I'm running on Universe 10.3.4 on AIX 5.3 on a PICK flavor account.
I ran into some really weird behavior with a CASE statement this morning, or
at least what I deem to be strange.
I won't post the entire program... yet
Basically I have some boolean variables that get set earlier in the
Yeah I need sleep... Sorry. Thanks.
On Fri, Aug 5, 2011 at 11:01 AM, Israel, John R.
johnisr...@daytonsuperior.com wrote:
Your 2nd CASE was satisfied so no further CASE conditions were tested.
Unlike some other languages, once a CASE condition is met, no other CASE
conditions are tested.
Hi John
Based on the values of your variables, your CASE construct is behaving
perfectly!
As far as I can tell, the reason partial_names_found never executes is
because the preceding clause in your CASE statement evaluates to /true/.
In a CASE block, each clause is checked until a clause is
This is the reason you always place CASE 1 at the end... :-)
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Glenn Sallis
Sent: Friday, August 05, 2011 11:00 AM
To: U2 Users List
Subject: Re: [U2] Strange CASE
I have run into something I have never seen before. We exchange a lot of
data with an AS400 in Chicago. For many years we have taken the approach
that the AS400 would submit a job to our UNIX box that would run a script.
Many of the scripts run a Unibasic program and send the resulting file
Thanks guys. One of those days where you stare at something for a while,
and on't realize the obvious :(
On Fri, Aug 5, 2011 at 11:12 AM, Marc Harbeson marc.harbe...@gmail.comwrote:
This is the reason you always place CASE 1 at the end... :-)
-Original Message-
From:
Did anything change in your VOC LOGIN program/proc/paragraph that might be
preventing the program from running?
Susan Lynch
F. W. Davison Company, Inc.
- Original Message -
From: charles_shaf...@ntn-bower.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: 08/05/2011 11:26 AM
Since you say it's sending the same file each day, then it's not
just the Unibasic that is not running, the rm isn't working either,
otherwise, you would be sending a blank file over and over.
How are you running this script from the AS400? rsh? If so, has
the user that running it on the AS400
Did anything change in your VOC LOGIN program/proc/paragraph that might
be
preventing the program from running?
Susan Lynch
F. W. Davison Company, Inc.
I don't think so. Wouldn't that affect the command line run also?
Charles Shaffer
Senior Analyst
NTN-Bower Corporation
Not necessarily - if, for example, you have a branch in your VOC LOGIN that
varies on usertype or on the login user (eg SYSTEM to avoid having Redback
processes run some parts of the LOGIN routine, which is one thing that we
do), you might have inadvertantly caused the user id for this process
George
Since you say it's sending the same file each day, then it's not
just the Unibasic that is not running, the rm isn't working either,
otherwise, you would be sending a blank file over and over.
The remove and touch affect the log file. The data file is cleared in the
program. Since
what if you throw a whoami, groups and env into the script and check your
logfile
against those values when your on the CL, to see if anything jumps out.
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of
Susan
Not necessarily - if, for example, you have a branch in your VOC LOGIN
that
varies on usertype or on the login user (eg SYSTEM to avoid having
Redback
processes run some parts of the LOGIN routine, which is one thing that
we
do), you might have inadvertantly caused the user id for
I agree on checking permissions on the executable. That aside have you
considered adding a EXECUTE COMO ON TEST or something similar to the top
of the program to capture any output it might be producing?
On Fri, Aug 5, 2011 at 10:23 AM, Dan Fitzgerald dangf...@hotmail.comwrote:
And it _does_
One thing I would do is to add 21 to the end of every line that contains a
$LOG or $LOG. This will redirect any error messages from stderr to the
log file as well. Then you can check the log file to see if any type of
error is occurring. It may be that your script isn't even starting udt.
Also
I will try the 21. That might be informative.
I can log in locally as the same user that remotely logs in and run the
script no problem, including the unidata session.
Thanks.
Charles Shaffer
Senior Analyst
NTN-Bower Corporation
Larry Hiscock lar...@wcs-corp.com
Sent by:
George
Are you sure it's running ok? Did you remove the output file before you
ran as that user?
When we first noticed the problem, I logged in as the remote user and ran
it from CL, and the folks in Chicago saw right away that the records were
updated. Orders they were missing were now
George
what if you throw a whoami, groups and env into the script and check
your logfile
against those values when your on the CL, to see if anything jumps out.
Good idea. I just ran it from CL with the additional information. It ran
fine, and everything looks as I would expect.
Monday
Today I had an interesting discussion with a java developer about uniobjects
and while I am going to run a test for myself I thought I would throw out my
question to see what others know about this.
The question is can you write a java or .net application that can call a
subroutine (via
This has been a problem with UniObjects from the beginning.
When you are performing a subroutine which hits an INPUT, it just
never comes back. You have to be doing an execute, which picks up
everything put out with CRT etc and waits for input. On filling the
input, it continues. Desired
23 matches
Mail list logo
