Bossman and OpenVMS V7.2-2

[Rob Mooney]

We are still running a menu application called BOSSMAN (V7.3)
Copyright (c) NPR Systems Pty Ltd 1985
and are testing applications on a Development Server running OpeVMS 7.3-2. We are getting an error ..
$ BOSS_MENU
ERROR IN ENVIRONMENT: BOSSMAN DISK AND DIRECTORY:
DSA22
[BOSSMAN_V7]
COMMAND FILE DISK AND DIRECTORY:
DSA22
[BOSSMAN_V7]BOSSMENU.COM;

Is there anyone out there still using this product? It runs OK on OpenVMS V7.3-1.

Thanks

[Rob Mooney]

Sorry the Subject of the initial post should read
"subject: Bossman and OpenVMS V7.3-2"

[Martin P.J. Zinser]

Hello,

No experience with this product, but it seems boss_menu is actually a DCL, so a set verify might proof helpful.

Feel free to post the output of the procedure with verify enabled here if you can not make sense of it by yourself.

Greetings, Martin

[Hein van den Heuvel]

Hmm, I do not see any clear error in that message. It may be checking for some logical names, directoires and or files.

If I had to solve this, I would probably start with SET FILE /WATCH/CLAS=MAJOR to get an impression about which files are used and which ones are trying to be accessed and take it from there.
[Note: you will need to give the account cmkrl temporarely to use set file /watch]

You'll probably also want to carefully review any and all logical names that might be involved (probably BOSS$ or BOSSMAN_ or some such) as well as global symbols that are set up.

As you moved the application did you include and adjust startup scripts? login.com inclusions? sylogin.com?

Good luck,
Hein.

[Rob Mooney]

Boss_Menu is an executable.


Set verify on

CHERUB>sh sym bossman
BOSSMAN == "SPAWN @BOSSMAN_VX:BOSSLOGIN"
CHERUB>set verify
CHERUB>bossman
%DCL-S-SPAWNED, process WAHS_SYSTEM_248 spawned
%DCL-S-ATTACHED, terminal now attached to process WAHS_SYSTEM_248
$! BOSSLOGIN.COM
$!
$ SET NOCONTROL_Y
$! SET NOVERIFY
$ ASSIGN /NOLOG TT SYS$INPUT
$!
$! IF INPUT DEVICE IS A WINDOW PROCESS (IE TT IS A MAILBOX DEVICE) THEN EXIT
$ DEV_TYPE = F$GETDVI("TT","DEVTYPE")
$ IF (DEV_TYPE .EQ. 44) .OR. (DEV_TYPE .EQ. 1) .OR. (DEV_TYPE .EQ. 7) THEN -
GOTO EXIT
$!
$ IF F$MODE() .EQS. "INTERACTIVE" THEN GOTO RUN_INTER
$ RUN_INTER:
$ FILE = "BOSS$COMMAND:SITELOGIN.COM"
$ IF (F$SEARCH(FILE) .NES. "") THEN @BOSS$COMMAND:SITELOGIN.COM
$ @BOSSMAN_V7:BOSSMENU.COM
$! BOSSMENU.COM - BOSSMAN DRIVER
$
$! If any users have access to DCL is desirable to delete all symbols
$! as the user may have defined some symbols to redirect some of the DCL
$! commands and cause them not to work as they should. If you would like
$! to delete the global symbols activate the following two lines by
$! removing the comments.
$
$!! DELETE := DELETE
$!! DELETE /SYMBOL /GLOBAL /ALL
$! SET NOVERIFY
$ SET NOCONTROL_Y
$ SET ON
$ ON WARNING THEN GOTO ERROR
$
$ BYE :== @BOSSMAN_V7:BOSSEXIT.COM
$ RUN_SHARE :== $BOSSEXE_V7:BOSS_RUN_SHARE
$ BOSSSTATUS :== %X00030001
$ LO*GOUT :== @BOSSMAN_V7:BOSSLOGOUT
$ IF "" .EQS. "" THEN MENU_STYLE == ""
$ BOSS_MENU := $BOSSEXE_V7:BOSSMENU
$ IF F$TRNLNM("BOSS_RIGHTSLIST", "LNM$JOB") .EQS. "" THEN -
DEFINE /JOB BOSS_RIGHTSLIST WAHS_SYSTEM6,INTERACTIVE,REMOTE,TSM_
READ_WRITE,SYS$NODE_CHERUB
$
$! If the global symbols were deleted at the start of this command
$! procedure then the system login command procedure may have to be
$! activated again to redefine any global symbols defined by the
$! system login command procedure. Please note that in many system login
$! command procedures a call to SET TERM /INQUIRE is made. This command
$! will kill the terminal's type ahead buffer. It is desirable that this
$! is done once (and only once) during login. See the BOSSMAN manual if
$! you are unsure on how to stop this command from being run each time.
$! If you would like re-run the system login command procedure activate
$! the following line by removing the comment.
$
$!! @SYS$SYLOGIN
$ FILE = "BOSS$COMMAND:BOSSSITE.COM"
$ IF (F$SEARCH(FILE) .NES. "") THEN @BOSS$COMMAND:BOSSSITE.COM
$ FUNCTION = P1 !! TEMPORARY, FOR ALPHAS
$ BOSS_FUNCTION = P1
$LOOP:
$ IF F$TRNLNM("BOSS$REMOVE_IDENTIFIERS", "LNM$SYSTEM",,"EXECUTIVE")
$ ENDIF
$
$ IF F$TRNLNM("BOSS$DEASSIGN_LOGICALS", "LNM$SYSTEM",,"EXECUTIVE")
$ ENDIF
$
$ DEFINE /NOLOG SYS$INPUT TT
$ BOSS_MENU
ERROR IN ENVIRONMENT: BOSSMAN DISK AND DIRECTORY:
DSA22
[BOSSMAN_V7]
COMMAND FILE DISK AND DIRECTORY:
DSA22
[BOSSMAN_V7]BOSSMENU.COM;
$ IF F$SEARCH("BOSS$COMMAND:BOSSSITE_EXIT.COM") .NES. ""
$ ELSE
$ RUN BOSSEXE_V7:BOSSLOGOUT
$ LO*GOUT := LOGOUT
$ LOGOUT
Process WAHS_SYSTEM_248 logged out at 5-MAY-2004 13:34:03.37
%DCL-S-RETURNED, control returned to process _RTA4:

