- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Why VERIFY is ON ?
Operating System - OpenVMS
1756742
Members
2352
Online
108852
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-25-2011 09:35 AM
тАО05-25-2011 09:35 AM
I have a strange Problem with something doing a SET VERIFY before SYLOGIN procedure is running !
This are the first three lines in SYLOGIN.COM
$ WRITE SYS$OUTPUT "## Start of ''F$ENVIROMENT("PROCEDURE")' ##"
$ sav_ver=F$VERIFY(0)
$ IF sav_ver THEN WRITE SYS$OUTPUT "Verify is on"
This are the last three Lines in SYLOGIN.COM
$ sav_ver=F$VERIFY(sav_ver)
$ WRITE SYS$OUTPUT "## End of ''F$ENVIROMENT("PROCEDURE")' ##"
$ EXIT 'sts'
If I login interactive to this System I see the following:
$ ssh gdc138
******************************************************************************
* *
* Unauthorized access is prohibited. Misuse will be prosecuted. *
* *
* Unberechtigter Zugriff ist verboten. Allf├дlliger Missbrauch wird geahndet. *
* *
* Acc├иs interdit sans autorisation. Tout abus sera puni. *
* *
* L'accesso senza autorizzazione ├и vietato. Ogni abuso sar├а punito. *
* *
******************************************************************************
Last interactive login on Wednesday, 25-MAY-2011 18:52:00.09
Last non-interactive login on Wednesday, 25-MAY-2011 18:52:45.71
## Start of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
## End of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
>>> there is nothing between the Start and the End Markers of SYLOGIN.COM which means VERIFY is OFF
Then I have a Commandfile witch does nothing, just used to show the problem.
$ TYPE x.com
$ WRITE SYS$OUTPUT "## Start of ''F$ENVIROMENT("PROCEDURE")' ##"
$ WRITE SYS$OUTPUT "## End of ''F$ENVIROMENT("PROCEDURE")' ##"
I Submit x.com
$ submit/log x
Job X (queue GDC139_BATCH, entry 602) started on GDC139_BATCH
$ typ x.log
$ WRITE SYS$OUTPUT "## Start of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##"
## Start of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
$ sav_ver=F$VERIFY(0)
Verify is on
$ WRITE SYS$OUTPUT "## End of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##"
## End of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
$ EXIT 1
$ sav_ver=F$VERIFY(0)
$ WRITE SYS$OUTPUT "## Start of KUDA_USERS:[USER5.GENI]X.COM;4 ##"
## Start of KUDA_USERS:[USER5.GENI]X.COM;4 ##
$ WRITE SYS$OUTPUT "## End of KUDA_USERS:[USER5.GENI]X.COM;4 ##"
## End of KUDA_USERS:[USER5.GENI]X.COM;4 ##
GENI job terminated at 25-MAY-2011 18:59:09.43
As you can see there is the Text . SYLOGIN writes this text in Line 3 of the Commandfile, which means VERIFY is ON !!!!!
It seems, that VERIFY is ON already before SYLOGIN.COM is running. Does somebody knows where this happens? Is there a Sysgen Parameter which enforces a VERIFY ON?
ItтАЩs OpenVMS 8.4 on IA64
This are the first three lines in SYLOGIN.COM
$ WRITE SYS$OUTPUT "## Start of ''F$ENVIROMENT("PROCEDURE")' ##"
$ sav_ver=F$VERIFY(0)
$ IF sav_ver THEN WRITE SYS$OUTPUT "Verify is on"
This are the last three Lines in SYLOGIN.COM
$ sav_ver=F$VERIFY(sav_ver)
$ WRITE SYS$OUTPUT "## End of ''F$ENVIROMENT("PROCEDURE")' ##"
$ EXIT 'sts'
If I login interactive to this System I see the following:
$ ssh gdc138
******************************************************************************
* *
* Unauthorized access is prohibited. Misuse will be prosecuted. *
* *
* Unberechtigter Zugriff ist verboten. Allf├дlliger Missbrauch wird geahndet. *
* *
* Acc├иs interdit sans autorisation. Tout abus sera puni. *
* *
* L'accesso senza autorizzazione ├и vietato. Ogni abuso sar├а punito. *
* *
******************************************************************************
Last interactive login on Wednesday, 25-MAY-2011 18:52:00.09
Last non-interactive login on Wednesday, 25-MAY-2011 18:52:45.71
## Start of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
## End of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
>>> there is nothing between the Start and the End Markers of SYLOGIN.COM which means VERIFY is OFF
Then I have a Commandfile witch does nothing, just used to show the problem.
$ TYPE x.com
$ WRITE SYS$OUTPUT "## Start of ''F$ENVIROMENT("PROCEDURE")' ##"
$ WRITE SYS$OUTPUT "## End of ''F$ENVIROMENT("PROCEDURE")' ##"
I Submit x.com
$ submit/log x
Job X (queue GDC139_BATCH, entry 602) started on GDC139_BATCH
$ typ x.log
$ WRITE SYS$OUTPUT "## Start of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##"
## Start of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
$ sav_ver=F$VERIFY(0)
Verify is on
$ WRITE SYS$OUTPUT "## End of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##"
## End of SYS$COMMON:[SYSMGR]SYLOGIN.COM;7 ##
$ EXIT 1
$ sav_ver=F$VERIFY(0)
$ WRITE SYS$OUTPUT "## Start of KUDA_USERS:[USER5.GENI]X.COM;4 ##"
## Start of KUDA_USERS:[USER5.GENI]X.COM;4 ##
$ WRITE SYS$OUTPUT "## End of KUDA_USERS:[USER5.GENI]X.COM;4 ##"
## End of KUDA_USERS:[USER5.GENI]X.COM;4 ##
GENI job terminated at 25-MAY-2011 18:59:09.43
As you can see there is the Text
It seems, that VERIFY is ON already before SYLOGIN.COM is running. Does somebody knows where this happens? Is there a Sysgen Parameter which enforces a VERIFY ON?
ItтАЩs OpenVMS 8.4 on IA64
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-25-2011 09:56 AM
тАО05-25-2011 09:56 AM
Re: Why VERIFY is ON ?
See
http://h71000.www7.hp.com/doc/83final/9996/9996pro_224.html
"The default for batch jobs is SET VERIFY."
http://h71000.www7.hp.com/doc/83final/9996/9996pro_224.html
"The default for batch jobs is SET VERIFY."
I have one, but it's personal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-25-2011 01:45 PM
тАО05-25-2011 01:45 PM
Solution
Heinz,
As Jess has stated, the default for batch jobs is verify enabled. I don't think you can change the initial state.
Trivia in your posted code:
>$ WRITE SYS$OUTPUT "## Start of ''F$ENVIROMENT("PROCEDURE")' ##"
>$ sav_ver=F$VERIFY(0)
>$ IF sav_ver THEN WRITE SYS$OUTPUT "Verify is on"
it should say "Verify WAS on" since you disabled it on the line before. sav_ver tells you the previous state.
This is the code I use as first line of command procedures:
$ verf='F$VERIFY(F$TRNLNM(F$PARSE(F$ENVIRONMENT("PROCEDURE"),,,"NAME")+"_VERIFY"))'
By default it will silently turn verification off. The leading quote on F$VERIFY means the lexical function is executed BEFORE the line is verified. In contrast, as your listing shows, if verification is on, the line (without quotes around F$VERIFY):
$ sav_ver=F$VERIFY(0)
will cause the F$VERIFY to execute AFTER the line is verified, thus the line will be displayed.
My code also allows verification to be enabled for selected procedures by defining a logical name_VERIFY. This can be very handy for debugging a nested procedure.
My exit command is:
$ EXIT (F$INTEGER(stat).AND.%XFFFFFFF).OR.%X10000000+(F$VERIFY(verf).AND.0)
where stat is the variable I use to return status. The %XFFFFFFF mask is to clear the control bits (DCL can do some very odd things if they're set). %X10000000 is to set the STS$V_INHIB_MSG bit to stop DCL from displaying the message and (F$VERIFY(verf).AND.0) is to restore verification to its previous state. This time I don't have the leading quote because I don't want it to change until after the verification step.
These procedures are therefore completely silent if the verification logical name is undefined or false. If it's defined as TRUE, all lines, including the first and last are verified. The procedures also work correctly for all execution modes.
DCL Trivia... also note that a quoted F$VERIFY will execute even if it's in a comment!
$!'F$VERIFY(0)'
As Jess has stated, the default for batch jobs is verify enabled. I don't think you can change the initial state.
Trivia in your posted code:
>$ WRITE SYS$OUTPUT "## Start of ''F$ENVIROMENT("PROCEDURE")' ##"
>$ sav_ver=F$VERIFY(0)
>$ IF sav_ver THEN WRITE SYS$OUTPUT "Verify is on"
it should say "Verify WAS on" since you disabled it on the line before. sav_ver tells you the previous state.
This is the code I use as first line of command procedures:
$ verf='F$VERIFY(F$TRNLNM(F$PARSE(F$ENVIRONMENT("PROCEDURE"),,,"NAME")+"_VERIFY"))'
By default it will silently turn verification off. The leading quote on F$VERIFY means the lexical function is executed BEFORE the line is verified. In contrast, as your listing shows, if verification is on, the line (without quotes around F$VERIFY):
$ sav_ver=F$VERIFY(0)
will cause the F$VERIFY to execute AFTER the line is verified, thus the line will be displayed.
My code also allows verification to be enabled for selected procedures by defining a logical name
My exit command is:
$ EXIT (F$INTEGER(stat).AND.%XFFFFFFF).OR.%X10000000+(F$VERIFY(verf).AND.0)
where stat is the variable I use to return status. The %XFFFFFFF mask is to clear the control bits (DCL can do some very odd things if they're set). %X10000000 is to set the STS$V_INHIB_MSG bit to stop DCL from displaying the message and (F$VERIFY(verf).AND.0) is to restore verification to its previous state. This time I don't have the leading quote because I don't want it to change until after the verification step.
These procedures are therefore completely silent if the verification logical name is undefined or false. If it's defined as TRUE, all lines, including the first and last are verified. The procedures also work correctly for all execution modes.
DCL Trivia... also note that a quoted F$VERIFY will execute even if it's in a comment!
$!'F$VERIFY(0)'
A crucible of informative mistakes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-25-2011 10:59 PM
тАО05-25-2011 10:59 PM
Re: Why VERIFY is ON ?
Hi Jess and John
Thanks very much for your fast response.
Your input regarding DCL Dictionary and tips was well known to us. But we did not recognize that we had a very old SYLOGIN Procedure on this machine. We have to analyze how this very old SYLOGIN procedure comes to this machine during the last few days.
Verify was switched on for detached processes within this old SYLOGIN procedure. The problem was, that the log-files of detached processes became suddenly much larger than expected. If you then have 300 or more such detached processes, the space on the log-file disk becomes curt.
You gave me the input, that we were looking on wrong place to solve the problem
Thanks very much
Regards
Geni
Thanks very much for your fast response.
Your input regarding DCL Dictionary and tips was well known to us. But we did not recognize that we had a very old SYLOGIN Procedure on this machine. We have to analyze how this very old SYLOGIN procedure comes to this machine during the last few days.
Verify was switched on for detached processes within this old SYLOGIN procedure. The problem was, that the log-files of detached processes became suddenly much larger than expected. If you then have 300 or more such detached processes, the space on the log-file disk becomes curt.
You gave me the input, that we were looking on wrong place to solve the problem
Thanks very much
Regards
Geni
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP