The simple answer is "nowhere". Unlike MVS 3.8, ISPF is not regarded as Public Domain software by IBM. It is a "for charge" item, and is very expensive. Several inquiries to IBM about licensing an early version of ISPF that would run on MVS 3.8 received replies that the cost to license ISPF would be several 10s of thousands of US$, per installation. Rob Prin has made available his RPF (Rob's Programming Facility) to the Hercules' community, and it provides many of the functions of ISPF. You can obtain RPF from his site - http://www.prince-webdesign.nl/index.php/software/57-rob-s-programming-facility-en.
Greg Price's REVIEW and RFE (Review Front End) also provide most of the capabilities of ISPF: https://www.prycroft6.com.au/vs2sw/index.html#review
If you have followed my instructions/tutorial to build an MVS 3.8j system, you will have installed both of these at the end of the process.
The same answer applies to SDSF as ISPF, above. Although SDSF was a "field developed" program, it is now a "for charge" item that IBM is as yet unwilling to compromise on. Queue, a predecessor of SDSF will provide some of the functionality, and is available from various web sites. Greg Price has recently (11/2002) made available an updated version which adds some new features and is assured of working with MVS 3.8 and makes it available from his web site at https://www.prycroft6.com.au/vs2sw/.
If you have followed my instructions/tutorial to build an MVS 3.8j system, you will have installed QUEUE at the end of the process.
I'm not sure anyone has figured out why it fails or how to correct that client. If you have access (legally and physically) to Windows NT 4.0, the telnet client from that system may be copied onto Windows/2000 and will work just fine.
Hyperterminal, which is included with Windows/2000, will also work, but may expose your system to security problems. If you choose to use Hyperterminal, you should visit Microsoft's web site to see what your risk is, and perhaps download the patch to fix Hyperterminal.
I had been looking for another ("free") alternative since I became aware of this problem. Just recently (February, 2002) I became aware of Tera Term, a free telnet client. You may download a copy from my site - ttermp23.zip [MD5: CDE2C5A58662002C5CA79B7BC5C198B7].
When you start the program, you will see the New connection screen:
For my Hercules' configuration, it is necessary to change Host to localhost and the port# to 3270, as shown. These settings will probably work for most other Hercules' users also, unless you have changed the port in the Hercules' configuration to something other than 3270.
You also need to select the Settings from the client window menu:
The default for both Receive and Transmit are CR, but you will need to change Transmit to CR+LF. Also, Local echo needs to be checked.
[July 2020] This question/answer is probably so out-of-date that I should just remove it, but I thought some people might actually like to have Tera Term available to use, so I am leaving this question here.
Questions are periodically posted to the Hercules' groups regarding the relationships between the various versions of IBM's mainframe operating systems. A couple of files were available in the main Hercules' group files area that can help explain the historical development of these operating systems. Since Yahoo groups demise these files are no longer available from those links. Here are a couple of historical timeline type articles of relevance to IBM's mainframe offerings over the decades:
A simple question with multiple answers, depending upon the content of the files to be imported and their origin.
File content is text (COBOL, Assembler, PL/1, etc. source or just plain text data) residing in a file on the PC - you may wrap the JCL for IEBGENER around the data and submit it to the Hercules' reader. An example:
//IEBGENER JOB 'LOAD TEXT DATA TO MVS', CLASS=A,MSGCLASS=A //IEBGENER EXEC PGM=IEBGENER,REGION=128K //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=A //SYSUT1 DD * --- your ASCII data from the PC file goes here --- //SYSUT2 DD DSN=SYS2.TEXT.DATA.FROM.PC,DISP=(NEW,CATLG), // UNIT=3350,VOL=SER=PUB001,SPACE=(TRK,(60,60),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120) //
An alternative is to use my MAKETAPE program (mawstape.htm) to load the contents of one or more ASCII files onto AWS tape images, which may then be read directly under MVS 3.8. It has had some updates made by Paul Edwards and Jeremy Bingham that improve its functionality and allow it to be used on MACs.
[July 2020] This program is still functional and I use it from time to time on my Linux system and have communicated with others who do. At some point it was included in the Hercules utilities and is, at least with some distributions of Hercules, installed along with the other Hercules executables.
File content is text, but is in EBCDIC, residing in a file on the PC - you may use Jim Morrison's RDRPREP program to wrap JCL around the EBCDIC data and create an EBCDIC jobstream to submit to the Hercules' reader. An example:
//IEBGENER JOB 'LOAD TEXT DATA TO MVS',
CLASS=A,MSGCLASS=A
//IEBGENER EXEC PGM=IEBGENER,REGION=128K
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD *
::E yourfile.txt <-- replace "yourfile.txt" with the name of the file to be loaded
//SYSUT2 DD DSN=SYS2.TEXT.DATA.FROM.PC,DISP=(NEW,CATLG),
// UNIT=3350,VOL=SER=PUB001,SPACE=(TRK,(60,60),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)
//
RDRPREP reads the file containing these statements, converts the ASCII statements, the JCL, to EBCDIC, and inserts the contents of the EBCDIC file, without translation, into the output file. RDRPREP (formerly in the no long available files area of the Hercules-390 Yahoo group) is now available from my site at: ../downloads/archives/rdrprep-0002.zip
File is in XMIT format (created using the TRANSMIT command under TSO/E) and the content of the file(s) in the XMIT file is ASCII text. Use XMIT Manager (https://www.cbttape.org/njw/index.html) to extract the file(s) you wish to upload onto your computer, then use the first method described above.
If the contents of the XMIT file are object or load modules, use dasdload, which is included in the Hercules' installation materials to create a DASD image containing the file:
- Create a control file for dasdload. The control file is an ASCII file containing a volume statement, which describes the characteristics of the DASD volume, followed by one or more dataset statments, which describe the individual MVS datasets to be created on the DASD volume.
The format of the volume statement is: volumeid devicetype cylinders; where volumeid is the volume serial identification MVS will use to identify the volume, devicetype is the emulated device type (3330, 3350, etc.), and cylinders is the number of cylinders to be created for the emulated volume (cylinders may be coded as an asterisk (*) to specify the default for the devicetype specified). An example control file:
In this example, a 3380 DASD volume is created with a volume serial id of 'cbt135'. A Volume Table of Contents is created at the beginning of the volume and occupies 15 tracks (sysvtoc is a dummy dataset name, required by dasdload). A single MVS dataset - cbt135.lib - is created from the contents of the cbt135.xmi file.
- Execute dasdload to create the DASD image. The format of the dasdload command is: dasdload controlfile outputfile msglevel; where controlfile is the name of the file containing the control file described above, outputfile is the name of the file to contain the created DASD image, and msglevel is a numeric value designating the amount of informative messages you want dasdload to show as it creates the DASD volume (2 is a good choice in most cases). For example:
dasdload cbt135.ctl cbt135.3380 2Note: the dasdload command must be issued from a Windows or Linux command prompt, not from within Hercules!
There are some cases in which dasdload will not correctly process XMIT files, notably when the dataset contained in the XMIT file is a sequential dataset (DSORG=PS) rather than partitioned (DSORG=PO), and when the XMIT file contains a comment record. According to posts on the Hercules' lists, some have used RDRPREP (described above for EBCDIC text files) to load such datasets to MVS.
If dasdload issues the message - Error: COPYR1 record length is invalid - see FAQ #28.
[July 2020] Jim Morrison's RECV370 and XMIT370 can unpack and create XMIT files, respectively on MVS. So to process an XMIT file that is on your host Operating System and transfer it to MVS running under Hercules, you can use an emulated card reader to simultaneously upload the XMIT from the host Operating System to MVS and unpack it with RECV370 running on MVS, or use IND$FILE (below) to transfer the XMIT from the host Operating System to MVS and then use RECV370 to unpack the XMIT on the MVS side of the transfer. I have written a short tutorial on these two methods at Transmit and Receive.
Mike Rayborn has written an IND$FILE for use with MVS 3.8j that can be used to transfer small to medium sized files between the host PC and a TSO User Session. Version 1.0.6 with external code page support (cut mode only) is available for download from: ind$file [MD5: FB8299C89D533D32CAE983B7DBE13878].
[July 2020] I have written a short tutorial on using IND$FILE that is available at IND$FILE: Transferring Files Between MVS and the Host OS.
The most likely cause for this is one or more comment records inserted into the XMIT file during processing for inclusion on the CBT tape. I have written a PERL script - xmitfix.rar - that will copy the XMIT file omitting these records. It will also format and display the information in the control records, much like David Alcock's REXX program, XMITINFO, from which I derived much of the format of the XMIT records.
Execute the script to copy the file causing the error:
xmitfix.pl input.XMI output.XMI
and you can then use dasdload to process the output.XMI.
Note: In order to use my script, you will need Chris Leach' Convert module installed to handle the EBCDIC to ASCII conversions. It should also be obvious that you will need PERL installed on your computer; if you do not already have PERL installed, you can download and install PERL from: https://activestate.com.
This is a generically stated question that I am using to address two issues. First, there have been several discussions on the Hercules' lists regarding tn3270 clients that fail to work, or fail to work properly, with MVS 3.8 under Hercules, especially attached to a console device address. Secondly, I recently decided that I was tired of leaning in to my monitor to read the contents of my tn3270 client running in a window, a necessity since my current client did not have the option of running in full-screen mode.
When I started exploring options, I began with the advantage that I had already benefited from the prior discussions "on list", so I knew that Tom Brennan's vista client had been recommended several times. In fact, I had downloaded an evaluation copy of it at least as far back as 2001. So I grabbed a current copy and installed it (it took less than a minute to install to the point of executing and connecting to Hercules). It seemed immediately to be a viable solution. I decided right away that all the features that I would need would be fairly intuitive and easy to use and, most importantly, it could be maximized to utilize the full screen for its display. I then spent about 30 minutes doing a search of the other available tn3270 clients for a price comparison. I found that the closest competitor, based on price, was 30% more expensive than the $30 registration fee for Tom Brennan's vista. An added incentive is that Tom Brennan is an MVS Systems Programmer, so he knows what is needed by MVS users in a tn3720 client.
So, if you need a great tn3270 client to use with Hercules and MVS 3.8 on the Windows/?? platform, I urge you to try Tom Brennan's vista. You can download a fully functional copy that you may use for a 30 day evaluation period at https://www.tombrennansoftware.com.
[July 2020] I still highly recommend Tom Brennan's client, as he is a good friend to the Hercules community and has made some enhancements to Vista specifically to benefit Hercules users. But there is also an X3270 client that runs either on Windows natively (ws3270) or in a Windows console window (wc3270). Both are available from http://x3270.bgp.nu/.
The MVS operating system expects specific hardware devices to be attached and accessible at a specific hardware addresses. The address of a particular device is sometimes referred to as the channel and unit address, which is often abbreviated as CUU (or cuu). [The MVS versions we are legally using here date from a time when the addresses were three digits, one for the channel and two for the unit. Today's MVS, excuse me OS/390 or zOS, utilize addresses of four digits, two for the channel and two for the unit - CCUU. The Hercules' configuration file (and console commands) allow four digits, but you may omit the leading zero to effectively have a three digit address. MVS 3.7 and 3.8 (not to mention OS/360 MVT) will only understand 3 digit addresses.] This device type/address relationship is established during the System Generation process, when the MVS nucleus is built. The expected devices can be modified somewhat by a subsequent (mini-) System Generation process referred to as an IOgen.
When the Hercules program is executed, it reads a configuration file. Besides some basic operating characteristics, the configuration file contains a collection of device definitions. Each of these definitions is used to associate an emulated hardware address (that is perceived by MVS as an actual, physical device address) with either a disk file maintained by the host operating system (Linux, Windows/??, etc) or with a communication address that will be used to pass data to/from a client, such as telnet or tn3270. Under Linux, it is also possible to associate a physical SCSI tape device with an emulated address that corresponds to an MVS tape device.
When MVS, running under Hercules, initiates an I/O operation to an attached device, it does not know anything about Hercules or the underlying host operating system. Hercules uses the information in its configuration file to perform the I/O operation (to a host OS disk or tape file, or in communication with a host OS client program) and returns the data to the MVS image. If an incorrect association is made in the Hercules' configuration file, the data passed to MVS will be incorrect. This will usually result in MVS entering a disabled wait state, with the sense information indicating a command reject (CMDREJ). A frequently asked question on the lists is a result of connecting a telnet session to a console address that is defined as a 3277 device (or the converse of attaching a tn3270 session to a console address defined as a 3215 device). Another situation that will generate a disable wait state is attempting to IPL from a DASD image that does not contain the MVS IPL information and system datasets.
During IPL, all devices defined as DASD (Direct Access Storage Devices, or disk drives) are probed by MVS to determine if a volume is mounted at the address and, if so, what the Volume Serial Number of the mounted volume is. Certain DASD volumes are required to be online for the IPL to proceed. Certain additional devices are required to be present and operational for the IPL to proceed. The most important is at least one functional console device which MVS requires to communicate with the operator as the IPL proceeds. The lack of a console during IPL manifests itself as a disabled wait state 21, and is one of the more frequently asked questions on the lists.
You could possibly get away with specifying some address/emulated device pairs incorrectly if the devices are not required and/or not polled by MVS during IPL. But you will probably receive an ABEND (abnormal program end) and an entry in the EREP (device error recording) file the first time you attempt to access the device. At the very least.
MVS is not a "plug and play" operating system. You must know the generated devices expected by MVS at each generated address. The Hercules' configuration file must correctly match up these addresses with the correct corresponding host OS file or client. It is possible to omit unused device addresses from the Hercules' configuration file. In fact, in actual operation, most MVS images will have hundreds of devices defined during System Generation that are not actually present at all times that MVS is running. It is a means of allowing for expansion of the hardware and for the use of transient hardware, devices that might be brought "online" for a short time for a specific purpose.
If you are building your own MVS 3.8j system, you will know exactly what device is expected at each address, because you specified that in the Stage 1 deck. If you are using Volker's Turnkey CD-ROM, he documents the devices he has generated in several places. Check his documentation or look at the Stage 1 deck he used to build the system. If you are using the MVS 3.7 starter system, there is a chart of the devices in that system on pages 25/26 of the OS/VS System Generation Reference: GC26-3792-p25-26.pdf. If you have built (or are building) an MVS 3.8j system using my instructions/tutorial, you will have the opportunity to modify the devices and their addresses, and you will certainly know what devices are included and at what addresses; I even provide a pdf document listing all of the devices defined in the Stage 1 System Generation deck.
Whenever an MVS program terminates execution, a numeric value is returned, regardless of whether the program is a step in a batch job or started task, a program executed in a TSO session, or a TSO session itself. In fact, even subprograms - component parts of an executable program that may be considered completely contained code units - pass a return code back to the main code unit. The value returned may be referred to as a return code, condition code, completion code, or exit code, depending upon who you are talking to, and in what context. The purpose of the return code is to communicate the success or failure of the task being performed by the program. If there were no errors encountered during the program's execution, the value returned is 0000 (the return codes are frequently displayed as four digit numbers, hence 0000 rather than 0). The value can be any value from 0000 to 4095.
The return code for each step is always printed in the JOBLOG portion of the SYSOUT for each batch job, started task, and TSO User session. The return code (CONDition CODE) value is the last piece of information included on the IEF142I message for each step:
The JOBLOG is written to the output class specified in the MSGCLASS parameter on the JOB card (or the default MSGCLASS specified in the JES2 parameters if MSGCLASS is omitted from the JOB card). The class to which the MSGCLASS SYSOUT is written must not be HELD (must be released for processing by a JES2 output writer) and there must be an output writer started for the class. After JES2 has processed the output it is available for viewing in the host OS file assigned to one of the emulated printer devices in Hercules.
If you are running under an MVS system with a version of IEFACTRT installed that displays the step completion codes on the MVS console, at the completion of each job step, the value of the code will be shown on the MVS operator's console.
Large batch jobs, and some started tasks, utilize JCL condition code evaluation to determine if subsequent steps should execute based upon the value of one or more previous step's completion code. Therefore it is necessary to check the completion codes of all steps in a job to ensure that the job has achieved the required function. During System Generation, for example, if an early step of a job returns an unacceptable condition code value, component modules of the target operating system may not be built. Subsequent jobs may then complete, to all appearances successfully, but with necessary components of the target operating system missing or non-functional.
The values returned from user written programs are somewhat arbitrary. There are usually development standards that place some dictates upon the codes that are assigned. However, what codes should be expected, and the action to be taken for each, are placed in the program's documentation to guide operators and users in interpreting the code values returned when the programs execute. The manner in which the step return code is set varies by programming language - in assembler the code is set by loading the value into Register 15 prior to returning control to the operating system; in COBOL the value is MOVEd to the RETURN-CODE Special Register; in PL/I the value is set by a call to the PLIRETC function; in FORTRAN the value is included as an integer following the STOP statement.
The codes that may be returned for IBM's programs - utilities, compilers, TSO commands - can be found by perusing the appropriate manual for the program being executed. There is a general standard for IBM programs (utilities and compilers):
0000 - program completed successfully
0004 - minor errors encountered, possibly expected and acceptable, output of program may be usable
0008 - major errors encountered, output of program probably not usable
0012 - very major errors encountered, output of program not produced
0016 - catastrophic errors encounter, program execution terminated as a result
Some return codes are encountered so frequently, they become easily recognizable:
00c7 - data exception (usually a COBOL application program)
010a - insufficient virtual storage
0222 - operator issued a cancel command for job
0322 - job cancelled by JES2 because TIME limit exceeded
0722 - job cancelled by JES2 because SYSOUT output limit exceeded
0806 - load module not found in specified library
080a - insufficient virtual storage
0813 - tape dataset open failed because tape label did not match DD
0822 - insufficient virtual storage to obtain region
0b37 - attempt to extend dataset beyond 16 extents
0d37 - dataset filled all space allocated
0e37 - PDS dataset filled all allocated directory space
A summary of frequently encountered System and User ABEND codes, obtained from the CBT tape, can be viewed (or downloaded in PDF format) from my site at: Abend Codes.
You can access IBM's manuals online at https://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library where you can read and search manuals or download copies of them to your hard drive in Bookmanager or PDF format. As a bare minimum, you should download copies of:
MVS System Codes
MVS System Messages, Volume 1 (ABA-ASA)
MVS System Messages, Volume 2 (ASB-EWX)
MVS System Messages, Volume 3 (GDE-IEB)
MVS System Messages, Volume 4 (IEC-IFD)
MVS System Messages, Volume 5 (IGD-IZP)
JES2 Messages
Yes, these manuals are for much later releases than the 3.8j version of MVS we are using, but most of the codes are still valid.
The VTOC Conversion function has been entered for volume with the serial number indicated in the message by vvvvvv mounted at the device address indicated in the message by nnn. There can be a couple of reasons for this happening; which one it is will be indicated by the value of ccc in the message text.
If ccc is DOS, this is probably the first time that MVS has attempted to write to this DASD volume image, and the volume was created with one of the Hercules' utilities: DASDINIT or DASDLOAD. Volumes created with these utilities appear to MVS as though they were formatted under DOS/VSE and some of the control structures are not as complete as MVS requires them. The convert routine corrects these structures to meet MVS' more rigid requirements.
If ccc is DIRF, the last time an update was in progress for the volume, there was an interruption and the operation did not complete, leaving some of the VTOC structures damaged. The convert routine corrects the problems with the structure that was damaged or incomplete.
After the convert routine has completed repairs to the VTOC structures, the operation that caused the convert routine to be run is completed.
Beginning with the 3.00 release, Hercules utilizes dynamically loaded modules for some of its device support. When running under Windows/?? and CYGWIN, the main Hercules' executable assumes that the installation of the binaries/executables of both CYGWIN and Hercules were placed within the CYGWIN directory hierarchy. If that is not the case, when Hercules attempts (and fails) to load one of the dependent modules, this message will be issued. Hercules will not initialize or operate properly without access to these modules.
From the Hercules' documentation included with release 3.00 and above:
MODPATH path- specifies the path where dynamic modules are loaded from. When a modpath statement is specified, the path on the modpath statement is searched before the default path is searched. When a relative path is specified [it] is interpreted as a relative path within the default search path, if an absolute path is specified is interpreted as such.
Note that if you specify a relative path, the path specified is interpreted to be relative within the default search path. In order to correctly locate the dynamically loadable modules in the structure I use, I specify the MODPATH parameter as:
MODPATH e:/hercules/lib/
If the drive specification [e:] is omitted, Hercules views this as a relative path specification and the dynamically loadable modules will not be found. Therefore, if your installation is such that you require a MODPATH statement in your configuration file, you probably will need to include a drive letter in order for the path to function correctly and allow Hercules to load the dynamic modules.
This question has been discussed several times on the various lists. Since I had never been able to successfully recover from this situation when it had happened to me in the past, I decided to take some time to learn exactly what steps would work. It should not matter, but I am running Hercules version 3.01.
To create the failure, from a running MVS 3.8 I terminated the 3270 clients attached to both the main and alternate console addresses (010 and 011, respectively). Hercules issued a "Connection reset by peer" message for each.
To recover, I first started two new instances of my 3270 client (I am using Tom Brennan's Vista version 1.24). Their screens each immediately displayed the Hercules version message with the appropriate device address (0011 and 0010, respectively).
Next I switched the Hercules control panel to the text or log output version and issued the external interrupt command:
ext
Then I pressed the ENTER key on the 3270 client attached to address 010. Console log output appeared on the screen, but it required a manual reset (on the Vista keypad) and a second ENTER before I could type MVS commands into the command input area.
In order to restore the alternate console, I had to issue a Vary command from the primary console:
V 011,CONSOLE
It is also necessary to re-establish roll mode deletion on the secondary console after this recovery.
There may be several reasons the Hercules' emulated CPU could enter a disabled wait state during IPL, but most of the times the error condition will be found to be some component required for IPL is missing or incompatible. This is one of the most frequently posted questions on the discussion groups and I probably should have added an entry here earlier. Nevertheless, better late than none at all.
Since there may be several reasons to receive a disabled wait state, I will add to this answer as different causes are encountered. For each reason, I will reproduce the message(s) issued, then explain the cause and resolution.
HHCCP077I 0009:Sense=INTREQ HHCCP011I CPU0000: Disabled wait state PSW=000200FF 80000005
If you want to look up the wait state code, the code value is the last three digits of the PSW, which is the last information shown in the last message Hercules issues (the last two messages are reproduced above). The list of codes is found in MVS System Codes manual (GC28-1780) and even the current version of the manual will work. The explanation given in the manual for code 005 is:
An I/O interruption during initial program load (IPL) indicated a unit check.
but nothing else in the entry for this code will be particularly helpful. Looking back at the next to last message, you will find the clue you need. The four digit number - 0009 - preceding the colon indicates the physical device address for the device in the Hercules' configuration file which is causing the problem. Following the colon is the interpreted reason for the sense code returned by the device: INTREQ or Intervention Required.
The device at address 0009 in Volker Bandke's Turnkey system (and perhaps some other configurations also) is a 3215 console. Before you issue the IPL command in the Hercules' hardware console, you must start a telnet client and open a connection to the port you assigned to the console in the Hercules' configuration file. Note that you must use a telnet client and not a tn3270 client. The 3215 device is a line mode device and not a full-screen display device.
When using PCOMM under Windows+CYGWIN there appears to be a necessity to adjust the Hercules task priority to compensate for a dispatching priority issue.
The Hercules command HERCPRIO may be used to alter the processing priority of Hercules:
HERCPRIO nn
specifies the process priority for Hercules. The default is 0.
Setting the value of HERCPRIO to 8 ("below normal") seems to resolve the problem.
Modify the session profile (contained in the .WS file for your session, normally in the 'private' subfolder) so that it includes the following:
[LT]
IgnoreWCCStartPrint=Y
UndefinedCode=Y
UndefinedDBCSChar=Y
No, the Hercules installation files only contain the executable and/or source (depending upon the package you downloaded) for the Hercules emulator. You must obtain the files to install an operating system that will execute on the emulated hardware separately. Some pointers for sources for these can be found at Installing OS/360 MVT 21.8f. You can follow my instructions/tutorial to build an MVS 3.8j system from the IBM distribution tapes, or acquire a copy of Volker Bandke's Turnkey MVS system.
The entire text of the message will contain additional information, followed by a prompt for a reply; for example:
IEC507D E 150,MVSRES,COBCL,LKED,SYS1.LINKLIBT 03 IEC507D REPLY 'U'-USE OR 'M'-UNLOAD
The message is issued when a job attempts to modify (or delete) a dataset for which an expiration date was specified at the time it was created and the current system date is earlier than the date the dataset is to expire. The additional information provided in the message text is the unit address and volume serial number where the dataset resides, the jobname and stepname which is attempting to modify the dataset, and the name of the dataset. The two possible responses are: 'U', which permits the job to modify (or delete) the dataset or 'M', which causes the step to terminate immediately with an S713 completion code.
Production load libraries are frequently protected in this manner to prevent unauthorized modification of production programs, or at least ensure that the system operator is aware of the modification and an audit trail records the modification (ie. the system log). If you are encountering this message frequently on your Hercules/MVS (or MVT) system and wish to remove the protection, use the ZAPDSCB program to remove the expiration date from the dataset entirely.
ZZSA is a great recovery tool written by Jan Jaeger. It may be IPLed directly under Hercules without the necessity of an Operating System, so it may be used to repair damage to dataset contents that precludes successful IPL of your normal Operating System. The card image version of ZZSA is distributed along with Hercules -- search for the file named zzsacard.bin. In my installation it is found in the util subdirectory under the directory where Hercules was unpacked from the installation archive. Most of the time I am running MVS 3.8j, so I have copied this file -- zzsacard.bin -- into the same directory where my Hercules' configuration file for MVS resides. In order to IPL ZZSA, I:
- Start Hercules with my normal MVS configuration, but do not IPL from the MVS System Residence DASD.
- Start a single 3270 emulator client and connect to Hercules.
- Modify the ARCHMODE to ESA/390 (Hercules' command: archmode esa/390). ZZSA requires ESA/390 mode.
- Modify the card reader to point to the zzsacard.bin file (Hercules' command: devinit c zzsacard.bin ebcdic eof).
- IPL the card reader (Hercules' command: ipl c).
- Press the CLEAR key on the 3270 emulator client window and the ZZSA main screen is displayed..
- Enter the ZZSA password -- ZZSECRET -- (note all caps) on the ZZSA main screen and press ENTER.
At that point I can access all the DASD normally attached to my MVS environment using ZZSA. For detailed instructions on using ZZSA, visit the main download/instruction site for ZZSA: https://www.cbttape.org/~jjaeger/.
I have received feedback on this answer regarding step 6: the user was only able to receive the ZZSA main screen after pressing the ATTN key on the 3270 emulator. I have rechecked the documentation, which states
Generate an attention interrupt on the local non-SNA 3270 device that will used (eg. hit enter, attention, PA or PF-key).
So the correct solution may depend upon several factors, such as what 3270 emulator you are using. If CLEAR does not work for you, try other attention generating keys until the main screen appears.
The complete description of the problem is:
I created a dasd volume using xmit files and so far only 1 program has a problem. It is compiled and linked on z/OS 1.8 and works fine there. When I execute it on MVS 38/Hercules I see a 30A abend on the console. Looking in the dump I also see a 106-0B (it's a unknown problem). The problem occurs in batch and TSO. The load module is more that 1 MB in length. I added the value of 32(50) to the registry for maximum storage but it didn't help.
The person who submitted this question actually provided the answer, which he suggested I place here for others who might encounter the problem:
You might want to update one of your WebPages to say you will get 30A- 1 and 106-0B abends running some load modules produced by the z/OS binder. If you relink the module that fails using IEWL, so far it works.
Leon Bouwer encountered this problem:
I ran Hercules on my old laptop, and every start after a reboot, was slow - the disks takes forever to initialise. But after the first time it is pretty much instantaneous. Then I bought a new laptop and now every start is slow. Each disk in Hercules takes probably 5 to 10 minutes to start.
And also discovered the answer and solution:
I found the problem with the slow restart of Hercules which I described below; its Windows Indexing; if you have the bottom box ticked, you have this problem. Without it, as I have it now, the Herc start is just about instantaneous.
This question was asked in the main Hercules forum. The poster had downloaded a zip archive from Volker's system, but the file was corrupted. I decided to investigate to see if there were any other locations where the original Turnkey/MVS system was still hosted and found only one, at https://www.ibiblio.org/jmaynard/turnkey-mvs-3.zip. The archive at this site is viable, but since this location is maintained by Jay Maynard, who I understand has not been easily contacted recently, I decided to provide a snapshot of that archive here on my site. It is available at: turnkey-mvs-3.zip [512 MB MD5: 78c4a1bc92401891208b3bca4622664a]. The archive contains an ISO image, which may be burned onto a CD-ROM.
[July 2020] The Turnkey system is currently maintained by Juergen Winkelmann. The website for it is https://wotho.ethz.ch/tk4-/.
In November 2019 I was asked this question. I was aware of the SDL Hyperion version of Hercules through the Hercules' discussion forums, but I had never had a reason to investigate this version of Hercules, primarily because my perception of it was that it had many features that were 'bleeding edge' (which is Fish' own description) and were mostly needed if you are attempting to run a very recent version of z/OS. I downloaded the source and built it on my Linux system so I can report that it does appear to have no difficulties when running MVS 3.8J. If you are inclined to try this version, it is available from http://www.softdevlabs.com/hyperion.html.
This was a problem that I began to encounter a while back, but I simply did not stop to research the problem and find a solution because I have several ways to submit jobs to the MVS system running under Hercules; therefore it wasn't a priority. But I took the time today to look into it and found that others had encountered the problem and a solution had been posted about 13 months ago. The posts I found, along with the solution, appear on the Software Development Labs github discussion for issues with the Hyperion version of Hercules developed and maintained by Fish (David Trout).
I am running Hercules version 3.13 from an archive created September 25, 2017, available from http://www.hercules-390.eu/. The description of the problem submitted by agadsby on Mar 22, 2019:
The use of sockdev as a device endpoint appears to not work on LINUX versions without syn_cookies being enabled. On system such as the Raspberry Pi messages relating to sync cookies being used are also issued in the operating system log.
The problem presents as external processes such as Hercrdr and Hercprt cannot connect to any sockdev(s) defined in the conf/tk4-.cnf . After tracing this through the problem appeared to be that the LINUX kernel did not pass the socket connection to Hercules: a netstat -a showed the connection to the socket e.g. 3505, as hanging in SYN sent and dmesg showed messages like: "kernel: possible SYN flooding on port 3505."
There was a workaround submitted in response to this problem, but there was also a suggestion of a correction to the Hercules' source code for sockdev.c. I compared the source code of sockdev.c from SDL Hyperion with that of Hercules version 3.13 and found that the suggested correction was what was already in place in the SDL Hyperion version. I modified the Hercules 3.13 source for sockdev.c on my computer and then rebuilt Hercules from the source. The change to sockdev.c source is:
From: if (0 || bind (sd, (struct sockaddr*) &addr, sizeof(addr)) == -1 || listen (sd, 0) == -1 ) { logmsg (_("HHCSD010E Failed to bind or listen on socket %s: %s\n"), path, strerror(HSO_errno)); return -1; }
To: if (0 || bind (sd, (struct sockaddr*) &addr, sizeof(addr)) < 0 || listen (sd, 1) < 0 ) { logmsg (_("HHCSD010E Failed to bind or listen on socket %s: %s\n"), path, strerror(HSO_errno)); return -1; }
This may have improved the problem, but I am still occasionally experiencing failures with submission through a card reader defined as a socket device.
It has been known for a long time that compressing SYS1.LINKLIB on a running MVS system can be dangerous. Although it had never before happened to me, I have been around some discussions of it. Not long ago I specified COMPRESS(ALL) in an SMP job and received an abend while it was processing SYS1.LINKLIB, which happens to be included when SMP does a COMPRESS(ALL). So, why does it happen? First, I will pass along the explanation and then I will pass along a remedy that should solve the problem.
IEBCOPY, which is one of the oldest IBM utilities around, was written when memory was in short supply at most installations, so it is link edited with overlays, which means not all of the program is loaded into memory at the beginning of execution. If IEBCOPY is working along compressing the library it was loaded from - SYS1.LINKLIB - and the load module for IEBCOPY has already been moved, then the part of IEBCOPY in memory attempts to load an overlay from disk, the pointers it uses are no longer valid, because the load module has been relocated on disk. So, a simple fix for this is to re-link edit IEBCOPY to eliminate the overlay structure. Overlays are not necessary as we have plenty of memory available to MVS under Hercules to load the entire program at the beginning of execution.
I went back to the Stage2 deck from one of my last MVS 3.8j builds and used the jobstep that originally link-edited IEBCOPY as the basis for a job to do the re-link. The first step of the job renames the original load module to IEBCOPY@, so it will be preserved, then re-links the load module without the overlays back into SYS1.LINKLIB(IEBCOPY). You can grab a copy of the jobstream from ../downloads/iebcopyr.jcl. When I went looking for discussions about this, I found that there was one as recent as August, 2017 on the H390-MVS discussion group on the now defunct Yahoo groups; two of the posts were from Greg Price and Gerhard Postpischill. There was also a similar jobstream uploaded to the files section of that group that I don't have an attribution for, since the only extant copy of the Yahoo material has been grabbed and reloaded to the groups.io group and the original poster attributions were lost on those files. If you use the Turnkey MVS maintained by Juergen Winkelmann, this sort of fix has been implemented there. The next time I revise my MVS 3.8j build instructions, I will be including this job as a part of that process.
I hope that you have found my instructions useful. If you have questions that I can answer to help expand upon my explanations and examples shown here, please don't hesitate to send them to me:
This page was last updated on February 16, 2022 .