Here's something new I'm thinking of doing that some may find interesting.

There may be an easy solution I'm simply missing but then again maybe not.

We need a way to educate the users on what to do when they encounter a debug object in Production without applying any formal training. The task of notifying users via email is too time consuming and seldom do users read the email anyways.

We obviously try to limit our need to run anything in debug on Production, but in some cases it can't be helped. We only want to notify the users who may be affected so we don't want to broadcast to everyone.

We can't use before.program in debug to post a message to 'press continue' since the user would need to either hit
's' or 'c' to even see this message.

We've created a session that allows us to see who can run what either via menu or DEMs, which could filter out the affected
users if the object is used in the session, however this does not take into account objects for sub-sessions activated within other
sessions or libraries etc.

We've created a new table to list what objects are in debug (start and end dates and times) by which Baan instance and layer so we have a way of tracking what could pop-up.

What we need to do now is create something that would force a message when the object is used or else suppress the debug screen for the user or force continue. It would be nice if this could be an option controlled by user.

Any ideas would be great and all would be appreciated.

Regards,

BaanTech

Hi,

In the bwc-file add the following statement at the command line:


-nodebug


debug mode will be suppressed.

There is no need to keep track of sources in debug mode.

There is this option to change the fd file. Adding
{bsp} on a copy of a line then that particular line only applies for user bsp. When you add the path to the debug files in that line only, then only bsp will see the debug object.

Hope this is clear enough to use it... no more time to explain in more detail...

This would probably be the simplest solution, but in our case this would result in too much overhead.

Our bwcs are stored on 4 main citrix servers and we would need to make these updates on each of them (not always in synch). We could create some auto tools to do this, but really this is just an idea we're throwing around and it could be resolved by simple education.

PS. We keep track of all debug objects as part of our administrative tools in order to ensure we know what instance is in debug and since when so that we can replace any debug objects in a timely manner.

Regards,

BaanTech

My last reply was in regards to FransG and I'll take a look at the idea posted by Omeluuk.

Thanks for the feedback.

This is what I do
#1 Compile the script in Debug mode
#2 Run the session
#3 Compile the script again (no debug this time)

Note : Step # 3 should be executed immediately after step # 2 :)

The chances of a user running a session between Steps #2 and #3 is pretty slim.

My users have never caught me doing this :D


Cheers,
Popeye!

There are different approaches to handle this issue -

As others suggested

1. use the -nodebug.

2. Create a check-out VRC at the production VRC level and only the developers have the authority. So when they want to investigate the problems with live data, they checkout and put in debuggers and fix it and when they check-in the changes are live.

I guess you need to have a formal procedure to this. We have 2 base-code VRC levels, where the based code goes to VRC "abc" and another VRC below it "abcd" where there is no actual code and the developer copy there and checkout and do fixes. We call that as the emergency VRC. The developer does not have authorizations to modify the base code. After code migrations the all the emergency components are deleted. All the users/developers are linked to the package combination which has the emergency VRC as the 1st level.

It works good for us and our end users are happy that they get faster bug fixes. :)

... if only it was that simple ...

The session is tfacp1132s000 which is basically used constantly
by our finance people.

We were actually looking at using debug to get around the attr.input = false line on field tdpur046.clos for a few orders
that were saved and posted. We wanted to flip the flag via
the session instead of via GTM and let the code carry through.

This would probably take us some time since we wanted to
verify the pur045, pur046 and acp200 values for each occurence
before we made the changes.

On a side note:

I know we can restrict access on the form, but is there anything outside of the code that can override the attr.input statements
in the code.

On another note:

What we wanted to do gave us problems when we attempted it in test. It appears you actually need to be in the same batch number of the invoice being updated or else the system goes haywire. This could be a problem in cases where the batch is already finalized.

GTM ... here we come ... everything's crossed ...

BaanTech

Man you people are too quick ... There's always an extra
post that appears between my reply and the one I'm replying to.

In reply to NPRao.

Quick question:
Does the 'below it' mean like c1 is below/behind c2 when actually
looking at it from a derviation/compare with perspective, or
it is like c3 is below c2 like someone would

If all users are logging into the emergency level 'abcd' would the
users not just see all 'abc' components and in the odd case the 'abcd' debug if it exists. If the debug object exists in 'abcd' then all users without -nodebug could potentially be affected.

Doing this would allow us to save the current Production object 'as is' during debugging as we would have a new object in the 'emergency' layer and then we replace the current Production object with the fixed version only when complete.

As of now instead of this we are using our 'Component in Debug' table as a method of automating the backing up the original object by instance and layer. When the component is removed from this table then the object file is reverted back to the original.

The companies have to be linked to either 'abc' or 'abcd'. How can the debug object be accessing Live data but not actually live
?

BaanTech

or ... (for got to finish a sentence)
is it like c3 is below c2 like someone would write on a board.

eg.

c1
|
c2
|
c3
|
c3gls0

PS. What is the (un)official VRC structure design standard, any
takers, or will this just open up a can of worms.

BaanTech