[Hein van den Heuvel]

Thanks for the Verify info, but as you per your initial note, there is no hard error, just a vague complained. "Error in envoronment". Surely it knows exactly what the exact error is but it is not goign to tell that!
No, it wants to give you a 'nice' but useless error message. Don't you hate that!?

Anyway.. that file BOSS$COMMAND:BOSSSITE.COM
It is there? It contains reasonable data for the new environment? No hardcoded node-names?
Tried SET FILE/WATCH?

hein.

[Willem Grooters]

I don't know the product but from the output I can think of some issues.
What does

$ SHOW LOG /FULL BOSS*

tell you?

The listing states:

$ FILE = "BOSS$COMMAND:BOSSSITE.COM"
$ IF (F$SEARCH(FILE) .NES. "") THEN @BOSS$COMMAND:BOSSSITE.COM

but I have no indication that this command-procedure is actually run.

If BOSSSITE.COM defines the environment, it's quite obvious that these to will fail:


$ IF F$TRNLNM("BOSS$REMOVE_IDENTIFIERS", "LNM$SYSTEM",,"EXECUTIVE")
$ ENDIF
$
$ IF F$TRNLNM("BOSS$DEASSIGN_LOGICALS", "LNM$SYSTEM",,"EXECUTIVE")
$ ENDIF

It seems that neither BOSS$REMOVE_IDENTIFIERS nor BOSS$DEASSSIGN_LOGICALS have been defined /SYSTEM/EXEC - so all identifiers to be removed, or logicals set will still be active - which could cause your problem.

HTH

Willem

[Rob Mooney]

First time on these Forums and the response is great..

Other things that may help..
I have reinstalled the product from original savesets to see it that would help fix problem. I am pretty sure the "ENVIRONMENT" (that is logicals etc..)is ok and the same as production. I am 80% sure this was working until I upgraded to V7.3-2 I am planning on restoring system disk to prior to upgrade and see if this helps.
This will take a day or so.

Below is text from some of the info requested

