开云体育

For some reason argv[1] does not get converted properly. If the folder name is hard coded the program works fine. If its value is passed through argv[1] the program will display the value correctly, but no directory list gets retrieved. This issue happens on MVS, but if the code is compiled on Linux it works as expected. Here is the code. The code below will only display the contents of / but not its branches. #define _POSIX_SOURCE #include <dirent.h> #include <errno.h> #include <sys/stat.h> #include <sys/types.h> #undef _POSIX_SOURCE #include<stdlib.h> #include<stdio.h> #include <unistd.h> #include <string.h> #include <sys/wait.h> #include <grp.h> #include <pwd.h> #include <time.h> #include <fcntl.h> char path[1024]; void listdir(const char *name, int indent,char *other) { DIR *dir; struct dirent *entry; puts(name); if (!(dir = opendir(name))) return; while ((entry = readdir(dir)) != NULL) { printf("%*s- %s\n", indent, "", entry->d_name); if (strcmp(entry->d_name, other) == 0) listdir(entry->d_name, 2,other); } closedir(dir); } int main(int argc, char **argv) { char* foldername = "."; puts(argv[1]); listdir(foldername, 0,argv[1]); return 0; }

Howdy, dear MVS-lovers, Today I would like to inform you that we have finally released BREXX/370 V2R2M0. At this point, we would like to thank Juergen, Greg, Jason, Wally, Daniel and Moshe for their support. The installation archive can be downloaded using the following link: https://github.com/mgrossmann/brexx370/releases/ Of course, we would be happy about any feedback and ideas for the next version(s). Mike

Done

The JCL below can reallocate your Sys1.LOGREC to a larger size so you don't get the pesky "log is full" message every other day. It worked for me with minor changes of course. //KATHYLR JOB (9999),'CREATE NEW LOGREC DS',CLASS=A,MSGCLASS=X, // MSGLEVEL=(1,1),NOTIFY=KATHY //*------------------------------------------------------------------ //* RENAME THE CURRENT LOGREC DATASET //* UNCATLG SYS1.LOGREC SO THE NEW LOGREC CAN BE ALLOCATED ON //* ANOTHER VOLUME, IF DESIRED //*------------------------------------------------------------------ //RENAME EXEC PGM=IEHPROGM //M43RES DD VOL=SER=M43RES,UNIT=3390,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD * RENAME DSNAME=SYS1.LOGREC,VOL=3390=M43RES, X NEWNAME=SYS1.LOGREC.OLD UNCATLG DSNAME=SYS1.LOGREC /* //*------------------------------------------------------------------ //* CREATE THE NEW LOGREC DATASET AND INITIALIZE IT //*------------------------------------------------------------------ //IFCDIP00 EXEC PGM=IFCDIP00,COND=(0,LT) //SERERDS DD DSN=SYS1.LOGREC,DISP=(,CATLG), // VOL=SER=M43RES,UNIT=SYSDA,SPACE=(CYL,3,,CONTIG) /* regards; Rahim

I'm using TK4- on Linux, with x3270 as the terminal emulator. When I press the "Insert" key to go into insert mode, it almost never works (it may have worked 3 times for me in total). In all other cases, the x3270 terminal displays X in the bottom, and then hangs until I press "Reset". Is there a way to fix this? Not being able to insert text can be quite frustrating after a while.

Apologies if this seems somewhat newbie-ish - I've been using various forms of MVS for many years but have never had to wrestle with this. Just as a precaution, changing the version of commndxx (default commnd00) by changing IEASYS00 CMD=xx seems a bit dangerous in some cases. I understand that it is possible to specify the xx via an operator command but have so far been unable to discover exactly how to enter it. If someone could point me to the appropriate manual or just specify the method, I would be grateful. None of the IBM manuals I have read actually give any detail. Many thanks Bill

Here's the output of ./configure. [ted@Scout hercules-3.13]$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... autoconf/config.guess: unable to guess system type This script, last modified 2003-07-02, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from ftp://ftp.gnu.org/pub/gnu/config/ If the version you run (autoconf/config.guess) is already up to date, please send the following data and any information you think might be pertinent to <config-patches@...> in order to provide the needed information to handle your system. config.guess timestamp = 2003-07-02 uname -m = aarch64 uname -r = 4.19.83-1-MANJARO-ARM uname -s = Linux uname -v = #1 SMP PREEMPT Tue Nov 12 15:23:51 UTC 2019 /usr/bin/uname -p = unknown /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = aarch64 UNAME_RELEASE = 4.19.83-1-MANJARO-ARM UNAME_SYSTEM = Linux UNAME_VERSION = #1 SMP PREEMPT Tue Nov 12 15:23:51 UTC 2019 configure: error: cannot guess build type; you must specify one [ted@Scout hercules-3.13]$ Any help is appreciated.