Does the 'below it' mean like c1 is below/behind c2 when actually
looking at it from a derviation/compare with perspective, or
it is like c3 is below c2 like someone would

--> Yes I meant a derived VRC tree structure.

If all users are logging into the emergency level 'abcd' would the
users not just see all 'abc' components and in the odd case the 'abcd' debug if it exists. If the debug object exists in 'abcd' then all users without -nodebug could potentially be affected.

--> The VRC search mechanism, finds the last used components in the VRC tree. If there are components in "abcd", the components are picked up from "abc" VRC.

Doing this would allow us to save the current Production object 'as is' during debugging as we would have a new object in the 'emergency' layer and then we replace the current Production object with the fixed version only when complete.

The companies have to be linked to either 'abc' or 'abcd'. How can the debug object be accessing Live data but not actually live
?
--> Changes are effective only when the developer checks in the code.

As of now instead of this we are using our 'Component in Debug' table as a method of automating the backing up the original object by instance and layer. When the component is removed from this table then the object file is reverted back to the original.

--> with the checkout and the SCM functionality you need not do this. This requires a good discipline with the Software Engineers.

The companies have to be linked to either 'abc' or 'abcd'. How can the debug object be accessing Live data but not actually live ?

--> Yes. BUT, we have production company data refreshed to DEV and QA every night. The developers can test the code against the production data, fix scripts, then put the code in the emergency VRC. The Emergency VRC is only used in a day time live, if only it is a serious problem and stops the users from using the sessions and need an immediate fix.

NPRao,

Sorry I'm still a little confused ...

Is the derivation abc -> abcd or abcd -> abc where c1 -> c2 ?

If abc -> abcd and the users are in abcd and the object is in
abcd then how can the components be picked from abc ?

**** Quote ****
The VRC search mechanism, finds the last used components in the VRC tree. If there are components in "abcd", the components are picked up from "abc" VRC.

(Also, in our case we need to assign a value in debug to correct the Live data so we have no alternative but to use debug - I agree using a mirror of prod on a daily basis is the best way to
debug, but it doesn't help when the issue's logged for today).

It's been about 2.5 years since I last managed a Baan V environment so my knowledge of the check in/out concept isn't what it used to be.

When you mention SCM functionality are you referring to something specific ? The check-in/out is teminology from Baan V,
but were on c3 (sorry should have mentioned this earlier).

We've developed our own tools which allow us to track all component movements based on using version control with the Baan PCA tags by instance and layer. We can list all components
by instance and layer and manage changes via linking PCA tags to projects, PCA tags to code tags, Projects to Requests, Projects to Budgets and PCA tags to Requests. At any given time we have the ability to now know if changing a component will conflict with any other changes. We have a method on knowing all
Projects and requests where specific components were modified and this allows us the ability to apply any additional non-supported overhead (eg. gaps) to the correct budget actuals once we pinpoint what specific request which caused the non-standard issue. We are also using these tools to define our implementation procedures which in some cases includes external programs (VB) etc.

We are also planning on using these tools to automate the scheduled of our environment refresh and test windows.

Thanks for all the feedback.

BaanTech

Now I have some more time to explain my contribution.

In my current role I need to place debug objects on our customers' systems. But of course without bugging normal users.

The login used is bsp (or baan).
Under the ${HOME} dir (or any other place) create subdir debug, under that dir create virtual VRC directory like in $BSE/application/<pp><PACKAGE_COMB>/ for both include files used, program scripts and objects.

We compile objects in debug mode (on an other system, but may also be on the same system). Check the compiled object file, if it is in debug mode with `bic_info6.1 -h`(object_flags = 2=DEBUG 8=DLL). When in debug, then copy it to the {$HOME}/debug/o<pp><mmm> path.

Then compile object again in normal mode for not bothering others.

Now is the time to gather other needed things like program scripts and include scripts (only relevant includes can be taken).

In the end the fd file of the used package combination needs to be modified, to have the search path for the used user via the debug dir.