CHERUB> SET watch file /CLAS=MAJOR
CHERUB>set ver
CHERUB>bossman
%DCL-S-SPAWNED, process WAHS_SYSTEM_103 spawned
%DCL-S-ATTACHED, terminal now attached to process WAHS_SYSTEM_103
$! BOSSLOGIN.COM
$!
$ SET NOCONTROL_Y
$! SET NOVERIFY
$ ASSIGN /NOLOG TT SYS$INPUT
$!
$! IF INPUT DEVICE IS A WINDOW PROCESS (IE TT IS A MAILBOX DEVICE) THEN EXIT
$ DEV_TYPE = F$GETDVI("TT","DEVTYPE")
$ IF (DEV_TYPE .EQ. 44) .OR. (DEV_TYPE .EQ. 1) .OR. (DEV_TYPE .EQ. 7) THEN -
GOTO EXIT
$!
$ IF F$MODE() .EQS. "INTERACTIVE" THEN GOTO RUN_INTER
$ RUN_INTER:
$ FILE = "BOSS$COMMAND:SITELOGIN.COM"
$ IF (F$SEARCH(FILE) .NES. "") THEN @BOSS$COMMAND:SITELOGIN.COM
$ @BOSSMAN_V7:BOSSMENU.COM
$! BOSSMENU.COM - BOSSMAN DRIVER
$
$! If any users have access to DCL is desirable to delete all symbols
$! as the user may have defined some symbols to redirect some of the DCL
$! commands and cause them not to work as they should. If you would like
$! to delete the global symbols activate the following two lines by
$! removing the comments.
$
$!! DELETE := DELETE
$!! DELETE /SYMBOL /GLOBAL /ALL
$! SET NOVERIFY
$ SET NOCONTROL_Y
$ SET ON
$ ON WARNING THEN GOTO ERROR
$
$ BYE :== @BOSSMAN_V7:BOSSEXIT.COM
$ RUN_SHARE :== $BOSSEXE_V7:BOSS_RUN_SHARE
$ BOSSSTATUS :== %X00030001
$ LO*GOUT :== @BOSSMAN_V7:BOSSLOGOUT
$ IF "" .EQS. "" THEN MENU_STYLE == ""
$ BOSS_MENU := $BOSSEXE_V7:BOSSMENU
$ IF F$TRNLNM("BOSS_RIGHTSLIST", "LNM$JOB") .EQS. "" THEN -
DEFINE /JOB BOSS_RIGHTSLIST WAHS_SYSTEM6,INTERACTIVE,REMOTE,TSM_
READ_WRITE,SYS$NODE_CHERUB
$
$! If the global symbols were deleted at the start of this command
$! procedure then the system login command procedure may have to be
$! activated again to redefine any global symbols defined by the
$! system login command procedure. Please note that in many system login
$! command procedures a call to SET TERM /INQUIRE is made. This command
$! will kill the terminal's type ahead buffer. It is desirable that this
$! is done once (and only once) during login. See the BOSSMAN manual if
$! you are unsure on how to stop this command from being run each time.
$! If you would like re-run the system login command procedure activate
$! the following line by removing the comment.
$
$!! @SYS$SYLOGIN
$ FILE = "BOSS$COMMAND:BOSSSITE.COM"
$ IF (F$SEARCH(FILE) .NES. "") THEN @BOSS$COMMAND:BOSSSITE.COM
$ FUNCTION = P1 !! TEMPORARY, FOR ALPHAS
$ BOSS_FUNCTION = P1
$LOOP:
$ IF F$TRNLNM("BOSS$REMOVE_IDENTIFIERS", "LNM$SYSTEM",,"EXECUTIVE")
$ ENDIF
$
$ IF F$TRNLNM("BOSS$DEASSIGN_LOGICALS", "LNM$SYSTEM",,"EXECUTIVE")
$ ENDIF
$
$ DEFINE /NOLOG SYS$INPUT TT
$ BOSS_MENU
ERROR IN ENVIRONMENT: BOSSMAN DISK AND DIRECTORY:
DSA22
[BOSSMAN_V7]
COMMAND FILE DISK AND DIRECTORY:
DSA22
[BOSSMAN_V7]BOSSMENU.COM;
$ IF F$SEARCH("BOSS$COMMAND:BOSSSITE_EXIT.COM") .NES. ""
$ ELSE
$ RUN BOSSEXE_V7:BOSSLOGOUT
$ LO*GOUT := LOGOUT
$ LOGOUT
Process WAHS_SYSTEM_103 logged out at 5-MAY-2004 18:27:39.78
%DCL-S-RETURNED, control returned to process WAHS_SYSTEM6
CHERUB>
CHERUB>
CHERUB>
CHERUB>
CHERUB>

CHERUB>SHOW LOG /FULL BOSS*

(LNM$PROCESS_TABLE) [kernel]
[no protection information]
%XQP, Thread #0, Lookup (11928,124,0) Status: 00000001
%XQP, Thread #0, Access SECURESHR.EXE;1 (11928,124,0) Status: 00000001
%XQP, Thread #0, Control function (11928,124,0) Status: 00000001
%XQP, Thread #0, Deaccess (11928,124,0) Reads: 3, Writes: 0, Status: 00000001

