USER-COLDSTART
dannyruckel
we had a USER-COLDSTART defined as a macro (attribute 1 = 'n') but
i've necessarily changed it to a proc (attribute 1 = 'pq') when i
test the logic of this USER-COLDSTART outside the context of starting
D3 the proc executes as expected, however, in the context of starting
D3 it does not.
have i provided enough information so someone could comment?
thanks,
danny
Kevin Powick
Not really enough information about what exactly isn't working in the
proc, but some things do behave differently during start-up. For
instance, running a job on a phantom (z) does not require the account
password input as one of the stacked input arguments when run from a
proc. So, if you build such a proc that works at TCL, it will fail if
called as part of the startup because you end up with an extra, now
mismatched, input argument.
--
Kevin Powick
Ross Ferris
In the first instance I'd change all of the P's to PW's in the PROC -
reboot to re-execute the coldstart proc, and then at least you will
have visual feedback of WHERE things are going off the rails
I also question the need to convert to a PROC --> why not refer to
"your proc" from the user-coldstart macro?
Pierre
Danny,
I'm like Ross : Why do you don't stay in PROC format ?
It's what we do and it's working fine and then you will be sure that's
will be work in both case.
Pierre
dannyruckel
kevin,
thanks for the reply. what i am attempting to do is, through the
course of the USER-COLDSTART routine, determine the hostname of the
AIX server i am on. I am running the same USER-COLDSTART routine on
multiple servers. if the hostname of a server is, say "Kevin", i want
to start printers and assign phantom jobs to phantom processes. if
it's any other server, i do not want to start printers/phantoms....
i have a basic program, WHAT.SERVER.AM.I, that simply shells out to
unix, issues the "hostname" command, captures the response and from
there i determine what server i am on. in any proc other than USER-
COLDSTART, this routine works as expected. within the friendly
confines of USER-COLDSTART however, the USER-COLDSTART proc terminates
when it encounters the "HWHAT.SERVER.AM.I" command.
i've also tried the "U01AD" user exit in conjunction with a unix file
that i would create uniquely to 1 of our servers. i've create an md
pointer to that file. proc complains that the file pointed to in the
md item is not a file...
dannyruckel
thanks for the reply ross!
i have changed all the 'P's to 'PW's and was able to determine the
point of failure. there is a basic routine that i have written
specifically for determining what server i am on during startup. once
i determine what server i am on i can decide whether i should start
printers/phantoms. it was for this reason i converted USER-COLDSTART
to a proc, ie, to call a basic program. great suggestion though, wish
i would have thought of it before converting the macro to a proc.
dannyruckel
good a.m. pierre,
thanks for taking the time to respond.
i am keeping the proc but from within the proc call a basic program to
determine what server i am on (we have multiple here). depending on
which server USER-COLDSTART is executing, the routine starts printers/
phantoms.
when i use this routine in any proc other than USER-COLDSTART it works
great. when USER-COLDSTART encounters the basic program it terminates
immediately.
danny
Tony Gravagno
isn't enough info yet to come to any conclusions. Here's a little
background on what's happening in there, and some further ideas.
System-coldstart is a dm,md macro that does a bunch of stuff before it
comes down to a "coldstart" verb. "coldstart" is just another macro
that does "run dm,bp, user.coldstart". That program then checks for
the presence of "user-coldstart" in the md, and whatever that item is,
it does a " chain 'USER-COLDSTART' ".
So you have a macro calling another macro that's running a program
that chains to another TCL command. That's what everyone has.
In Danny's case that TCL program is now a proc (which should be fine)
that then calls to another BASIC program via a catalogued entry. And
that program then shells out to AIX.
Suffice to say, the user workspace is doing a lot of stuff there,
pushing levels, exercising various processors along the way, etc.
It's all perfectly reasonable and "should work". But if it doesn't...
My guess is that Danny has found a bug in his very old D3AIX 7.4.2
which loses something important in the stack when presented with this
specific sequence of instructions. This is the sort of thing we used
to find in QA when running random tests, and sometimes the trail of
bits set in a certain order by a lot of processes would lead to some
sort of weird failure. With a complete log of the trail of execution,
we'd reboot, run the exact same pattern of tests, and if the issue was
reproduced we'd try to narrow it down, then forward it to Engineering,
who would then (hopefully) fix it before it went out the door.
It's possible that there is a bug, and possibly one that was fixed a
decade ago, soon after this unpatched system went production. Someone
else with a current D3 system should be able to easily try his code to
see if it works. Unfortunately, most people don't have a spare AIX
box where they can swap out their user-coldstart and reboot. As
usual, my recommendation would be to check with TigerLogic Support.
So - I'd like to see the full proc, down to the Hcommand in question
anyway. I don't see any reason why user-coldstart cannot be a proc -
and in fact procs are more versatile than macros so I swap between
them as necessity demands. I'm wondering if there is something else
above that Hcommand that is killing the stack. I'm wondering if Danny
can do something like H!ls and P right above that, just to see if he
can execute a shell command from the proc at coldstart time.
I'm also thinking there might be something in the permissions of the
AIX user booting D3 that stops !hostname from working. (I'd put my
bet on this one.) A lot of people run D3 as root, set D3 to run with
root permissions, and login to D3 via telnet with a user with root
permissions. But that's not a good idea and I'm guessing Southwest
Traders is using different permissions which may affect what the
coldstart can do. For example, the 'hostname' command may be
referring to /etc/hosts, or (not sure here) there may be some DNS
lookup involved. The permissions for D3 at coldstart time may not
allow the operation required to complete the 'hostname' query.
Similarly, it's also possible that there is some issue with specific
shell commands being executed from coldstart with D3 7.4.2 on AIX 5.3.
I don't know if 7.4.2 was actually certified for AIX 5.3. I rather
doubt this is an OS incompatibility, but for example, the issue with
executing 'hostname' from the D3 coldstart may work on a prior AIX
release, or with a more current D3 release over AIX 5.3. Again, I
doubt this is the case, but without being able to do direct testing it
would be one theory I'd consider.
I hope that "food for thought" helps to lead to a resolution.
T
dannyruckel wrote:
>On Nov 25, 4:03�pm, Kevin Powick wrote:
Colin
with Tony's idea on permissions.
Either that or something silly like the program is not cataloged in
the DM account where the user-coldstart runs.
Things to try:
- have your program do something simple like CRT "running
WHAT.SERVER.AM.I"
- if it doesn't work try putting the full path to the program into the
proc RUN myaccount, myprograms WHAT.SERVER.AM.I
- if the CRT works change your execute to !whoami so you know which
user AIX thinks is running the command
hth
Colin Alfke
Calgary, Canada
Pierre
To be able to execute a program in the USER-COLDSTART, you should give
the complet way to find it (ACCOUNT,PROGRAMFILE, PROGRAM). It the
same for the OPEN instruction, then the program will work everywhere
in the database.
Pierre
dannyruckel
tony,
as always, thanks so much for your comprehensive reply.
reading the same, i thought it worth toying with the idea that the
problem wasn't my basic program but perhaps some of the other calls
that were being made in the USER-COLDSTART. i assumed that all these
calls were being made successfully, i never saw mention of them
failing in any error logs (system or runtime). however, it turns out
that both BASIC-PROT-ON and SET-INCREMENTAL-OFF (either/or) are
successfully executed from the proc USER-COLDSTART but neither return
control to the proc USER-COLDSTART for continued execution of the proc
USER-COLDSTART.
could this be an issue specific to proc and these commands because,
though i'm about to test the idea, i don't know that these commands
were an issue when the USER-COLDSTART was configured as a macro.
thanks to all for your input!
Resuscitate CDP!
danny
Tony Gravagno
>i thought it worth toying with the idea that the
>problem wasn't my basic program but perhaps some of the other calls
>that were being made in the USER-COLDSTART. i assumed that all these
>calls were being made successfully, i never saw mention of them
>failing in any error logs (system or runtime). however, it turns out
>that both BASIC-PROT-ON and SET-INCREMENTAL-OFF (either/or) are
>successfully executed from the proc USER-COLDSTART but neither return
>control to the proc USER-COLDSTART for continued execution of the proc
>USER-COLDSTART.
>
>could this be an issue specific to proc and these commands because,
>though i'm about to test the idea, i don't know that these commands
>were an issue when the USER-COLDSTART was configured as a macro.
It sure seems like during the user-coldstart:
PQ
HRUN BP ALL.BASIC.PROGRAMS.KILL.THE.RETURN.STACK
P
HWe never get here
P
It could also be that something specific in each of those programs is
killing the stack, where more sparse code wouldn't. Try a simple CRT
"HAVE A NICE DAY" program, and see if your proc continues after it.
It could also be that the CHAIN in the USER.COLDSTART (note period)
program is causing all stack returns beyond it to fail - it's like a
flag is being set and it's being held through all stack operations
rather than just the current one. To test this you could change
USER.COLDSTART to EXECUTE "USER-COLDSTART" rather than CHAIN.
In any case, based on your feedback, I'm bending toward it being a bug
now. Aside from upgrading D3 or moving to another platform, my
recommendation is simply to make USER-COLDSTART a macro again, and
call to BASIC programs that do more sophisticated work that you may be
asking of proc. It's not worth it to try to teach that old puppy any
new tricks. If it were a new box I'd say file an action item with TL
Support.
>Resuscitate CDP!
>danny
With what? Serious discussion? Current and accurate technical
information? Detailed exchanges about using MV productively in modern
businesses? We tried that and there wasn't enough interest here, or
rather, the noise produced by people who want to live in the dark ages
chased away everyone else. No, CDP is gone. For serious discussions
there are many other forums:
See http://www.pickwiki.com/cgi-bin/wiki.pl?Community
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
NEW: http://Twitter.com/TonyGravagno