An example. Compile the script tdpur4120 in debug mode.
$> bic_info6.1 otdpur4120 -h
---------------------------GENERAL INFO---------------------------------
Object = otdpur4120
Pathname = /c3/b40c/own/tdB40O_c5/otdpur/opur4120
---------------------------OBJECT HEADER--------------------------------
Magic = [_bic_dll_]
relno = 61
obj_revision = 1
object_flags = 2=DEBUG 8=DLL
Copy the object in debug mode and script into the debug directory:
cp -p `explode6.1 otdpur4120` ${HOME}/debug/otdpur/.
cp -p `explode6.1 ptdpur41200` ${HOME}/debug/ptdpur/.
(recompile in normal mode)
Gather needed include files
$>cat ${HOME}/debug/ptdpur/* | grep include
... a.o. ...
#include "itccom0007" | round quantities
#include "itccom0015" | determine field info
#include "itccom0100" | give message if record not marked
...
#include "itdpur0017" | insert Purchase Order Line History
#include "itdpur0021" | print the goods received note again
... I decided to only do copy icom0015, icom0007, ipur0021:
$> cp -p `explode6.1 itccom00070` ${HOME}/debug/itccom/.
$> cp -p `explode6.1 itccom00150` ${HOME}/debug/itccom/.
$> cp -p `explode6.1 itdpur00210` ${HOME}/debug/itdpur/.
Edit fd file for used package combination to point to debug dir:
$> vi $BSE/lib/fd<PACKAGE_COMB>
Search for lines with `otd:`, `ptd:`, `itc:` and `itd:`. Copy these lines (yyP) and edit the first line:
add "{bsp}" in front of the line and add "${HOME}/debug:" after the above search terms. So:
itc:/c3/b40c/own/tcB40O_c5:/c2/b40c/bug/tcB40U_c5: ...
becomes:
{bsp}itc:${HOME}/debug:/c3/b40c/own/tcB40O_c5:/c2/b40c/bug/tcB40U_c5: ...
itc:/c3/b40c/own/tcB40O_c5:/c2/b40c/bug/tcB40U_c5: ...
meaning bsp uses this alternative VRC search path for includes of package tc.
Run session in debug for bsp only.

OmeLuuk,

This sounds like it could work. I'll give it a try as soon as I get time. It's month end so this could take a few days ...

I'm confused as to why I need to copy the includes as well.

Is this just in case we want to step through the function source
as well? Normally if we move something in debug from one
Baan instance to another we simply do a cut and paste of the
source and object. In some cases we already have the function
source in prod or ptch (PROD or Patch) from previous activities
of since long gone vendors.

Wouldn't I only need to move the include source over to the debug VRC if I know that I will be stepping within this include.

I won't be compiling in Production so I wouldn't need all include source for this.

(PS. For other users and vendors we do a true export for debug and another to revert).

What would happen if I try to run anything (on td) other than tdpur4120 while my fd has been changed ? (I would think everything else should be unaffected)

It looks like if the object does not exist in the debug dir that the next layer is checked and so on ... so there may not be a need to continously revert the fd file back to how it was since the debug dir will only come into play if the object exists here.

Thanks to all who have posted to this thread.

BaanTech:confused:

Hi Tech,

Sorry for the confusion.

The Emergency VRC "abcd" is derived from "abc".

the users are in abcd and the object is in abcd then that object is used. And if the object is not present in "abcd", then the object is picked up from the "abc" VRC based on the VRC tree structure.

**** Quote ****
The VRC search mechanism, finds the last used components in the VRC tree. If there are components in "abcd", the components are picked up from "abc" VRC.
--> My mistake, typos. Correction -
The VRC search mechanism, finds the last used components in the VRC tree. If there are "no" components in "abcd", the components are picked up from "abc" VRC.

As OmeLuuk, gave you a tip, you can make a BaaN Tool/session, and add to a job, which monitors all the packages objects if they are in debuggers and sends you an automated email or report. I made one here.

In BaaN Tools terminology, SCM means the Software Configuration Management, which includes the check-in, check-out etc. In funtionality terms, people refer it to as Supply Chain Management.

I guess most customers make their own tracking tools and we do have one, which has the setup for baan component migrations, shell scripts, oracle sql's and any interfaces.

Originally posted by BaanTech
...I'm confused as to why I need to copy the includes as well. Is this just in case we want to step through the function source as well?...Indeed this is only if you need to debug the function source as well. Without source in available, you will jump over it. When the function sources are available in deeper derivation structures, you will not need to copy the includes either. In our case we (almost) always need to copy includes too, so I included that too. It also demonstrates that you can put components of different packages (in the exapmle tc and td) under the same debug directory, provided you make the correct changes in the fd file. You will need the includes when you want to recompile too for example when you edit the script during the debug session with vi<Enter>.What would happen if I try to run anything (on td) other than tdpur4120 while my fd has been changed ? (I would think everything else should be unaffected)...It is affected, but in a limited way: because in the fd file you add ${HOME}/debug to the search path for he specific components, all components matching will first be sought for in the specified directory. There that component is not present, so there will be a slight delay. That is all....there may not be a need to continously revert the fd file back to how it was since the debug dir will only come into play if the object exists here.Indeed. And what I did not describe yet is the way to undo things: That is quite easy. Save script changes is they are made, using the vi<Enter> option in the debugger Run ttadv5210m000 without any option checked and process (Original fd file is recreated). Enter the `rm -R ${HOME}/debug` commandBy the way I explained this for Unix with UNIX command, the same applies for NT. But the other way of file caching by the OS and the way shared memory is handled. In the worst case reboot may be needed.

I use the same technique as you, but there is one major downside to it.
Whenever somebody converts something to runtime, the fd6.2 file gets rewritten. I've had that happen several times when installing debug objects for BGS.
Before BGS is done, one of my esteemed collegues installs a patch or moves an object in production and next thing I know BGS is on the line about their session no longer running in debug mode.

I still agree this is the best way to handle this, but it requires a little coordination if you work in a team.

That is true, so make a copy of your edited fd file if possible use chmod 744 fd<OPER>Congrats on your 200th post!~