16 replies to this topic

[wicoulte]

Hey,

We converted a ProIV 4.0 green screen Tru64 environment to ProIV 4.6 on AIX 5.3.4.0. Everything looks good, except transparent logon doesn't work.

The transparent logon flag is set for the user. If we shell out after logging in, we can see that the environment variables for operator and co/div are set. But when we execute the pro command ( $CHESS_PRO $OPR $COD) we invariably end up on the login screeen. Same thing works fine in the 4.0 environment.

Am I missing something?

Thanks,
Bill

[Mike Schoen]

Have you tried running this command when you are shelled out, to see if its some other
Ie ctrl-c, shell out and then run your command?
Does it take you to the standard pro-iv login screen with the correct operator and password filled in, ie not reversed?
What is the logon link function for the operator - hopefully not "LOGON".

Just some straws to grasp at, because I can't think of any reason why what you are doing should not work.

Mike

[Richard Bassett]

Don't remember ever having a problem with transparent logon on Unix V4.6 so I doubt you're missing anything obvious.

However, at some point (don't remember quite when) something did change in the behaviour of XFERIN I think. So if your code uses XFERIN for any reason and that might cause a problem then you may want to explicitly compare the behaviour of XFERIN between your old and new environments.


Also if you are messing with &#@LOGONB anywhere then maybe worth checking that code for impact by anything that might be different in your new environment.

HTH.. maybe.

[wicoulte]

Have you tried running this command when you are shelled out, to see if its some other
Ie ctrl-c, shell out and then run your command?
Does it take you to the standard pro-iv login screen with the correct operator and password filled in, ie not reversed?
What is the logon link function for the operator - hopefully not "LOGON".

Just some straws to grasp at, because I can't think of any reason why what you are doing should not work.

Mike

Mike,

Yes, I've shelled out and run the command again - and again ended up at the logon screen.

When I get to the logon screen it shows a company division code, but it apparently derives this from the sys2def record for the terminal ID being used. It never displays an operator ID on the logon screen. It appears that the pro command doesn't recognize that it is being passed parameters.

The link to function is UT$CRTU. I've cleared the link to function and tried logging in, but it had no effect.

Thanks,
Bill

[wicoulte]

Don't remember ever having a problem with transparent logon on Unix V4.6 so I doubt you're missing anything obvious.

However, at some point (don't remember quite when) something did change in the behaviour of XFERIN I think. So if your code uses XFERIN for any reason and that might cause a problem then you may want to explicitly compare the behaviour of XFERIN between your old and new environments.


Also if you are messing with &#@LOGONB anywhere then maybe worth checking that code for impact by anything that might be different in your new environment.

HTH.. maybe.

Richard,

I did a logic search and can't find anyplace where we monkey with &#@LOGONB or XFERIN.

Thanks,
Bill

[Richard Bassett]

Strange. Let me ask a pretty stupid question.. you have tried the literal, final command you expect to work from the shell prompt right? You know, something like..

aix> pro JOE IBM

..I just wondered if you are using a different shell by default and something's happening with that?

[wicoulte]

Strange. Let me ask a pretty stupid question.. you have tried the literal, final command you expect to work from the shell prompt right? You know, something like..

aix> pro JOE IBM

..I just wondered if you are using a different shell by default and something's happening with that?

Richard,

Not a dumb question at all... I tried that before (pro WVC OTS) and it didn't work; for grins just I tried it again and it still doesn't work. I've changed the default shell to Bourne and Korn for the Unix account, but neither works.

I always have to enter the operator and password, and then I'm logged in and everything else works fine.

Thanks,
Bill

[Rick Young]

Another straw-grasping thought...

your script to start the transparent login has been recreated identically to your prior environment and has the appropriate PROPATH and PRODATA etc vars being set correctly?

when you attempted your manual command line start pro WCS OTS, did you check for and/or export the aforementioned vars? (which really oughtn't be necessary if you shelled out from within a proiv session...)



-Rick

[wicoulte]

Another straw-grasping thought...

your script to start the transparent login has been recreated identically to your prior environment and has the appropriate PROPATH and PRODATA etc vars being set correctly?

when you attempted your manual command line start pro WCS OTS, did you check for and/or export the aforementioned vars? (which really oughtn't be necessary if you shelled out from within a proiv session...)

Rick,
The

[wicoulte]

Another straw-grasping thought...

your script to start the transparent login has been recreated identically to your prior environment and has the appropriate PROPATH and PRODATA etc vars being set correctly?

when you attempted your manual command line start pro WCS OTS, did you check for and/or export the aforementioned vars? (which really oughtn't be necessary if you shelled out from within a proiv session...)

Rick,


The

[wicoulte]

Another straw-grasping thought...

your script to start the transparent login has been recreated identically to your prior environment and has the appropriate PROPATH and PRODATA etc vars being set correctly?

when you attempted your manual command line start pro WCS OTS, did you check for and/or export the aforementioned vars? (which really oughtn't be necessary if you shelled out from within a proiv session...)

Rick,

The script is not identical, but PROPATH and PRODATA are properly set. After I login, I can shell out and see that PROPATH and PRODATA are properly set.

I can also see that $OPR and $COD (the variables for operator and company/division code) have been exported and properly set.

Thanks,
Bill

[Rob Donovan]

Hi,

I have a faint recollection that we had some problem with this many years ago.

I think it was to do with the encrypted field 'password' on LOGONF (ie the bootstrap file that holds your opr login details), when converting from 4.0 to 4.6

Try deleting and re-adding your opr in $OPR, and see if that helps...

Rob.

[fatboy996]

I think I may have seen this before.

When you created your 4.6 area did you use your 4.0 boots (i.e. isin them over a clean 4.6 set). If so you maybe able to fix it by isining dbase.out (from 4.6 installation over the top). Otherwise you might want to check your dbase.out version and if it is an older 4.6 one, contact PROIV to get a newer one as they would have fixed this type of error by now.

[wicoulte]

Hi,

I have a faint recollection that we had some problem with this many years ago.

I think it was to do with the encrypted field 'password' on LOGONF (ie the bootstrap file that holds your opr login details), when converting from 4.0 to 4.6

Try deleting and re-adding your opr in $OPR, and see if that helps...

Rob.

Rob,

I tried this, but it didn't help.

I found a new problem, which may or may not be related. If we set a function to run on a batch queue and then kick it off from the command line, an entry is created in the batchque.pro file, but the job doesn't actually get started (i.e. 'job QUE1' never appears on the process table). If I recreate the batchque.pro file and clear all the entries, the first time I submit a background job from the command line for a given queue, the screen goes blank, then hangs with the message '/exports/apps: Is a directory' (which is accurate, but curious nonetheless). Subsequent submissions to the same queue do not hang or display the message.

?

Thanks,
Bill

[wicoulte]

I think I may have seen this before.

When you created your 4.6 area did you use your 4.0 boots (i.e. isin them over a clean 4.6 set). If so you maybe able to fix it by isining dbase.out (from 4.6 installation over the top). Otherwise you might want to check your dbase.out version and if it is an older 4.6 one, contact PROIV to get a newer one as they would have fixed this type of error by now.

I started with 4.0 files, isout'ed security.pro, logonf.pro,, termmast.pro, crtctl.pro and sysdef.pro. The I installed 4.6 in the existing environment, and isin'ed those 5 files. This is the procedure recommended in the installation guide.


Thanks,
Bill