Please help this site if you can afford. It has been a helpful resource for our community by providing access to important software. I just made my own donation. Rahim

I'm sorry for using this forum to post stupid beginner quesitons, but it's somewhat difficult to find online documentation on this stuff. Especially when one isn't even sure about the terminology. My question is, if I have a Partitioned Data Set with a member, let's call it: HERC01.FOO.BAR(XYZ), and I want to make a copy of it to: HERC01.FOO.BAR(ABC), how do I do that? When using RFE to perform this copy, after entering the destination DS, I get an error message saying "Please enter TO dataset". If I try to copy the member to a different PDS, then it works. Thus, the only way I have been able to do this is to first copy from one PDS to another, and then back again. That's quite cumbersome. Regards, Elias

Count me in!

In linux I have a shell script to launch my system, and I thought it might be nice to have a launcher to go with it, so I created a mvs.desktop file with the following content. [Desktop Entry] Version=1.0 Type=Application Name=MVS Exec="/home/path/ra/mvs/xstartmvs.sh" Icon=/home/username/Programs/mvs/idea.png Categories=Development;IDE; Terminal=false StartupNotify=true StartupWMClass=jetbrains-MVS Name[en_GB]=MVS.desktop

The last message I received was posted on Jan 17, so I thought I'd post and see if it's just me. Peter