(LNM$JOB_815EE880) [kernel] [shareable] [Quota=(3168,4096)]
%XQP, Thread #0, Access RIGHTSLIST.DAT;2 (8090,81,0) Status: 00000001
[Protection=(RWCD,RWCD,,)] [Owner=[WAHS_SYSTEM_USERS,WA
HS_SYSTEM6]]

"BOSS_RIGHTSLIST" [super] = "WAHS_SYSTEM6"
= "INTERACTIVE"
= "REMOTE"
= "TSM_READ_WRITE"
= "SYS$NODE_CHERUB"

(LNM$GROUP_000010) [kernel] [shareable,group]
[Protection=(RWCD,R,R,)] [Owner=[WAHS_SYSTEM_USERS,*]]

(LNM$SYSTEM_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

"BOSS$ACCOUNTING" [exec] = "YES"
"BOSS$AUDIT_FLAG" [exec] = "NO"
"BOSS$BACKUP" [exec] = "NO"
"BOSS$BYPASS" [exec] = "YES"
"BOSS$COMMAND" [exec] = "DSA22:[BOSSMAN_V7.COMMAND]"
"BOSS$DEASSIGN_LOGICALS" [exec] = "NO"
"BOSS$EXAMPLES" [exec] = "DSA22:[BOSSMAN_V7.EXAMPLES]"
"BOSS$EXAMPLEXE" [exec] = "DSA22:[BOSSMAN_V7.EXAMPLES.AXP]"
"BOSS$LICENCE" [exec] = "W-WMFI-HICD-HIZF-NBKG-JNJJ"
"BOSS$LOGICAL_TABLE" [exec] = "NO"
"BOSS$MESSAGE1" [exec] = "PLEASE LOG OUT WHEN YOU LEAVE YOUR TERMINAL"
"BOSS$MESSAGE2" [exec] = "REPORT ANY PROBLEMS WITH THIS MENU TO EXT. 2345. TH
ANK YOU."
"BOSS$NET" [exec] = "DSA22:[BOSSMAN_V7.NET]"
"BOSS$NETEXE" [exec] = "DSA22:[BOSSMAN_V7.NET.AXP]"
"BOSS$PASS_PARAMS" [exec] = "YES"
"BOSS$PROCESS_FLAG" [exec] = "LAST"
"BOSS$SCRATCH" [exec] = "DSA22:[BOSSMAN_V7.SCRATCH]"
"BOSS$TITLE" [exec] = " W.A.H.S. APPLICATIONS MENU"
"BOSS$UTILEXE" [exec] = "DSA22:[BOSSMAN_V7.UTILITY.AXP]"
"BOSS$UTILITY" [exec] = "DSA22:[BOSSMAN_V7.UTILITY]"
"BOSSACC_BOSSFILE" [super] = "BOSSMAN_V7:BOSSACCTNG.DAT"
"BOSSACC_OUTFILE" [super] = "BOSSMAN_V7:BOSSACC.DAT"
"BOSSACC_VMSFILE" [super] = "SYS$MANAGER:ACCOUNTNG.DAT"
"BOSSCOM" [exec] = "_DSA22:[BOSSCOM]"
"BOSSEXE" [exec] = "BOSSEXE_V7"
"BOSSEXE_V7" [exec] = "DSA22:[BOSSMAN_V7.AXP]"
"BOSSLINESHR2_V7" [exec] = "BOSSEXE_V7:BOSSLINESHR2_V7.EXE"
"BOSSLINESHR2_V7_TV" [exec] = "BOSSEXE_V7:BOSSLINESHR2_V7.EXE"
"BOSSLINESHR_V7" [exec] = "BOSSEXE_V7:BOSSLINESHR_V7.EXE"
"BOSSLINESHR_V7_TV" [exec] = "BOSSEXE_V7:BOSSLINESHR_V7.EXE"
"BOSSMAN_V7" [exec] = "DSA22:[BOSSMAN_V7]"
"BOSSMAN_VX" [exec] = "DSA22:[BOSSMAN_V7]"
"BOSSMENU1SHR_V7" [exec] = "BOSSEXE_V7:BOSSMENU1SHR_V7.EXE"
"BOSSMENUSHR_V7" [exec] = "BOSSEXE_V7:BOSSMENUSHR_V7.EXE"
"BOSSPRINT" [exec] = "SYS$PRINT"
"BOSSPWD_V7" [exec] = "BOSSEXE_V7:BOSSPWD_V7.EXE"
"BOSS_KEY_F10" [super] = "0"
"BOSS_KEY_F8" [super] = "2"
"BOSS_KEY_F9" [super] = "1"
"BOSS_KEY_HELP" [super] = "5"
"BOSS_KEY_NEXT_SCREEN" [super] = "3"
"BOSS_KEY_PREV_SCREEN" [super] = "4"

(LNM$SYSCLUSTER_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

(DECW$LOGICAL_NAMES) [exec] [shareable]
[Protection=(RWCD,RWCD,R,R)] [Owner=[SYSTEM]]
%XQP, Thread #0, Deaccess (8090,81,0) Reads: 6, Writes: 0, Status: 00000001
CHERUB>
CHERUB>dire BOSS$COMMAND:

Directory DSA22:[BOSSMAN_V7.COMMAND]

BOSSSITE.TEMPLATE;12 BOSSSITE_EXIT.TEMPLATE;7
SITELOGIN.TEMPLATE;12

Total of 3 files.
CHERUB>ty DSA22:[BOSSMAN_V7.COMMAND]BOSSSITE.TEMPLATE;12
$! BOSSSITE.COM
$!
$! This command file is called when a Bossman user logs in, and when they
$! logout from DCL to return to the menu.
$! This command file and the containing directories [.COMMAND] require
$! WORLD EXECUTE protection.
$! This command file is optional and may be deleted if not required.
CHERUB>
CHERUB>type BOSS$COMMAND:BOSSSITE.COM
%XQP, Thread #0, Lookup BOSSMAN_V7.DIR;1 (384,2,0) Status: 00000001
%XQP, Thread #0, Lookup COMMAND.DIR;1 (387,1,0) Status: 00000001
%XQP, Thread #0, Lookup (387,1,0) Status: 00000910
%TYPE-W-SEARCHFAIL, error searching for DSA22:[BOSSMAN_V7.COMMAND]BOSSSITE.COM;
-RMS-E-FNF, file not found
CHERUB>

[Hein van den Heuvel]

That bosssire.com appears to be optional so we can ignore it:

"$! This command file is optional and may be deleted if not required."

The set watch more or less failed as was not active in the sub-process that was spawned.
You may have to put that command in the bosssite.com to get it active at the right time.
What is that spawn doing?
Can you run whatever it is running interactively?

Hein.

[Martin P.J. Zinser]

Hi,

yup, looking at the output you should be able to do a set watch and then just run the boss_menu executable interactively.

Btw, next time around you might want to edit one particular logical before posting ;-)

Greetigns, Martin

[Martin Hoogenboom]

Hi,

Just guessing.
Could this be an ODS2/ODS5 issue ?

MartinH

[Rob Mooney]

I have restored an image of the system disk V7.3-1, and the application now works!.

I guess since I have no support on this product I was really hoping that someone out there may still be using this BOSSMAN and had already come accross this problem.

If I come across a fix/solution I will post it here.

regards

[Hein van den Heuvel]

Thanks for the feedback.
I though Martin might have hit it with the ODS5 suggestion. Oh well.

Hein.

[Jan van den Ende]

Hi,

just shooting blindfolded in the dark, but I _DO_ remember an issue (with SYBASE, upgrading from 7.1-2 to 7.2-1, but still) that WAS showing some similarity.
In the end it turned out that some process quota had to be enlarged, but before we found that..
If you are really lucky, it might even be that your subprocess failed, and then the master decided to generate an error.
In that case (or anyway) check the final process status of your subprocess in ACCOUNTNG. If the error was trapped, signalled, end then a 'nice' process shutdown was done, the status will be success and this is not any help. But if you ARE lucky, the final process status will tell you WHAT the problem is, and that is usually 90% of the solution...

About the ODS-5 issue: did you do the ODS-2 => ODS-5 conversion? (you chose whether to do so or not). If you DID, then (a lot of work) can you upgrade your now-running 7.3-1 again WITHOUT changing to ODS-5? If you DID NOT convert, then ODS-5 is not an issue and you (we) should look somewhere else.

hth

Jan

[Rob Mooney]

I will check the process quota's / Accounting.

Sorry I forgot to mention I did not upgrade to ODS-5.

I am now running a two member cluster one on V7.3-1 and one member V7.3-2, I do need the V7.3-1 member to do some application testing, but I will keep the V7.3-2 member to try and sort this out.
I must admit I didn't check any process quota's but have run from an account with "in the past" plenty of quota's but will check accounting today.

Regards