I had to struggle to find out what was defined as my Db2 subsystem-id on my MVS. Recently I came across the following article and rexx script that may have made my life much easier. Every site has this challenge and we all find different ways around the problem: How can I generate a list of DB2 subsystems defined to my current LPAR and whether they are active or not? It may be that you want to know exactly that but more commonly this is the sort of thing that is needed to support a DB2 tools panel, validating which services are genuinely available. Typically we find that customers resort to hard coded lists in the panel verification e.g. VER(&SSID,NB,LIST,DG91,DGA1,DGB1) In this example we have three DB2s listed (DG91,DGA1 and DGB1) which all happen to be the first members of data sharing groups. What happens if we need to run the second member of DB90 (DG92) on this LPAR? What if we create a new data sharing group? Determining what DB2 services are defined to your LPAR can be done in a number of ways. This blog outlines an approach which can be used on any site with DB2 for z/OS. Some Control Blocks Inevitably, finding this information will require some gentle control block surfing. The good new is that these are all well understood and documented. When we define a subsystem to z/OS we apply the details to the IEFSSNxx PARMLIB member. These entries are used by z/OS during IPL processing to build the subsystem vector table, which is a chain of control blocks, one for each formal MVS subsystem. Each entry in the vector table is a SSCVT control block (SSCT) and as well as names and chaining pointers, also includes a couple of “user” fields. When we define DB2 in IEFSSNxx, the entries look like this: SUBSYS SUBNAME(DBB1) INITRTN(DSN3INI) INITPARM(‘DSN3EPX,-DBB1,S,DBB0’) The INITRTN (DSN3INI) is driven at IPL (or SETSSI ADD) to do any setup initialisation. In the case of DB2 one of the things that it does is build the ERLY control block and hang this off the first of the SSCT user fields. So now we know why the contents of the SDSNLINK are usually referred to as ERLY-code. Part of the DSN3INI population/build actions for the ERLY include saving the configuration options (cf INITPARM) and loading additional modules. This means that the parms can all be found recorded in the ERLY. Note also that ERLY is the stepping off/anchor point for all of DB2’s control blocks that support it’s operation. As an example, the SCOM (which exists in the MSTR address space) is chained from the ERLY once it’s created (at subsystem startup). Figure 1 – Control Block Chaining It’s worth noting that MQ on z/OS is largely based on DB2 for z/OS. As a result it also has an ERLY (same ID and eyecatcher) and SCOM pointer. To differentiate between MQ subsystems and DB2 ones, check that the ERLY interface module name is DSN3EPX (as in INITPARM in the IEFSSNxx entry) rather than CSQ3EPX for MQ. Details of each of these control blocks can be found in: PSA : SYS1.MACLIB(IHAPSA) CVT : SYS1.MACLIB(CVT) JESCT : SYS1.MACLIB(IEFJESCT) SSCT : SYS1.MACLIB(IEFJSCVT) ERLY : Layout in SDSNSAMP(DSNWCBDS) Some Code The following is some example Rexx code that walks these control blocks to report all of the DB2 subsystems defined on an LPAR and whether they are active or not: Specifying Which Db2 Subsystems CICS connects to can be overridden by specifying a DB2subsystem on DSNC STRT in cics. /* Rexx -------------------------------------------------------------*/ /* */ /* DB2SSIDS */ /* ======== */ /* Return the status of all DB2 subsystems defined on this LPAR. */ /* */ /* Parms : None */ /* */ /* Output : A line for each subsystem that is defined on the LPAR of */ /* the following form: */ /* */ /* ssid { ACTIVE } */ /* */ /* i.e. each subsystem is listed and is flagged as ACTIVE */ /* if running. */ /* */ /*-------------------------------------------------------------------*/ /* */ /* James Gill - November 2014 */ /* */ /*-------------------------------------------------------------------*/ numeric digits 20 psa = 0 /* psa absolute address */ psa_cvt = 16 /* psa->cvt p

I have my groups.io preference set to "I always want to receive copies of my own emails" but none of the emails I send to the group are sent to me (no, they don't get routed to my junk folder either). Does anyone else have this issue? Should I report this to groups.io somehow? Peter

[Cross-posted to Hercules-390, H390-MVS and H390-VM groups] I like being able to automate Hercules startup and shutdown under Windows like the excellent and well-thought-out TK4 scripting, and have used very TK4-like scripting for several of my Hercules instances. I owe a big thanks to the TK4 team for that. One issue I had was how to cleanly shut down the 3270 terminal sessions at Hercules shutdown without manual intervention. At first I was using the Windows command "taskkill" with the "/IM" switch to shut down all copies of the emulator program running at a late point in the shutdown process. However, that creates difficulties if you have more than one active instance of Hercules running. When you go through the automated shutdown process for instance 1 you also kill the 3270 sessions for instance 2 (not a good thing to do). This weekend I found a method that works much more precisely, at least for the 3270 emulator that I use, Tom Brennan's Vista TN370. Vista allows you to set the 3270 window title to a unique string, which then allows you to use the "taskkill" filter operation ("/FI") to select only those windows with a particular unique string in the title. For instance, if one has a couple of Vista TN3270 sessions each with the Window title set to "MyMVS1 Session &WindowID", then when shutting down the MyMVS1 instance of Hercules you can execute this command from one of the HAO shutdown scripts: sh STARTGUI stopterm.cmd Where stopterm.cmd is just: @Echo off taskkill /FI "WINDOWTITLE eq MyMVS1*" Note the asterisk at the end of the filter value; that is the taskkill wildcard that says "and anything that follows". The technique should work for any Windows 3270 emulator that allows you to set a unique window title for your 3270 sessions when you start them. HTH Peter --

Very good Peter. But how do you set the Vista TN3270 window title? Regards JR -----Mensagem original----- De: [email protected] <[email protected]> Em nome de pjfarley3 Enviada em: domingo, 8 de mar?o de 2020 03:26 Para: [email protected]; [email protected]; [email protected] Assunto: [H390-MVS] Tip for automating Hercules shutdowns on Windows systems [Cross-posted to Hercules-390, H390-MVS and H390-VM groups] I like being able to automate Hercules startup and shutdown under Windows like the excellent and well-thought-out TK4 scripting, and have used very TK4-like scripting for several of my Hercules instances. I owe a big thanks to the TK4 team for that. One issue I had was how to cleanly shut down the 3270 terminal sessions at Hercules shutdown without manual intervention. At first I was using the Windows command "taskkill" with the "/IM" switch to shut down all copies of the emulator program running at a late point in the shutdown process. However, that creates difficulties if you have more than one active instance of Hercules running. When you go through the automated shutdown process for instance 1 you also kill the 3270 sessions for instance 2 (not a good thing to do). This weekend I found a method that works much more precisely, at least for the 3270 emulator that I use, Tom Brennan's Vista TN370. Vista allows you to set the 3270 window title to a unique string, which then allows you to use the "taskkill" filter operation ("/FI") to select only those windows with a particular unique string in the title. For instance, if one has a couple of Vista TN3270 sessions each with the Window title set to "MyMVS1 Session &WindowID", then when shutting down the MyMVS1 instance of Hercules you can execute this command from one of the HAO shutdown scripts: sh STARTGUI stopterm.cmd Where stopterm.cmd is just: @Echo off taskkill /FI "WINDOWTITLE eq MyMVS1*" Note the asterisk at the end of the filter value; that is the taskkill wildcard that says "and anything that follows". The technique should work for any Windows 3270 emulator that allows you to set a unique window title for your 3270 sessions when you start them. HTH Peter -- -- att. Jo?o

Vista menu tab "Options", item "Options", "General" tab. Midway that window on the left side is "Window Title". The default Vista title contents is the string "Vista Session &windowid". Just change that to "MYMVS1 Session &windowid" (or whatever unique string you want), connect that session to the Hercules instance and then logoff and close the Vista session to save the session file and you are done. The window title is saved in the Vista "*.ses" file so each session file can have a unique window title. When starting Vista sessions for a particular Hercules instance, just use something like: start /D<path-to-Vista-session-files> <path-to-Vista-executables>\vistaTN3270.exe MYMVS1.ses If you invoke the "start a 3270 session" and "stop all 3270 sessions for this Hercules" command files from a Hercules HAO script as I do, be sure to use the STARTGUI option like this: In the HAO script before IPL use: sh STARTGUI startterm.cmd and in the "stopping" script after the hosted OS is fully terminated use: sh STARTGUI stopterm.cmd HTH Peter

[Cross-posted to Hercules-390, H390-MVS and H390-VM groups] I am asking widely for help with this issue since I have not been able to find a solution on my own. I wish to update the SYSTEM CONFIG file on the VM/ESA V2R4 mini-disk CF1 under the MAINT userid in order to change the SYSTEM_IDENTIFIER statements to allow VM to identify its CPU ID correctly for any CPU model number. The default SYSTEM_IDENTIFIER statements delivered with the system use "7490" as the CPU model number whereas I would like to use an "*" to allow any model number to be used. I would also like to add more SYSTEM_IDENTIFIER statements to allow using Hercules LPAR mode (which sets the high byte of the CPU number to the LPAR number) to also be used. HOWEVER, it seems that once the VM system is IPL'ed the SYSTEM itself has "stable write" access to both the CF1 and CF2 PARM mini-disks and no other user can get write access to either of those mini-disks. I have reviewed much VM documentation trying to determine how to get write access to the CF1/2 PARM mini-disks, but the CP LINK command documentation in particular is pretty clear (unless I am mis-reading the documentation) that if ANYONE has "stable write access" to a mini-disk then NO ONE can get a write link of any kind to that mini-disk. So I need to ask any listers with memories of VM/ESA times how one goes about updating a SYSTEM CONFIG file if one cannot get write access to the CF1/2 mini-disks? Yes, I do know that I could tell Hercules to set the CPU model to 7490 to match the existing SYSTEM_IDENTIFIER statements, but that doesn't change the need for additional SYSTEM_IDENTIFIER statements for LPAR mode or the potential need to update the SYSTEM CONFIG file for other reasons, so it would be really useful to know how to do this update for any necessary reason. Any help you can offer or any pertinent RTFM will be much appreciated. Peter --

Great, Peter Thank you HTH JR -----Mensagem original----- De: [email protected] <[email protected]> Em nome de pjfarley3 Enviada em: domingo, 8 de mar?o de 2020 15:38 Para: [email protected] Assunto: Re: [H390-MVS] Tip for automating Hercules shutdowns on Windows systems Vista menu tab "Options", item "Options", "General" tab. Midway that window on the left side is "Window Title". The default Vista title contents is the string "Vista Session &windowid". Just change that to "MYMVS1 Session &windowid" (or whatever unique string you want), connect that session to the Hercules instance and then logoff and close the Vista session to save the session file and you are done. The window title is saved in the Vista "*.ses" file so each session file can have a unique window title. When starting Vista sessions for a particular Hercules instance, just use something like: start /D<path-to-Vista-session-files> <path-to-Vista-executables>\vistaTN3270.exe MYMVS1.ses If you invoke the "start a 3270 session" and "stop all 3270 sessions for this Hercules" command files from a Hercules HAO script as I do, be sure to use the STARTGUI option like this: In the HAO script before IPL use: sh STARTGUI startterm.cmd and in the "stopping" script after the hosted OS is fully terminated use: sh STARTGUI stopterm.cmd HTH Peter

Is anyone aware of a text formatter for MVS 3.8J? Something like RUNOFF, used for typesetting documentation (typically on a line printer). A non-IBM version of SCRIPT (WATERLOO script?) is available on the VM/370 six-pack, the name eludes me, but I am looking for something to run on MVS 3.8J.